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

Ahoy there,
i think a lot of the trouble with how the game is presented is homebrewed.
The devs have all necessary tools at hand, to correct the most obvious flaws.
They have USSes and wing beacons, the ability to spawn NPCs tied to the BGS states
and can change the cargo lists of NPCs, while also tracking cargo transactions.

It sure is a lot of work to tune and test that, but very possible.

Example:
A player interdicts a ship, then assaults the ship.
Whether the target is a NPC (non wanted) or a player with report crimes on,
the game then should create a USS, in case of the NPC that can be found with the new exploration scan method,
stating a distress call - weapon fire.
In case of a player it should create a likely named "wing beacon", displayed to all players in the instance,
assuming they are in a wing, even if they aren't.

Should the ship be disabled as the encounter progresses, checking if drives and/or powerplant are intact,
it discards the old USS/Wing beacon, but keeps the entity ID of the object in the SC-instance
and just reworks the displayed name into "distress call" as the ship requires aid.

Should the ship be destroyed, it changes to combat aftermath and later into degraded SS or other USS types fitting the ship type.


This rather simple change would instantly make the game way more dynamic and believable,
as IMO the most problematic part of the "living, breathing galaxy" is that it is presented stale and static.

Regarding NPC cargo, it should more closely tie to the info, the system map gives,
and preferr to spawn ships with cargo fitting the production and demand of the system,
yielding a direct bgs influence per ton of ware stolen as a transaction (hatch breaker triggered ejection or jettison).
Since BM transaction changes influence of minor factions, by reinforcing criminal markets,
or decreasing the security state of a system, bypassing the cops selling stolen goods,
that part should stay as is.

However, a system that is known to produce or harvest special high value items,
should have a decent percentage of those onboard of NPCs, to create "hotzones"
that by themselves create hubs of crime and police/bounty hunter action in response.

Lastly NPCs jump around without a real destination, that is disturbing and can be adressed
by lightweight flightplans, based on the trade data traderoutes.

I hope i could lay out my concerns with the game, and what i'd like to see
improve BGS wise, to create a better game for all.

------------------------------------------------------------------------------------
Edit - Proposal of how communication could work:

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.

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,
if that is possible.

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.

--------------------------------------------------------------------------------------------------
Edit 2:
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


What about you?
Do you see the same problems at the core gameplay?
 
Last edited:
Hmm.

So an individual player does x in instance y. The BGS then takes that action, and rather than just update the stats from instance x into the BGS as one of a huge number of possible changes to the faction system, it generates new missions in that same system for ... other instances? All instances? Your instance?

Hmm.

Don't get me wrong, I like the idea of the knock on effects. But to WHO? You? Or the BGS and all other instances? I suspect it's tricky to do.
 
Hmm.

So an individual player does x in instance y. The BGS then takes that action, and rather than just update the stats from instance x into the BGS as one of a huge number of possible changes to the faction system, it generates new missions in that same system for ... other instances? All instances? Your instance?

Hmm.

Don't get me wrong, I like the idea of the knock on effects. But to WHO? You? Or the BGS and all other instances? I suspect it's tricky to do.
To make it possible we need to assume this:

The player who first enters a new instance, namely a system,
is the owner or manager of that system.
As long as he is in, and the instance player limit is not met,
other players are added to this particular instance.

For this change to work and to not overly generate traffic,
it would require to limit the USS/Beacons to the existing instance.

When the owner leaves the instance, via high wake, the instance
is transported to another player, who assumes the role of owner/manager,
with preserving the states and generated USSes.

Regardless of the USS/Beacons the BGS transactions are communicated
to the BGS server and added to the stockpile to take effect at the next tick.
 
I guess what I'm saying is

Should the ship be destroyed, it changes to combat aftermath and later into degraded SS or other USS types fitting the ship type.
Who would see the complex joined up sequence?
 
I guess what I'm saying is



Who would see the complex joined up sequence?
All in the instance shared with the player who does the deed.

If you have 2 instances @ 20 players each, the USS/Beacon will only
be shown in instance A if the player doing the deed is in instance A.
 
To make it possible we need to assume this:

The player who first enters a new instance, namely a system,
is the owner or manager of that system.
As long as he is in, and the instance player limit is not met,
other players are added to this particular instance.

For this change to work and to not overly generate traffic,
it would require to limit the USS/Beacons to the existing instance.

When the owner leaves the instance, via high wake, the instance
is transported to another player, who assumes the role of owner/manager,
with preserving the states and generated USSes.

Regardless of the USS/Beacons the BGS transactions are communicated
to the BGS server and added to the stockpile to take effect at the next tick.
Hmm. I would love to hear from devs who know a lot more about this than us, but I'm leaning towards a [woah] reaction if one did ;)

It's an interesting idea though
 
Hmm. I would love to hear from devs who know a lot more about this than us, but I'm leaning towards a [woah] reaction if one did ;)

It's an interesting idea though
I have been asking for connected gameplay for a long time,
I'd be happy to hear something from the devs, too.

Additionally i have strong hopes for the codex generating player interest on it's own,
but that is player to player only, as i understand it.

I'd love to see other things like an explorer heading to base selling his data
and the BGS tick creating News about new ressource nodes in system X,
generating a survey mission for miners.
 
To make it possible we need to assume this:

The player who first enters a new instance, namely a system,
is the owner or manager of that system.
As long as he is in, and the instance player limit is not met,
other players are added to this particular instance.

For this change to work and to not overly generate traffic,
it would require to limit the USS/Beacons to the existing instance.

When the owner leaves the instance, via high wake, the instance
is transported to another player, who assumes the role of owner/manager,
with preserving the states and generated USSes.
My understanding is that SC and normal space are separate instances.
I think the basic idea could work because of that.

The event caused by the player in normal space creates a USS in all SC instances.
That USS could evolve based on updates from the player in normal space.

Then if a player in SC responds to that and tries to drop-in matchmaking rules apply.
If they are allowed to join the player they do - e.g. both in Open
If they can't instance together the SC player gets the equivalent NPC encounter instead - e.g. one player in Solo

Either way, it enriches all modes for all players by responding to what all players are doing in all modes.
I imagine busy systems could generate a lot of player-driven USSs.
 
My understanding is that SC and normal space are separate instances.
I think the basic idea could work because of that.

The event caused by the player in normal space creates a USS in all SC instances.
That USS could evolve based on updates from the player in normal space.

Then if a player in SC responds to that matchmaking rules apply.
If they are allowed to join the player they do - e.g. both in Open
If they can't instance together the SC player gets the equivalent NPC encounter instead - e.g. one player in Solo

Either way, it enriches all modes for all players by responding to what all players are doing in all modes.
I imagine busy systems could generate a lot of player-driven USSs.
I do not fully know how the game handles leaving SC and entering normal cruise,
it is all based on my experience as a player, but that would work, too.
After all the goal is to enrich the world and make it palpable.

We have some ressources freed up with moving the mission server off,
don't we ? :D

To add on that RNG made something weird a long time ago.
I was in normal cruise close to a planet and shot an NPC.
The debris, which i followed down to the planet, hit surface
and generated a POI with a scannable datacore.

Sadly that was not a function of the game, but pure coincidence.
I'd love to see something like that.

Even for PvP wing on wing combat there would be a hook here,
laying out the criteria of at least 4 vs 4 to generate a CZ POI in space,
with hopefully ties to the bgs based on squadron pledge.
 
Last edited:
I agree a dynamic follow-on sequence in terms of what the BGS generates would be interesting. I'd maybe go a formal route of suggesting it as a change to the devs rather than just in Dangerous Discussion forum though.

I imagine it would be a significant body of work, similar to what Adam Bourke-Waite explained in terms of the new Q4 BGS changes to states. I wonder if the THINGS they are working on for the next expansion might be seen by Fdev as a better use of the dev time.
 
I do not fully know how the game handles leaving SC and entering normal cruise,
it is all based on my experience as a player, but that would work, too.
After all the goal is to enrich the world and make it palpable.

We have some ressources freed up with moving the mission server off,
don't we ? :D

To add on that RNG made something weird a long time ago.
I was in normal cruise close to a planet and shot an NPC.
The debris, which i followed down to the planet, hit surface
and generated a POI with a scannable datacore.

Sadly that was not a function of the game, but pure coincidence.
I'd love to see something like that.

Even for PvP wing on wing combat there would be a hook here,
laying out the criteria of at least 4 vs 4 to generate a CZ POI in space,
with hopefully ties to the bgs based on squadron pledge.
Instancing is about players, not locations.
E.g. If nobody is at Jameson Memorial - there aren't any instances of it.

An instance gets created when a player jumps or drops into a particular location.
Other players only join that instance if matchmaking allows it, otherwise they create a new one.

On that basis, SC and every normal space location in a system create different instances whenever a player is the first one there.
 
I think FD is working their way to something as dynamic as described.

We have weekly BGS ticks. Now we'll have daily objectives, so a sort of daily BGS ticks. Soon(TM), we'll get to near real-time.

In terms of connectedness and cascade across platforms and instances, additional work could be done to deliver the type of dynamics described.

Example: My dropping into a Pirate Activity Detected USS could appear as a USS for another player dropping to the system and doing a FSS. And then dropping in to the USS will match the player into my instance.

The new backend changes seem to make the above easier to deliver.
 
So this pretty much breaks down and fails in, say, a CG system where there are 100+ players.

The concept, at its core is good, but the mechanics leave too much to be desired. The notion of creating signal sources, which we already do to some extent (namely our wakes, High or Low), and the Wing Beacons, if we're using them. It really shouldn't be THAT complicated to simply spawn a standard signal source at the site of a player instance that could be detected and visited by others though.

Of course, if you're the creating player on Can-and-String-Net, patched through a VPN spanning the Atlantic... I know I don't want to drop into that instance and see your every 31st frame. That crap is the #1 reason I avoid Open like a festering lot lizard.
 
I think FD is working their way to something as dynamic as described.

We have weekly BGS ticks. Now we'll have daily objectives, so a sort of daily BGS ticks. Soon(TM), we'll get to near real-time.

In terms of connectedness and cascade across platforms and instances, additional work could be done to deliver the type of dynamics described.

Example: My dropping into a Pirate Activity Detected USS could appear as a USS for another player dropping to the system and doing a FSS. And then dropping in to the USS will match the player into my instance.

The new backend changes seem to make the above easier to deliver.
To correct you BGS ticks daily.
The above mentioned assets are there,
and as i see it, most work goes into flashyness,
a.k.a. UI and module presentation.
I miss a dedicated "mechanics" series of expansions.

So this pretty much breaks down and fails in, say, a CG system where there are 100+ players.

The concept, at its core is good, but the mechanics leave too much to be desired. The notion of creating signal sources, which we already do to some extent (namely our wakes, High or Low), and the Wing Beacons, if we're using them. It really shouldn't be THAT complicated to simply spawn a standard signal source at the site of a player instance that could be detected and visited by others though.

Of course, if you're the creating player on Can-and-String-Net, patched through a VPN spanning the Atlantic... I know I don't want to drop into that instance and see your every 31st frame. That crap is the #1 reason I avoid Open like a festering lot lizard.
Are you referring to the existing mechanics,
or the proposed changes/weaks?
If the latter, yeah i failed to understand the absence of it,
since "wings" hit the servers.
 
The idea is not only incredible good, but also highlights some of ED current gaps: closing the gameplay loops.

The challenges are quite a few tho, starting with blocked players, instancing issues and gameplay speeds. I'm still trying to find out why the ships don't use the beacon for anything else than wings, and even then still has its own issues.

Also, during an instance there are a few moments where the client talks to the EDServer, it really needs an event. Just being shot at is not one of them. Getting a fine, a bounty or whatever player action that generates a permanent outcome is. I'm trying to bring up the fact that the EDServer is not very much aware of what is going on. Without entering into details about the role of the EDServer and the instance generation, your approach is good by limiting the info to the player's instance.

Another thing we don't know how will work is the 3.3 USS generation system. We know it will now generate a bunch of USS when entering SC or a system, and those USS will have a timer, but then we have no idea what is going to happen after.. will they be a regen random call to add more USS signals if I keep flying 40 minutes in SC? or do I have to exit/enter SuperCruise again to make this regen work? This 'minor issue' is also related to the fact that unless there is an event going on any of the clients, the EDServer might not be aware it has to update other clients with information.

Additionally, some info is not really tied between the transactional server and the EDServer, so it might not be as easy to share initially, but for sure it can be done (technically).

With all that background, and considering most of ED is happening client side, the less interaction we add to the server side will definitely help selling the idea. Now, here comes the dilemma: if I get shot in an instance, there is no way I can alert any ship in SuperCruise because that is another instance. The 'weapon fire' does not generate an event, but the ED Client can be changed for that easily or the beacon could have this functionality set to manual: send a distress beacon, make the beacon public. However, a fire event happens in a normal-speed instance, what instances of SC have to be informed and under what conditions?

If we can forget about the realtime 'informing' of SC, but still have the 'degrade emissions' and the location considered as the next USS to generate having a higher priority in the pool instead of getting one from the random pool at all (this is considering there is a refresh on USS signals in SC) then we could have something. However, how is this managed in a RES? a res may have already 4, 7, 10 distress signals from NPCs or players, maybe more.. How to differenciate on the server side whether to generate one or 10 signals add some terrible logic to the system, and then how/when show them to the SC instances.. that is a hell of coding and decission making.

I like your idea, but I think the overal ED needs some more work to accomodate something like this.
 
To correct you BGS ticks daily.
The above mentioned assets are there,
and as i see it, most work goes into flashyness,
a.k.a. UI and module presentation.
I miss a dedicated "mechanics" series of expansions.



Are you referring to the existing mechanics,
or the proposed changes/weaks?
If the latter, yeah i failed to understand the absence of it,
since "wings" hit the servers.
The proposed change. The 20-player limit would get nuked in a CG system, or in other regularly inhabited systems (Shinrarta, that Li Yong place I forget the name of, Cubio, and wherever people think they can fast-track credits or rep this week).
 
The proposed change. The 20-player limit would get nuked in a CG system, or in other regularly inhabited systems (Shinrarta, that Li Yong place I forget the name of, Cubio, and wherever people think they can fast-track credits or rep this week).
The 20 player limit was just an assumed limit, to portrait the function.
With increasing player numbers the data that is necessary to be communicated needs to be added up,
but the same does the mission board in each mode currently.
Otherwise you would not see the same missions as players not in a wing
on the same station, at the same time, right?
 
  • Like (+1)
Reactions: ilo
The idea is not only incredible good, but also highlights some of ED current gaps: closing the gameplay loops.

The challenges are quite a few tho, starting with blocked players, instancing issues and gameplay speeds. I'm still trying to find out why the ships don't use the beacon for anything else than wings, and even then still has its own issues.
Thanks, i wondered about beacons aswell, since the player activated distress call got removed.
Basically back then it was a refuel on a premium cost, not quite what was thought it would be.

Also, during an instance there are a few moments where the client talks to the EDServer, it really needs an event. Just being shot at is not one of them. Getting a fine, a bounty or whatever player action that generates a permanent outcome is. I'm trying to bring up the fact that the EDServer is not very much aware of what is going on. Without entering into details about the role of the EDServer and the instance generation, your approach is good by limiting the info to the player's instance.

Another thing we don't know how will work is the 3.3 USS generation system. We know it will now generate a bunch of USS when entering SC or a system, and those USS will have a timer, but then we have no idea what is going to happen after.. will they be a regen random call to add more USS signals if I keep flying 40 minutes in SC? or do I have to exit/enter SuperCruise again to make this regen work? This 'minor issue' is also related to the fact that unless there is an event going on any of the clients, the EDServer might not be aware it has to update other clients with information.
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.

Additionally, some info is not really tied between the transactional server and the EDServer, so it might not be as easy to share initially, but for sure it can be done (technically).

With all that background, and considering most of ED is happening client side, the less interaction we add to the server side will definitely help selling the idea. Now, here comes the dilemma: if I get shot in an instance, there is no way I can alert any ship in SuperCruise because that is another instance. The 'weapon fire' does not generate an event, but the ED Client can be changed for that easily or the beacon could have this functionality set to manual: send a distress beacon, make the beacon public. However, a fire event happens in a normal-speed instance, what instances of SC have to be informed and under what conditions?
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.

If we can forget about the realtime 'informing' of SC, but still have the 'degrade emissions' and the location considered as the next USS to generate having a higher priority in the pool instead of getting one from the random pool at all (this is considering there is a refresh on USS signals in SC) then we could have something. However, how is this managed in a RES? a res may have already 4, 7, 10 distress signals from NPCs or players, maybe more.. How to differenciate on the server side whether to generate one or 10 signals add some terrible logic to the system, and then how/when show them to the SC instances.. that is a hell of coding and decission making.

I like your idea, but I think the overal ED needs some more work to accomodate something like this.
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?
 
  • Like (+1)
Reactions: ilo
I agree a dynamic follow-on sequence in terms of what the BGS generates would be interesting. I'd maybe go a formal route of suggesting it as a change to the devs rather than just in Dangerous Discussion forum though.

I imagine it would be a significant body of work, similar to what Adam Bourke-Waite explained in terms of the new Q4 BGS changes to states. I wonder if the THINGS they are working on for the next expansion might be seen by Fdev as a better use of the dev time.
After all the years, i think discussing the first iteration of a suggestion in discussions first,
is the best way to go, to get a lot of people on board adding their thoughts and feedback.
Suggestions is a barren land and the ultimate destination of a proposed change.

"Statistically" from all the positively received ideas, none in the suggestion forums
made it throught, to get devs attention.
 
  • Like (+1)
Reactions: ilo
Top Bottom