BGS - How to make the game more dynamic and drastically improve the simulation of the world

I wonder how NPCs then are created based on the player states "have cargo/have bounty/ on mission".
It would be necessary to work that aspect of communication in to the server, if that is the case,
to keep track.

There is no communication to the server, once you accept the mission you run a finite state machine on your system that dictates you need a few extra ships in SC under certain/random conditionst that lasts until the mission ends. This is tied to you and you only on your client and gets propagated to your instance. But there is no actual server order to have you spawning an extra ship in SC while you fly. You communicate to the server the event of death, or crime, as any other regular -normal speed flying- event.


If a player is in system x, for the first step, it should be restricted to the same system, informing nearby "sessions"
of players owning/managing instances. The owners/managers then would be required to communicate
the info on a new USS to the clients connected to them via P2P.

The client generating the beacon or generating the new USS has its own instance and has no idea how many other instances of SC on that system are around so really there are no clients connected via P2P untill you jump out to SC or someone jumps into your instance (this to happen right now has to be through wing beacon or low wake). Lets assume he sends the 'activate beacon', 'activate distress' whatever to the server and this one wants to replicate that now to the people in SC. First, for sure there is going to be cases where no one will be in SC in that system, an other cases where 20 instances will be existing, you want now to tell the server: send this new info to the instances of the players who's ping with this other player fits under the 'reasonable value', and also considering they are not blocked. Usually the more latency between different clients the more instances of the game at the same time, meaning very far countries will spawn different instances. On top of that, the game still has to give preference to friends and wingmates, as if without them it wasnt hard enough.

Lets say you success in this and then several players come to join, imagine 1 of each Supercruise instance'. What is going to happen if I'm in Europe and have an average ping with US and average ping with Australia, they both can see the USS, when these two players that have an horrible ping between them join the new instance? horrible experience for everyone.


Regarding the information required to inform other "sessions",
would it not be sufficient to add a lifetime timer to each new USS,
especially in res sites or CZs, only generating new USS, when another infraction
is tracked after the previously generated USS timed out?

This can definitely work, but then you are adding more logic to the EDServer, and therefore going away of selling the idea. If you define a type of USS based on an event (e.g. a shooting, or a death) then it can 'somehow' tricked to work. If the EDServer (that is instance based) has now to decided what happens in an area where there could be different instances (remeber I'm flying in SuperCruise and there could be 20 different RES instances running) to show whether there is one USS or more (because soon after a distress you will have a degraded emissions, followed by another distress and again degraded, etc..) then I can tell you this will not happen, at least not like that.
 
So with the technical side as topic,
i'd say when you enter an instance in normal cruise
and you do something that qualifies to spawning a USS (trigger),
you send a short info to the ED server you are logged in to.

That information is distributed to the clients connected
and in the same system as you, generating a USS.

In heavy traffic areas, where multiple events are happening,
the server keeps track of a list and distributes that information,
flagged with your preferred instance (the one you were in in SC
or you have friends/wingmates in) to the instances in the same system.

While that is said, if you are not on the friendslist, or not a wingman
you have lower priority down to 0 prio if you blocked the CMDR,
however if you had not a player USS for a set time, your prio on the list increases.
The server then distributes the info of a new prioritized USS
to a set number of CMDRs striking the USS off the list to distribute,
but keeps track of the USS encounter until resolved or timed out.

Does that work?
 
  • Like (+1)
Reactions: ilo
Sure I might sound discouraging, but I'd like to point out that after talking about this there could be a reasonable technical approach that could be experimented.

Frontier's farm of EDServers is big. The client is constantly connected to the EDServer and actually, the client is the instance, not the EDServer, so basically everything that happens is in the client creating the instance, but the server is aware of all the events. Now, the server farm assigns servers using several factors, but I want to believe the geographic location is one of them, which means, all players connected to the same EDServer are in a 'decent' latency range.

What if, the distress signal is generated on the client and therefore the corresponding EDServer is informed about it, and this EDServer then informs all the instances it manages on that system?

it may happen that the EDServer might have 300 people connected and none of them are on that system.. so what, there is no real difference to what ED is right now. But if at least one player has an instance in the same system on that EDServer it will be safe to send him the USS since it is already in a good network latency range. On certain signals you could also be informed of USS on close systems via your inbox (e.g. same player faction USS).

So, the answer to 'what SuperCruise instances do you inform about normal cruise events' would be 'those instances happening in the same system as you (or close) managed by the same EDServer, this could probably work well.
 
Sure I might sound discouraging, but I'd like to point out that after talking about this there could be a reasonable technical approach that could be experimented.

Frontier's farm of EDServers is big. The client is constantly connected to the EDServer and actually, the client is the instance, not the EDServer, so basically everything that happens is in the client creating the instance, but the server is aware of all the events. Now, the server farm assigns servers using several factors, but I want to believe the geographic location is one of them, which means, all players connected to the same EDServer are in a 'decent' latency range.

What if, the distress signal is generated on the client and therefore the corresponding EDServer is informed about it, and this EDServer then informs all the instances it manages on that system?

it may happen that the EDServer might have 300 people connected and none of them are on that system.. so what, there is no real difference to what ED is right now. But if at least one player has an instance in the same system on that EDServer it will be safe to send him the USS since it is already in a good network latency range. On certain signals you could also be informed of USS on close systems via your inbox (e.g. same player faction USS).

So, the answer to 'what SuperCruise instances do you inform about normal cruise events' would be 'those instances happening in the same system as you (or close) managed by the same EDServer, this could probably work well.

Sounds good to me, really hoping on a FD response.
 
  • Like (+1)
Reactions: ilo
In all honesty, I suggest you set the technical limitations aside from now on, focus on what you try to achieve as gameplay and ignore any negative answer about 'that can't be done', because I'm sure with will everything can be done.

Thanks for the constructive work, it seems the idea forms into a first draft.
Hope FD will have a look, i have been proposing stuff like this for a long time,
just not with the detail we have here, due to co-op.

I'd also like to add that having priorities is necessary, as in a high traffic area
players with long time no player spawned USSes should have a higher prio
to not be left out.

Also more than the initially triggers could be designed, like the ATR zooming in.
What would be paramount is a check to see, if the player has "report crimes on",
to automatically spawn an associated USS, but also allow to manually spawn a
distress call for explorers in the void, or pirate trap laying ;)
 
Last edited:
thank you for bringing this up, Julio, I'll always push your creative ideas forward, and this one I think really fills gap in the ED galaxy.
 
I updated the OP with ideas how to solve the technical side,
especially when in high population areas.

Any more things to look at and get in form for a first draft?
 
I updated the OP with ideas how to solve the technical side,
especially when in high population areas.

Any more things to look at and get in form for a first draft?

I'd also avoid the technical side at this point - I think instancing is only an issue when another player tries to drop into the player generated USS and the normal matchmaking rules would apply.

The key point that ilo mentioned is the use of whatever events are triggered by the player in normal space to trigger updates to the USSs in SC so I'd focus on that.
Merely dropping out of SC into a USS must trigger a transaction because a new instance gets created so the initial encounter is certainly available to use.

The question then is whether other events in normal space create transactions that can be used.
- committing or being the victim of a crime i.e. weapons fire in a jurisdiction
- destruction of a ship generating a bounty or reward
- non-combat USSs are a bit more static so I'm not sure what could be used

However, the new more persistent USS mechanisms definitely do seem to present an opportunity to use player actions to affect them.
The big question is whether the new persistence is just client memory for an individual player, or truly shared across players.
 
I think the OP raises an important issue but I fear the suggestion, itself, is a non-starter.

Firstly, the biggest flaw is, quite simply, that everything is optional (and nothing is important).

Similar thing to the new "scenarios".
It's great that they're making USSs more dynamic, and making them persistent so people can go back to do stuff.
The problem is, almost nobody is going to bother.
Why would I bother to, say, fly to a nearby station, buy some food and then schlep back to a USS so I can deliver it to some sponger who I'll never see again in return for some kind of faction-rep' which, if I'm at all interested in, I can achieve in a heap of different ways?

Fundamentally, there's no reason to care what happens to other players, much less NPCs, so there's no compulsion to assist.


Secondly, the idea of anything related to "distress calls" is always going to be open to abuse.

Any kind of situation that involves an attacked ship (either NPC or player) sending out a distress call is likely to be appropriated by murder-hobos as a way of providing them with "emergent content".
Which isn't necessarily a bad thing except for point #1.

In a game where there's no compelling reason to investigate or respond to anything, (almost) nobody's going to risk doing it.


I do agree that it's an issue though.

No real idea what might be done about it but I suspect that any solutions will centre around the "Pilot's Federation" though.

I know some people hold the view that we're all supposed to be "the same" in this game, and that players should be treated exactly the same as NPC ships but, quite simply, we're not.
We (the players) are supposed to be members of the Pilot's Federation and, AFAIK, NPCs are not (even though they all seem to have PF rank).

Perhaps FDev should look at what they can do with the Pilot's Federation in order to add stuff to the way we all act within the ED universe?
 
I'd also avoid the technical side at this point - I think instancing is only an issue when another player tries to drop into the player generated USS and the normal matchmaking rules would apply.

The key point that ilo mentioned is the use of whatever events are triggered by the player in normal space to trigger updates to the USSs in SC so I'd focus on that.
Merely dropping out of SC into a USS must trigger a transaction because a new instance gets created so the initial encounter is certainly available to use.

The question then is whether other events in normal space create transactions that can be used.
- committing or being the victim of a crime i.e. weapons fire in a jurisdiction
- destruction of a ship generating a bounty or reward
- non-combat USSs are a bit more static so I'm not sure what could be used

However, the new more persistent USS mechanisms definitely do seem to present an opportunity to use player actions to affect them.
The big question is whether the new persistence is just client memory for an individual player, or truly shared across players.

Thanks for the input.

I think the following player actions could act as triggers:
- CMDR attacks a clean ship -> weapons fire
- CMDR attacks police ->police under attack
- CMDR destroys clean ship -> combat aftermath -> emissions of type matching the shiptype
- CMDR destroys police -> combat aftermath -> emissions of type matching the shiptype
- CMDR disables a ship -> distress call
- CMDR is notorious and has ATR inbound -> priority request for assistance
- CMDR has killed an ATR member -> high priority request for assistance -> combat aftermath -> emissions

-CMDR (clean/report crimes on) is under attack -> weapons fire (Pilot's Federation)
-CMDR (clean/report crimes on) is disabled -> distress call (Pilot's Federation)
-CMDR is destroyed -> combat aftermath -> emissions
-CMDR manually uses a distress beacon -> distress call (Pilot's Federation)

-CMDR in 2 wings pledged to different squadrons -> temporary CZ (Pilot's Federation)

I think the OP raises an important issue but I fear the suggestion, itself, is a non-starter.

Firstly, the biggest flaw is, quite simply, that everything is optional (and nothing is important).

Similar thing to the new "scenarios".
It's great that they're making USSs more dynamic, and making them persistent so people can go back to do stuff.
The problem is, almost nobody is going to bother.
Why would I bother to, say, fly to a nearby station, buy some food and then schlep back to a USS so I can deliver it to some sponger who I'll never see again in return for some kind of faction-rep' which, if I'm at all interested in, I can achieve in a heap of different ways?

Fundamentally, there's no reason to care what happens to other players, much less NPCs, so there's no compulsion to assist.

I understand your position, but i think even for a CMDR who doesn't care,
he can see that stuff is happening and the system is not as calm as he thought.
Additionally there could be automated news reports once triggers generate player USSes
and are resolved one or the other way.

It gives an option to people, and options are always great.

Secondly, the idea of anything related to "distress calls" is always going to be open to abuse.

Any kind of situation that involves an attacked ship (either NPC or player) sending out a distress call is likely to be appropriated by murder-hobos as a way of providing them with "emergent content".
Which isn't necessarily a bad thing except for point #1.

In a game where there's no compelling reason to investigate or respond to anything, (almost) nobody's going to risk doing it.

Same applies here as the above response.

I do agree that it's an issue though.

No real idea what might be done about it but I suspect that any solutions will centre around the "Pilot's Federation" though.

I know some people hold the view that we're all supposed to be "the same" in this game, and that players should be treated exactly the same as NPC ships but, quite simply, we're not.
We (the players) are supposed to be members of the Pilot's Federation and, AFAIK, NPCs are not (even though they all seem to have PF rank).

Perhaps FDev should look at what they can do with the Pilot's Federation in order to add stuff to the way we all act within the ED universe?

I took your comment about the PF and added it to the USS label to distinguish between NPC-related USS and Player/Player based USSes.
 
Last edited:
Julio, we might need to reduce the logic in that generation to make it easy/doable.

E.g.: a ship is killed > generate a degraded emissions with corresponding materials (the difference is in the ship type, not player or npc).

Also, while it might be a bit intrusive, and since stealthie already brought up the pilots federation, another easy approach would be if the pilots federation generates 'missions' on the fly (like other factions are doing now)..

So, the affected faction (NPC faction if an npc ship, controlling faction if a player) sends you a message:

CMDR, we have a:
- distress call of a $pilot/npc
- some cargo to recover
- some info on a debris
- whatever

this is recent and you only have $time minutes to complete it, we would pay you:
- $absurdmoney for helping out
- you can keep the cargo (missions have multiple payout options, don't they?)
- you have to return the cargo to $location
- help reducing lockdown chances
- whatever

When you accept the mission you have a POI to visit from the location.. the game has an actual control of what is happening in the instance and can track the subsequent actions (because it is already a mission now and not random space events).

Now, as a pilot the pilots federation might present you a UI to filter what types of missions you want to opt-in or opt-out.

This can also help MadDogMurdock concerns about people don't really caring about it.

Did I went too far?
 
Do i understand you correct to bypass the USS generation idea,
and instead have a dynamic mission to be spawned while you are in the system,
with a directly "uncovered" mission marker?
 
Do i understand you correct to bypass the USS generation idea,
and instead have a dynamic mission to be spawned while you are in the system,
with a directly "uncovered" mission marker?

Maybe for some types of situations yes. Specially those involving quick action (player/npc under duress, relevant player or cargo). The rest, like materials scattered, cargo drop abandoned, debris, could still be just simple USS.

Remember that USS have to be scanned before you can get to them, and I'm really confused how is this going to work after the first batch of USS has timedout. Do you get another message 'new unknown signal found', then you have to fire up the scanner mode etc?

It would also help getting the info of a player in distress even if you are not in SC but just sitting in an asteroid 2ly away waiting for inspiration.
 
Maybe for some types of situations yes. Specially those involving quick action (player/npc under duress, relevant player or cargo). The rest, like materials scattered, cargo drop abandoned, debris, could still be just simple USS.

Remember that USS have to be scanned before you can get to them, and I'm really confused how is this going to work after the first batch of USS has timedout. Do you get another message 'new unknown signal found', then you have to fire up the scanner mode etc?

It would also help getting the info of a player in distress even if you are not in SC but just sitting in an asteroid 2ly away waiting for inspiration.

So to recap that:
Situations with no imminent threat, as of lost cargo
or already destroyed ships are spawned via USS mechanics.

As soon as there is a time critical aspect, like an assault
or a distress call, the game uses a dynamically generated mission
instead, given by the governing faction of a system, which as of now
fields the police force and law enforcement.
This mission, unlike the USS, will be generated in a set radius of lightyears
around the system, to provide multiple players in multiple systems with
the info and a mission, should they want to join.

Basically that works as a heat map without a visual map layer then,
using on the fly mission generation instead to pique CMDR interest.

Does that work for you guys?

The coming USS changes will be rather unlucky i think,
without exploration modules players need to visit nav beacons.
I'd welcome having a basic discovery scanner to find USS on every ship,
even without having the module installed.

Keep the real FSS stellar analysis however tied to exploration modules.
 
ok, finally have some time to sit down. Lets get a step back and go into the current distress signals with a real example. I chosed to pick up the 'distress signal' of a ship without fuel because this is introduced as one of the revamped scenarios in 3.3.

So, if you go to any NON anarchy system and fly in supercruise around deep space, chances are you will eventually see a distress signal (threat 2). Watch out because some times this distress signal might not be a stranded pilot but some pirates, and sometimes it will actually be the stranded pilots AND some pirates.

So, this is what is going to happen (in theory, my best guess, based on dev experience):
- you exit supercruise following a USS, this instructs the game to start a 'custom minigame' in the form of a finite state machine (FSM).
- one of the states of the FSM will be setup the situation, spawn any ship or dropped cargo, environment, debris etc..
* the spawned ship will have 0 fuel and a custom message list (to welcome you when you come closer).
- front this point onwards, the FSM is finished, and now what happens is driven by the ship AI FSM (every ship has its own too, behaviour and stuff).
- If you don't refuel the ship NOTHING will happen at all.
- If you refuel the ship it will thanks (or not)
- eventually the ship will jump out (and say thanks)
(note, this is a simplification of the FSM, the ship doens't need to have 0 fuel at all, and the trigger even could be just firing a fuel limpet and not a real refueling action, but whatever works is fine).

Thank you very much for your effort. At this point in life we have no idea if this distress signal is already tied into the BGS, and our actions have any effect or not, but that'd be a different discussion.

Prior to 3.3, If you kill the ship the USS will dissapear. If you exit doing nothing the USS will dissapear. If the ship jumps out the USS will dissapear. Actually, the USS dissapeared at the very moment you entered it, because the lack of persistance.

After 3.3, I want to believe if you refuel the ship the USS will dissapear immediately, your client will be instructed to do so (pure guess again, that how I'd expect it to work). So, yeah, either your client saves the USS list locally, or the EDServer is giving back the list when you enter SC or the system again. The list being in the EDServer would be our best case scenario, because that means the FSM is aware of the 'goal' completion and informs the EDServer to remove the USS from the list. Worst case scenario, your client is managing it (will be probably stored somewhere close to the market data you buy from the galmap, etc.), we will see.

What we already know is that this USS is unique to you and therefore (this is important) even if someone joins you, other players DO NOT exit SuperCruise using the USS signal (and therefore firing up the FSM again) but following your low wake or beacon. At this point you are responsible for the instance, you are responsible for the FSM. If another player joins your instance, they will spawn the ships you instruct them to do, they will get the text messages you send to them as owner of the instance. The ship is not going to talk on their clients, it is being controlled by you. Really need to understand this, because this is relevant later during our 'player generated signals'. THEY ARE NOT AWARE there is a FSM running in the instance, only the client creating the instance knows this and controls the FSM, all client side.

So, lets assume, I ran out of fuel and somehow, I can forward this distress to another commander that joins my instance.. in my instance there can be NO FSM running, or a FSM that has nothing to do with refueling (a RES for example) or several FSM running because of different situations I (as instance owner) created.

For the new player coming to help there has to be a custom FSM on his side (an example could be a mission FSM) to take care of my distress signal, the different states of the FSM can help the EDServer to manage the different USS being created (e.g. under certain conditions, just delete the USS for everyone else, remove it from the pool, whatever). I really believe, with a custom FSM the load on the servers can be easily countered and actions can be taken to inform other players. (e.g. a degraded emissions threat 0, can turn into a degraded emissions threat 1 if a player enters the USS). This NEW type of FSM doesn't have to spawn any ship or cargo or materials because you are already entering an existing instance, however it can still inform the EDServer about events, specially in case the instance owner leaves and needs to transfer control to you.

So, quick recap on what I'm suggesting, you exist SC following a USS or a mission USS (from inbox mission generation), in both cases you as the new coming player you fire up your FSM on an existing instance with already defined objectives: refuel a ship, pick up some dropped cargo, repair a ship, and these 'objectives' can be rewarded as part of a normal mission FSM through the 'onsuccess' state.

Now, assuming (I'm the stranded pilot) and I get attacked before you arrive (either other player or an NPC), when I die, my FSM can send the required data to the EDServer for a 'critical mission update' objective change, and this info (as a new FSM state) can create the necessary items in the space for you when you enter the new instance you will create (dropped cargo, ship debris, materials). So you can no longer refuel or repair me, but you can still scavenge the spoils.

Without a mission or objectives, MacDogMurdock is somehow right, who is going to care about a distress signal that has little to no rewards (for the AIDING player), and having a mission still makes sense from a Lore point of view.

Now, from my point of view, as a gameplay loop, ideally I'd like to create a distress signal for a local faction (friend or allied that I know they will try to help me), e.g. the fuel rats, or my local faction close by. People 'linked' to that faction or a SuperPower or whatever system used to OPT-IN/OUT of this content would get a mission from the Faction I requested help from, or the police. So fuel rats will get missions from the Fuel Rats faction, that on completion will also help their faction. I can sneak OPT-IN and pick up the mission for nefarious purposes too, nothing will prevent that. Getting missions from the police could also add a new module like 'police radio scanner' or whatever other gameplay loop you want to add. Also, remember Stealthie brought up the Pilots Federation, I assume they could as well help creating this critical mission/uss whatever.

One of the main problems I can see is when two players join this newly created instance (remember what I said before it is important). They both get into the instance following a USS that will fire up the FSM on arrival. Still only one of them will be the owner of the instance, but if the FSM has to create space assets, then the cargo or space debris might get duplicated (exactly the same thing that happens with the Wake Scanner dup issue), but I'm sure in 2018 we can work out a technical solution for this. The FSM needs to be aware of the existing instance, or a different FSM can be necessary for the two cases: you join a new instance or you join an existing instance.

Let me know if this highlights any possible tech challenge and clarifies a system that might work. I'm not sure I can explain myself very well, specially with technical stuff when trying not to use technical langauge.

Finally, as a side joke while I was checking my functions panel:
d02EWRA.png
 
Last edited:
I'm not sure what ilo thought I said, but I'm not sure I was worried about whether players will respond, but what will happen if they do.
I was more just thinking out loud about sharing player locations from normal space into SC.

This might actually be considerably simpler than it looks - at least for an initial generation of extra USSs.
Think about how friends and wings work - the game tells you where they are at all times, because you've selectively chosen to see them.
The reason you don't see any indication of other players isn't because the game doesn't know, but just because there's no indication that the game should show you.

So, based on the game knowing where everyone is, this just becomes a display issue in SC.

We can ignore player presence at named sites, such as planets, stations, and specific space POIs such as Res Sites and CZs. Their indication in SC and the Nav Panel doesn't need to change.
It's the additional presence of players in unnamed locations in normal space due to them dropping into a USS or having done an interdiction or having been interdicted.

What already happens when you jump into a system:
- Generate all planetary bodies
- Generate all stations and infrastructure
- Generate all fixed POIs such as Res Sites, CZs, etc.
- Generate the set of USSs (however that works in the new system)

And now the extra step:
- Generate an extra set of 'player' USSs based on the presence of any players in the system, who are at unnamed locations - the game knows where everyone is, so this doesn't seem like a stretch.
- Give the new USSs an appropriate type to identify what might be going on there.

The display and detection of all those items would work however it works within the new FSS based system.
And again, instancing only matters when a player tries to drop in to one of these 'player' USSs.

That at least deals with their initial generation - I'd worry about trying to make their types evolve as a second step.
 
Last edited:

There is no point in showing everyone's location in SC as USS, that in fact might counterproductive. what we ideally want is a system with closed loops, a reason for an USS to spawn and a way to track down what is happening with the associated gameplay. I don't want to show my location to everyone or just to someone, I want to send a distress signal for a reason, or I want to system to send a mission/goals to another player for something that I did, not something that I'm doing. I want gameplay, not presence, I'd be happy if when I jump back to SC after killing something a USS for degraded emissions shows up in case I left materials or cargo, and this example has nothing to do with where I'm at any moment.
 
So after reading through your wall once and looking at the core aspects again,
i think this is what needs to be done to get it running.
Correct me if i am wrong.

1. Define triggers to create an event and define triggers that modify the event the player client keeps track on. (also tie in the stages and type of USS/Missions in here)
2. The events need to communicated and tracked by a "trusted authority" such as the ED server.
3. The server takes that info and creates a USS accordingly as the "destination" of where the action is.
4. Other players get a mission offer, to notify them of the ongoing event in the vicinity, by the edserver communicating with the mission server.
5. The mission leads the player to the player USS. (Option 1 visible mission target USS / Option 2 look for the prioritized USS via the new mechanics in 3.3)
6. The player accepting the mission then keeps track on what he does in the mission and is communicating triggers, changes and solving of the situation to the mission server,
which will send notifications and updates to the edserver.
7. Later that could be broadened to tie in dedicated player groups, that can affiliate their squadron to a specific gameplay aspect, like search and rescue, fuelrats or such.

Basically we have twofold comms going on.
The creator and owner of the USS instance, the one starting it,
communicates USS related stuff with EDservers.

Players joining in are communicating with the mission server,
and upon entering with the owner of the instance.

Between the servers there also is communication,
to keep track of the status of USS and if the instance needs to be
transferred in ownership, as the original creator left.

Correct?
 
Back
Top Bottom