Game Discussions Star Citizen Discussion Thread v12

Just now

1678762893054.png
 
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?

They have many! Surely you remember "Death of a Spaceman", the mining one that indicated the plan was for people to sit in the refinery doing nothing until something was actually mined, and who can forget the sublime mixmaster gameplay for NPC passengers and choosing the in-flight movie!
 

Viajero

Volunteer Moderator
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.
Oh I agree. Just that there are some who couldn’t even acknowledge SC as any kind of release, not even EA.

The implications are that, as many other released EA games out there, SC could be subject to widespread game critic reviews and scores; especially given that it has been sold and monetized for more than a decade.
 
Last edited:

Viajero

Volunteer Moderator
Great post :)

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.

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 ;))

Even worse. The client-server-network headroom isn't apparently enough for what they have now, let alone what else they plan to add in the future. Server mushing won't help with that unless they are spinning up new servers for every few clients, and that would cost a lot!
 

Viajero

Volunteer Moderator
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 ;))
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 ;))

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…
 
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?
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.


I'm not a game developer and this might sound stupid but with CIG you've got to double check these things. Have they checkd if the cable reached the server rack?
 
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.
 
Last edited:
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.
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.
 
Back
Top Bottom