|
|
| Author |
Thread Statistics | Show CCP posts - 6 post(s) |
Avallo Kantor
1160
   |
Posted - 2016.06.03 20:02:00 -
[1] - Quote
One thing I would hope to see is modes on the ships that represent us destroying / offlining ship assets during a fight.
I mean taking over a ship is one matter, but a mercenary strike force can be perhaps even more effective on huge ships if they are sent to certain regions with the idea of sabotage. After all, it's not like we need to get out alive.
*Hopes for a way to turn off gravity on a map*
"Mind Blown" - CCP Rattati
|
Avallo Kantor
1160
|
Posted - 2016.06.03 20:43:00 -
[2] - Quote
My true dream for a map is an orbital station where you can jump off, and drop down to a planetary portion of the map.
(Just the idea of basically skydiving from low-orbit)
"Mind Blown" - CCP Rattati
|
Avallo Kantor
1163
|
Posted - 2016.06.06 18:46:00 -
[3] - Quote
One thing I have always thought of for DUST / EVE gameplay in regards to ships was the notion of DUST mercs being a 'payload' type for EVE ships to use.
For example have special ship types that have landing pods / (those troop transports from the Future of EVE video) as their high slot armament. Then they contract out, or use corp mercs to be the ones ready to implant themselves in the inert clones if they manage to land. (Why bother having the mercs in the clones before that?)
What then happens is that in EVE during a battle, this weapon can be deployed by an EVE ship against another EVE ship. If successful this creates (on a separate battle server) a combat contract that the mercenaries can then take. Meanwhile a defensive contract opens up for the other side and a battle spools up. Objectives in the map can vary, as can size of deployment / map. The infiltrating force then vies for completion of those objectives. As certain events happen, the battle server sends a two part message back to the EVE side of things.
This message would be:
[Timestamp, Event]
The EVE client would then treat this as any other activity in the game, taking the appropriate action once the relevant event is received. The timestamp can then be used in Time Dilation environments to determine when the event fires in EVE.
As an example:
Let us assume 2 fleets. A and B. In addition to those two fleets, two companies have been formed Ac and Bc. (Companies in this case meaning a large collection of mercs) These companies have been set up to see contracts that form on their respective fleets.
A and B engage in battle. During the battle A uses ships that are fitted with these boarding parties to attack fleet B. These create a number of contracts where Ac attacks Bc. These appear in some sort of contract system.
In the battles Ac manages to achieve certain objectives against certain ships. Let's say one effect is to damage engines, which mechanically act as a web effect until resolved. This happens 5 min into the battle. So the battle, that is running on a separate server, sends to the server running the EVE battle [Timestamp of battle start + 5 min, Web Effect on [Ship ID]].
Meanwhile, because of the size of the battle in EVE, time dilation has taken effect let's say... 10%. This means that when the event is received, the server knows that server time has not reached the timestamp of that event, and simply holds it in queue. After a set period of server time has passed that is the timestamped time, the event triggers in EVE.
-example over-
In this way, the following is achieved:
1) EVE ships can only have this action inflicted on them by another EVE ship. [Mercs can not invade a player ship without EVE actions]
2) Contracts are created as events so that you can have a pool of people who can take them. You do not need to have every ship filled with mercs and only those mercs. Those with the permissions to view fleet contracts can join any event. [Attack or Defense]
3) Battles happen on separate servers from EVE battles as not to have the two fight over resources. The only events that are sent over are short individual events that can be easily sent. It could be set up in such a way as to only have "one additional connection" load on the server. (And a fairly inactive connection at that, most user connections would be sending -far- more events to a server)
"Mind Blown" - CCP Rattati
|
Avallo Kantor
1164
|
Posted - 2016.06.07 03:00:00 -
[4] - Quote
I like to imagine that once NOVA Mercs become a big deal, larger ships will start being installed with clone bays (inactive clones) that can be onlined when boarders arrive.
I imagine such a clone bays being in various strategic locations on the ship, heavily guarded, with a more central location on the ship. I imagine a setup that gives the imagination view to rows and rows of clones in vats, and maybe a "Iron-Man" style armoring station where a clone could be spat out, armored up, and spat into the area. All very clean and fortified.
This would be in contrast to the boarders where the pods have just breached in, a look of havoc and rush that makes the boarding area look frantic, and out of order.
As to voice overs, I think the attackers should have special VO for the attackers, from a commander giving updates, orders, etc. Maybe have the map change slightly in regards to the attackers gaining objectives vs defenders reclaiming objectives.
Lights going from "standard" to "emergency" lighting (if dynamic lighting is possible), Engine sounds going off or on, or even other minor effects changing. (For example out of a window you could see guns firing, or not firing based on who controls the hardpoint)
Edit:
How dynamic do you think maps will be? Will they be able to having "moving parts" as it were?
If you have any plans for moving parts what do you think of doing in a broad sense?
[Lighting effects, Sound effects, all the way up to parts of the map actually moving]
"Mind Blown" - CCP Rattati
|
Avallo Kantor
1167
|
Posted - 2016.06.07 18:13:00 -
[5] - Quote
How much is team size a factor in map creation, and to what degree would it differ the map?
Also do you plan to have any continuation of the "Socket" system from DUST? I remember when first hearing about it that it could, long term, have huge possibilities for nearly infinite map variations. On the downside, I realize that such customizability takes away from a well designed overall map experience, if you have to design each socket to be potentially independent parts of a larger map.
"Mind Blown" - CCP Rattati
|
|
|
| |
|