Game Discussions Star Citizen Discussion Thread v12

VR Golgot

VR Golgot
MouthOfSauron said:
There is alrady a persistance layer (P-Cache) but the design of this is server driven but there is no guarantee that you can get back to the server you crashed, so this is persistence session based (only few data is global like ships you own or the money you have). The other problem of P-Cache that it sits directly on top of the database which does make sharing a complicated manuever when you introduce multiple servers handling one player. This system was good enough for AC or SM but it totally failed for PU and its requirements (super fast access to player data but data is still persistent between sessions). The solution to that is now the icache - a in memory database front end, that holds the data needed and a async backend that writes changed data back to the conventional database.

Servermeshing is their idea to share the workload so that the ONE SERVER for ONE VERSE is gone (which is quite a big blocker when you reach the capacity of that one server). Their idea is to use many small services that are bundled together and do the server stuff. These need to share data primarly via icache (which is already a global instance). With icache the problem shifts away from the "sharing data problem" to the "control of data problem" (having multiple servers running that are needed to virtually drive one player means, that you must control somehow which server has the lead for some particular data scheme (and is doing the updates vs. icache or you soon found yourself in a very complex locking system to avoid concurrent updates). If a different server needs a change, he must communicate it thru the lead server which than can do the update. Having a control layer for every service that exists and you can build your meshing dynamically as you can distribute the workload freely and you still can do updates vs the back end.
Click to expand...

So to summarise:

  • The current persistence system used for the PU isn't fit for purpose.
  • The improved version is nowhere to be seen. (Despite being supposed to arrive mid 2020).
  • It will be a better fit for Server Meshing. Which is also nowhere to be seen. (Despite being supposed to arrive in Q4 2018).
  • It's 2021.

I'm no expert on game dev, but as a design approach, this would seem to be:

MouthOfSauron said:
Mostly wrong on every thing.
Click to expand...
 

kilvenny

kilvenny
FD's decision to always online was a last minute decision, My impression was they thought that stellar forge could be on the client but in the end its server side forcing the always on line with the advantage they can tweak server side without pushing a new client. I imagine that also reduces the download sizes of updates. P2P was not, at that point they had no idea how successful ED would be so they went for the cheapest option. I remember early on them having problems with stations (docking) and having to actually have some server authentication.
 

Agony_Aunt

Agony_Aunt
Wotthe ens said:
I believe ED's p2p connection was long planned and key to their route to release, but I seem to remember they talked of unforeseen issues arising when they went live with alpha, something to do with the quadrillion different routers everyone has.
Click to expand...

That's quite possible. Which is why its generally a good idea to make sure you can actually deliver on something before asking people for money for it, or selling virtual spaceships for it.
 

Surefoot

S
Wotthe ens said:
I believe ED's p2p connection was long planned and key to their route to release, but I seem to remember they talked of unforeseen issues arising when they went live with alpha, something to do with the quadrillion different routers everyone has.
Click to expand...
That's one of the main flaws of p2p, it relies on each client connection. Also it doesnt scale with players in the same instance (the traffic increases exponentially). That's why i disagree strongly with this architecture, for a real time massive multiplayer game. It's quick and easy to implement, and fits the budget and small team of FDEV at the time, so it's a fair decision i guess from the management as they did release successfully. But "massive multiplayer" it's not (it's "asynchronous multi" if you want, your actions are indirectly seen by the other instances) but that's it. And i maintain my last minute addition, that presentation linked by MoleHD (which i had seen too) strongly reinforces that argument, they really did it to save time and budget: this means it's not the core of the game design (which is something you pitch to producers when you want a budget..) - it's peripheral, and honestly they are maybe right as it was thought mostly as a solo game (as power play was a complete afterthought too, lets be honest, i still believe they are talented, so that cannot come from them as a really thought out process). Core elements of the game design were clearly the Stellar Forge, VR (definitely thought out from the game concept), flight mechanics carried over more or less from the previous Elite iterations, the trading system (also carried over), and of course iconic stations with the mail slot.

Dual Universe by contrast is centered around its network code, it's a core element. It should be for SC too, since a lot of things were promised back then, and with that kind of pitch one would tend to start with a really strong and innovative multiplayer network engine, and then build around that (and of course bartender AI and fluid physics for your glass of wine would come much much later in an expansion maybe)... That shows the difference in management of priorities between these companies.
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom