These games could serialize their state into less than 1k if someone on the team cared enough.
Ahh - but how many fidelities fit into 1 kilobyte?
These games could serialize their state into less than 1k if someone on the team cared enough.
The what now?
Thinking about it, if they ever DO get around to writing a design document, will they invent another new never-been-done-before high-tech name for it so it sounds groundbreaking?
No, it's not. Still a turd with lot of game breaking bugs.One thing though Cyberpunk 2077 is nowadays a good game.
No, it's not. Still a turd with lot of game breaking bugs.
Regardless if I understand game development or not, a turd is still a turd.You're clearly just a hater who doesn't understand game development. Buy a... erm....Rayfield Aerondight S9!
Oh I agree. Just that there are some who couldn’t even acknowledge SC as any kind of release, not even EA.Christ Roberst probably left the design document as a trust for his great grand children to complete the game with all the hand waving to explain how game mechanics and physics works.
'Early Alpha Access' that's been available for nearly a decade? I don't think there's anything early about version 3.18.
Parody becoming real. I swear this biowaste writes itself:Indeed. The patch is so good that it looks broken.
Regardless if I understand game development or not, a turd is still a turd.
For Star Citizen, you were pretty close to Dude Everyman in theory until fairly recently, at least as far as on-disk state goes. The addition of damage maps to ships requires that map to get saved (while just a texture, it's a lot more than they had before), and the recent feature of persistent littering means you've got a bunch of penguins with x,y,z,parent coordinates to dump into your favorite spatial data structure somewhere. That's really not much state per user though, maybe it sounds cooler when Chris talks about it, but I have more labels placed on a hiking website's map than I have penguins on planets, and the cost of these features is similar.
Great post
They seem to have a load more planned though. Say the externally accessible ship modules + 'physical damage' system (where materials gain different densities and affect projectile penetration etc). Suddenly the state of every open/closed/damaged panel becomes important etc. (Not just as bonus data, but as something that has to be networked etc too).
Or the 'room system' governing not just atmospheric state as it does now, but propagation of gases / fire etc, and presumably that's a lot of states in relatively rapid flux.
The massive server hit occurring when large ships load up with the new 'physicalised cargo' also suggests issues there, although more in the performance realm. (Presumably there are non-fidelitious savings to be made: IE just save them as number by type, set them to a default position on the 'cargo grid' regardless of placement, and turn off physics once they're placed etc.)
I don't understand this crap at all, but something tells me that client & server headroom ain't big enough for all the stuff they've got planned. Certainly ain't gonna help if the new data system poops the bed while queuing all the data back and forth. (In an attempt to resolve the latter problem of course )
La première ligne est déjà superbeThis french article about the 3.18 features is chef's kiss, hope Google Translate will make a good job...
Lasting Legacies : Star Citizen Déploie Ses Nouveaux Bugs Tant Attendus Avec Le Patch 3.18 - NoFrag
Cela fait un moment que nous n'avions pas fait d'article sur Star Citizen, la fameuse simulation de froissement de draps et de cafés de l'espace, créée parnofrag-com.translate.goog
These plans are never gonna happen with this engine, team, management and design concept. Ship is hit, generates a vent gas effect and gets hole decal. That's what they can maybe pull off.Great post
They seem to have a load more planned though. Say the externally accessible ship modules + 'physical damage' system (where materials gain different densities and affect projectile penetration etc). Suddenly the state of every open/closed/damaged panel becomes important etc. (Not just as bonus data, but as something that has to be networked etc too).
Or the 'room system' governing not just atmospheric state as it does now, but propagation of gases / fire etc, and presumably that's a lot of states in relatively rapid flux.
The massive server hit occurring when large ships load up with the new 'physicalised cargo' also suggests issues there, although more in the performance realm. (Presumably there are non-fidelitious savings to be made: IE just save them as number by type, set them to a default position on the 'cargo grid' regardless of placement, and turn off physics once they're placed etc.)
I don't understand this crap at all, but something tells me that client & server headroom ain't big enough for all the stuff they've got planned. Certainly ain't gonna help if the new data system poops the bed while queuing all the data back and forth. (In an attempt to resolve the latter problem of course )
Great post
They seem to have a load more planned though. Say the externally accessible ship modules + 'physical damage' system (where materials gain different densities and affect projectile penetration etc). Suddenly the state of every open/closed/damaged panel becomes important etc. (Not just as bonus data, but as something that has to be networked etc too).
Or the 'room system' governing not just atmospheric state as it does now, but propagation of gases / fire etc, and presumably that's a lot of states in relatively rapid flux.
The massive server hit occurring when large ships load up with the new 'physicalised cargo' also suggests issues there, although more in the performance realm. (Presumably there are non-fidelitious savings to be made: IE just save them as number by type, set them to a default position on the 'cargo grid' regardless of placement, and turn off physics once they're placed etc.)
I don't understand this crap at all, but something tells me that client & server headroom ain't big enough for all the stuff they've got planned. Certainly ain't gonna help if the new data system poops the bed while queuing all the data back and forth. (In an attempt to resolve the latter problem of course )
Maybe it'll be a design document-ary when the project failed like that time they showed up to citcon without something unfinished or something (was it SQ42?) and showed a little behind the scene documentary instead.The what now?
Thinking about it, if they ever DO get around to writing a design document, will they invent another new never-been-done-before high-tech name for it so it sounds groundbreaking?
Complex. Pishposh. Every man has inventory and a gun. Nothing complicated about that. And the 6000 cups I hid under Mole's bed are quite simple. too.The funny thing is, if they messed up the implementation in a particular way, having "previous snapshots" available won't do much. In order for snapshots to be valuable as a point of recovery, they need to be consistent as well (i.e. not contain nonsense data). This is not something that relies only on the fact that snapshots were made.
This is where the complexity of what they are trying to do lies - in making sure that a bunch of complex state that is modified by thousands of users and updated in real time does not devolve into a furball of complete nonsense.
It is very easy to maintain "large" state. It is very complex to maintain complex and ever changing one if it is done in a distributed system, regardless of the size of the data.
As always, I have zero confidence that CI thought about anything beyond the most naive happy path.
When Chris’s developers and artists asked him “What’s our budget to work with?” He thought they were taking about money, and replied “Infinite.” He never even considered having a budget for graphics triangles, bandwidth, data, server side resources, client side resources, etc…