Elite: Dangerous - Design Decision Forum

[Cody]

Thanks, Gimi...

Some malfunctions can be ended early by specific action that commanders can learn (such as switching a module off and back on...

... I had to laugh at that!

[Commander McLane]

Thanks, Gimi...

Some malfunctions can be ended early by specific action that commanders can learn (such as switching a module off and back on...

... I had to laugh at that!

Seems there'll still be equipment designed by Microsoft in the 34th century (and it's going to be of the same quality as in the 20th century).

[JazHaz]

Seems there'll still be equipment designed by Microsoft in the 34th century (and it's going to be of the same quality as in the 20th century).

And ditto for the quality of Microsoft in the 21st century...

[Norby]

It will be good to see more stronger ships, I always thinked that a single enemy is too weak in Elite and the mass attacks is not the best compensation (I try to make a better solution in the [wiki]HardShips[/wiki] OXP).

The management interface of the repairs remind me to the I-War which was cool: a detailed screen with about 20 damageable modules and visual feedback from the repairs where player can change the priorities: engines over weapons when flee, etc.

By the way I will welcome if somebody make an OXP ship based on Dreadnaught from I-War.

[JazHaz]

New topic for discussion in the DDF.

"He who controls the Spice controls the universe" Injected Events in Elite Dangerous

Hello there DDF!

So, the new video is out of the bag, which we all hope is going down well, but lets not forget that it's also new topic time! You lucky, lucky people you...

Today's somewhat vast topic is injected events, a system with fingers in many pies, mechanically speaking. Here it is:


INJECTED EVENTS
This system will be used to create large events and large scale changes to the Elite Dangerous universe.

GOALS

• Create large scale events for all players to enjoy within the ED universe.
• Use player influences and system data from within the galaxy to feed into a meta-game system.
• Provide story and content for missions and other environmental encounters.

WHAT ARE INJECTED EVENTS?
Injected events allow larger events to happen within the galaxy. These will not be initiated directly by players or specific actions, but will instead be based on the current state of a star system or faction, even certain random factors. These will be influenced by many factors:

• Background simulation – the system itself will keep track of information within each system, such as population, wealth, standard of living & political influences.
• Faction information – every faction will have status information, including friend/foe lists, station info, local specialisations & NPC hierarchy.
• Government type – different types of government will affect the threshold at which certain events can be initiated.
• Discoveries – big discoveries or new systems/planets that appear will affect all nearby star systems, potentially spawning new structures or causing events to break out (e.g. war, gold rush, etc.).
• Contested star systems – any place where 2 enemy factions have influence will be considered contested, making it open to larger injected events.
• Player influence – players will be able to influence a star system or faction through many different avenues (see Player Influence below).

This information will be held & controlled by the meta-game, and then used by the developers to create these larger events and happenings. The idea is to create injected events that are relevant to the situation.

In the future, we would hope to create a system that maintains a semi-autonomous approach to this, creating these events without the need for developer interaction, but also still allowing the team to inject separately.

META GAME
The entire system will be based off of rules dictated by a meta-game system, which will look at each location and calculate a set of factors by which an injected event can best be initiated. What this will mean is taking the influencing factors mentioned above and seeing where events would be best placed.

For example:

• A colony with a large population, nearby to a newly found, uninhabited Earth-like world might colonise that planet. A colony suffering from famine or being under-populated would not.
• A star system with low wealth, low development or low standard of living levels would be more likely to suffer from pandemics, famines, governmental collapse and other serious planetary failures.
• Star systems that are contested by 2 opposing forces may suffer from war, be it civil or between factions.

This shouldn’t stop the developers from injecting more random events, such as extinction level asteroid collisions or alien influences if the need arises. Its function is to create relevance and a sense of a living, evolving galaxy.

OUTCOME OF INJECTED EVENTS
These events have the ability to significantly affect the ED universe, changing systems and locations, allowing us to keep it as interesting as possible. Depending on the event, the following are a few examples of what can happen:

• Two factions could declare war on each other. The event would be focused around a disputed star system, allowing us to create combat encounters and missions, as well as refugees, unscrupulous pirates and aid requests. Eventually the star system could change hands and governments.
• A new colony and space station is established in a recently discovered star system. Nearby over populated star systems might send out a colony ships, establishing a new station, which would promote trade missions, aid requests and other missions based on setting up a new colony.
• A well populated planet suffers from an asteroid collision disaster, causing destruction over large parts of the surface (a visible change to the planet for players). This in turn would have the potential to influence other injected events, such as a planet wide famine or a severe pandemic.

PLAYER INFLUENCE
Players will be able to influence this system, since the meta-game will feed off of changes in the simulation from many different sources, including players. For example:

• Missions – generally these will have the largest positive or negative effect on the system, depending on faction, success or failure, nearby enemies or allies, the importance of the mission undertaken, and various unforeseen consequences.
• Trade – player trade will have a minor effect on the system, although a star system already under the effect of an injected event may be exploitable (i.e. food sold to a star system suffering from a famine would fetch a very good price).
• NPC interactions – attacking, defending, interacting and killing NPC’s within a star system or faction will have an effect. The everyday NPC’s met won’t be high level, so their influence will be limited to small changes. For example, killing a trader will negatively affect the wealth of his faction or star system, but not to a vast extent.
• Exploration – discoveries made by players, once sold into the system, will be unlocked for the system to use for injected events.

The key here is to create way for players to influence the universe around them, without being able to destabilise or break the overall simulation.

Okay, no specific discussion points from me here, we're interested in what you think, anything you think we've missed, anything that could make this greater. Feel free to also post up any big ideas or epic scenarios you can think of for us to inject, anything you'd like to see happen in the ED universe.

[JazHaz]

New topic for discussion in the DDF.

"Stop your grinnin' and drop your linen!" Sensors and Targeting in Elite: Dangerous

Hello lovely DDF backers!

Slightly later than anticipated, here's some crunch for sensors and tracking rules - no fluff in this breakdown, though I will add that whatever we go with, we'll be sure to make the presentation of it as sexy as possible. On with the show!

SENSOR MECHANICS

• Default Sensors for all ships
  • Upon arrival to a new location they slowly build up a picture of potential contacts around the player as fuzzy/noisy blobs
  • More detailed sensors are located in a forward facing arc and a more detailed and accurate picture of potential contacts are realised as the player looks around the location
  • The longer the player spends looking in a particular direction the more resolved the picture becomes as more detail is added and false positives removed
  • At a certain level of certainty (time taken looking at it) in the sensor image a contact will be validated as an actual contact and from then on the contact will be automatically tracked by the ships computer
    • The further the potential contact is away, the longer it’ll take to resolve their sensor image enough to validate the contact
    • The contact itself will also dictate the length of time required depending on their heat/EM signature, stealth systems etc.
  • A contact that has been validated can be lost again if a significant change in its stealth capabilities (Heat/EM/Stealth Systems/Occlusion by large objects) make it harder to detect than it has been
    • Lost contacts are significantly easier to reacquire providing the player can look in the right/expected place for it
  • Only contacts that have been validated can be targeted by the targeting computer so that weapons can provide assistance/gimballing/lock-on etc.
  • All of the above happens at longer ranges because at close range ships will typically rush through the above steps extremely quickly
• Advanced Passive Sensors
  • These are deployable sensors that dramatically improve your ships forward facing detection abilities by providing a player driven way to validate potential contacts from long range
  • When active they provide an audible signal through the radio and visual representation of various wavelengths that usually indicate background noise in the location
  • When a potential contact is looked at the audio and visuals could change such that a specific sound and visual spike is displayed that can tell the player the type of ship and distance if they’re familiar with the signal
  • After a very brief period of time focusing on a potential contact found through the use of the system the contact will become validated (far quicker than the default sensors especially at range)
  • Passive sensors like these don’t affect the ships current visibility to other ships sensors other than the potential heat increase through power used
• Advanced Active Sensors
  • These are deployable sensors that actively search for contacts using strong EM pulses and other forms of detection that can be detected by the contacts themselves
  • They are extremely powerful in that potential contacts within the sensor range can be validated almost instantly at the cost of also lighting the ship up to everyone else
  • They come in both forward facing only and in fully spherical configurations
    • Forward facing typically operate to much larger ranges and are quicker than the all around types
  • Activating an active sensor will “ping” the area and instantly reveal any potential contacts that the sensor is able to detect (some ships running cold or are otherwise stealthy might still not show up)
    • The further away a contact is the less likely it will be able to be detected
  • After activating a contact will know that they have been “pinged” and are also told the direction it came from if the instigating ship hasn’t been fully resolved as a valid contact yet, or are highlighted if they are on the sensors of the contact’s ship

TARGETING MECHANICS

• Once a ship has been resolved on the sensors the player can target them to provide a more detailed readout on the type and status of the ship
  • Targeted ships are highlighted on the sensors as well as on the HUD
• Detailed readouts of the ship are displayed in a dedicated panel on the cockpit whilst the ship is targeted
• By having a ship targeted several other mechanics can come into play based on the equipment installed and/or deployed on the player’s ship:
  • Missile lock (described below)
  • Subsystem scanning (described below)
  • Cargo Scanning (Mechanically identical to subsystem scanning)
  • Weapon gimballing (ability for gimballed weapons to provide aiming assistance on targeted ships)

MISSILE LOCK

• To begin the missile lock sequence the player must...
  • ...have a ship targeted
  • ...have a seeking missile weapon deployed
• Once the above conditions are met the HUD will indicate an acquiring lock symbol which will, over time, move from the centre of the HUD to the onscreen position of the targeted enemy
• When the acquiring lock symbol is maintained on top of the targeted ship icon for a short time the missile system will acquire a lock and the symbol will change
• Whilst a lock is acquired the symbol will overlay the target providing the enemy is within the FOV of the player’s ship
• If the enemy ship ever moves outside the FOV of the player’s ship any missile locks will be lost and will need to be reacquired
• Players can speed up missile lock by aiming their ship such to bring the acquiring lock symbol on their HUD on top of the intended target faster than if just leaving it to do it automatically
• Firing a seeking missile with a lock acquired will result in the missile being able to either:
  • Independently track the target and no further action by the player is required (they can break lock without affecting the launched missile)
  • Track the target providing the player maintains a lock throughout the missiles flight path (losing lock will result in the missile maintain its last heading until the lock is reacquired or the missile runs out of fuel)

SUBSYSTEM TARGETING

• To begin the subsystem targeting sequence the player must...
  • ...have a ship targeted
  • ...have a subsystem scanning module installed and/or deployed if necessary
• The scanning sequence will take time based on the quality of the module and also requires that the target ship to be in the FOV of the player’s ship the entire time (like with missile lock)
  • The target ship will know they’re being scanned unless the player is using specifically stealthy scanning modules
• If the target ship moves off screen or the lock on is disengaged for whatever reason the scanning will be cancelled
• Only when a full scan for the required time is made will the enemy subsystems be available to target through the cockpit interface and other appropriate input
• Once a full scan is completed the player doesn’t need another scan to reacquire the subsystem list if they change targets in the mean time (i.e. the ship remembers the results of the scan on a per target basis)

CARGO SCANNING

• Mechanically identical to subsystem targeting, cargo scanning just requires the specific scanning module to be installed to enable it
• Both subsystem scanners and cargo scanners can both be installed at the same time and will also run at the same time provided they are both powered and/or deployed if necessary

Not much to add to this one except that we think this is fairly comprehensive. So what do you guys feel? We hope that you can start to see now (along with all the other topics) how we're heading for something a little more "sim" like and in depth, but without swamping the player with super complexity on any particular system. But it would be interesting to hear from you guys on whether we are getting the balance right.

Scan the proposal and report your findings!

[cim]

• Whilst a lock is acquired the symbol will overlay the target providing the enemy is within the FOV of the player’s ship
• If the enemy ship ever moves outside the FOV of the player’s ship any missile locks will be lost and will need to be reacquired

Sounds fun in general. What does FOV mean in this context? If it means you have to keep the target where you can see it from the cockpit, that seems to make missiles mostly useless for defense of large ships. If it just means it has to be in sensor detection range like the original Elite (but lock-on is faster if you can keep the target in your forward sensors)

• Independently track the target and no further action by the player is required (they can break lock without affecting the launched missile)
• Track the target providing the player maintains a lock throughout the missiles flight path (losing lock will result in the missile maintain its last heading until the lock is reacquired or the missile runs out of fuel)

Presumably the first sort of missile uses active sensors to keep a lock and would be easily detected. With the second sort of missile, is there the possibility to lock up a target with passive sensors only, and fire the missile with perhaps them only becoming aware of it very late on when their own 360-degree sensors confirm it. Or are missiles generally sufficiently unstealthy that you can't do that?

[JazHaz]

• Whilst a lock is acquired the symbol will overlay the target providing the enemy is within the FOV of the player’s ship
• If the enemy ship ever moves outside the FOV of the player’s ship any missile locks will be lost and will need to be reacquired

Sounds fun in general. What does FOV mean in this context? If it means you have to keep the target where you can see it from the cockpit, that seems to make missiles mostly useless for defense of large ships. If it just means it has to be in sensor detection range like the original Elite (but lock-on is faster if you can keep the target in your forward sensors)

FOV stands for field of view, and refers to where the sensor is placed. For small ships there might be only be one sensor, facing forwards. On large ships there might be lots of sensors, placed all over the hull giving an all round detection.

• Independently track the target and no further action by the player is required (they can break lock without affecting the launched missile)
• Track the target providing the player maintains a lock throughout the missiles flight path (losing lock will result in the missile maintain its last heading until the lock is reacquired or the missile runs out of fuel)

Presumably the first sort of missile uses active sensors to keep a lock and would be easily detected. With the second sort of missile, is there the possibility to lock up a target with passive sensors only, and fire the missile with perhaps them only becoming aware of it very late on when their own 360-degree sensors confirm it. Or are missiles generally sufficiently unstealthy that you can't do that?

Discussions are going towards there being different sensors, eg active ones send out radar "pings" and find targets really quick, downside being that you advertise your presence to all other ships; then there are passive ones which work slower but enable you to be more stealthy.

[Diziet Sma]

I think the over-emphasis on forward-looking sensors is rather unrealistic.. even present-day cars, limited to optical scanning only, provide drivers with ways of 'looking over one's shoulder'... the idea that someone flying in potentially hostile space would not have full 360° sensors in place is ridiculous.

[Disembodied]

I think the over-emphasis on forward-looking sensors is rather unrealistic.. even present-day cars, limited to optical scanning only, provide drivers with ways of 'looking over one's shoulder'... the idea that someone flying in potentially hostile space would not have full 360° sensors in place is ridiculous.

If it makes a better game, I'm all for it. Maybe the engine produces subspace turbulence, or whatever, making it difficult to look behind you. Let's face it, space dogfights are ridiculous: combat - to be realistic - should be minuscule dots shooting lasers, or clouds of accelerated gravel, at other minuscule dots, or at where they think those dots will be when the laser/gravel arrives several seconds, minutes, or hours later. It could work as a game, but it would be a very different type of game.

[JazHaz]

A different way of looking at this issue is to consider nature... predators having forward facing eyes, binocular vision, and prey having eyes on the side of the head to look for threats all around...

[JazHaz]

Hello all, glad you all generally like the proposal.

Here are some clarifications though forgive me if I miss some of the questions:

• Missiles can indeed come in a variety of flavours dictating their lock-on behaviour and affective lock-on arc (the most expensive being able to lock on nearly at any angle and then maintain a lock after firing independently)
• Ranges we're talking about is everywhere between metres to tens of kilometres (unlikely to be able to push that out further despite our best wishes)
• The directionality of the sensors was only meant to provide as some people have guessed some game play for the player to undertake to help resolve their sensor image faster. You always get an all around look at the area but the arc in front of the player just resolves that bit quicker
• Generally speaking the idea is that ships only a couple hundred metres away pretty much resolve instantly providing they're not actively trying to stay hidden (running cold etc.)
• When we said deployed we meant something that takes up a hard point much like a weapon system. It deploys onto the surface of the ship to scan (i.e. no probes or any remote stuff in this proposal)
• Capital ships would have executive control. Anacondas, although large, are not executive control and thus you will be having to point your ship at targets for the most part to lock-on missiles if you decided to equip it that way. A more sensible option would be to have turrets instead that can track targets independently
• I would very much like to have line of sight blocking obstacles like asteroids be used to avoid detection

If any has any more questions or if I missed an earlier one please repeat it and I'll try and keep on top of them seeing as I'm now in work

[JazHaz]

This is quite an interesting conversation, really helps to illustrate how multi-player is going to work in E: D.:

Your answers touched on this briefly, but to make sure we're on the same page:

Is it correct to say that players only join the same instance when they come within tens of kilometres of each other?

Yes

Do the sensors in this proposal refer only to people within tens of kilometres, or does the long range scanning apply to the whole system?

Only to people within tens of kilometres.

Before players come within tens of kilometres, are they able to interact with all other players in the system or does the 32 player limit apply there too?

No, you can only interact with people in the same "instance" as you.

If this proposal is about scanning within tens of kilometres, what are the plans for detecting players at longer distances?

There are no plans to detect players at greater distances.

So, there could be hundreds or thousands of players in an individual system (especially the core systems) but each instance might only have a few players in them. This means that a system with lots of players won't necessarily cause slowdowns in gameplay. A very good technique I think.

[Cody]

I ain't too sure about 'instancing' - beyond my ken, is that.

I would very much like to have line of sight blocking obstacles like asteroids be used to avoid detection

I like this idea though - a lot!

[Diziet Sma]

A different way of looking at this issue is to consider nature... predators having forward facing eyes, binocular vision, and prey having eyes on the side of the head to look for threats all around...

And the first thing humans did when technology allowed them to, was use it to compensate for the inbuilt blind spots..

The directionality of the sensors was only meant to provide as some people have guessed some game play for the player to undertake to help resolve their sensor image faster. You always get an all around look at the area but the arc in front of the player just resolves that bit quicker

Ok.. that makes more sense.. thanks for posting the clarification, JazHaz!