Star Citizen Dev Response – Chad 2.0
e have had Lead Gameplay Engineer at Cloud Imperium, Chad McKinney, answering a load of questions across multiple threads on Spectrum about various gameplay and development over the last few hours and I wanted to go over them.
Are we getting a better missile & ship item equipping system?
This whole flow is going to get reexamined with the move to physicalized inventory, by the actor team. I don’t want to speak too much for them on the design direction, but there is movement here.
There’s a lot of ways we could go about making large collections easier. We could group them by type, allow fuzzy search, player based priority, etc.. That said most players in the game don’t have so many ships where this has been high priority enough to push on yet. That said ASOP/Hangar behavior is something we’re looking at revisiting, and so your feedback is welcome!
Vending machines… will they work someday?
Work has been done on Vending machines for things like the prisons, and there’s more work to come as well for general vending machine behavior. A good option would be to add persistence of items in the ships, so we can leave water and food stored in our ships This already works with some bugs.
What will current CPU optimization Work actually do?
Broadly speaking the game is highly multithreaded, by far the most multithreaded game I’ve worked on, and yes more cores will perform better. This will also improve as the game develops as we’re constantly pushing the game to work more in parallel. That said the improvement won’t map linearly to number of cores.
There was a thread talking about Agile Development (the short term sprint type of development that SC uses) that Chad Responsed to:
I don’t consider myself an expert in project management theory, so I may not be the best to answer this in the broad, but I can speak to my own experience in the industry. To date all the projects I’ve worked on have all utilized some version of agile development. When I began at CIG we did not, however a couple years in there was a big shift to push towards agile, with parts of the company doing either scrum (feature teams) or kanban (content pipelines, like ship content teams). We do have our own twist on things as we divide up the company using what we call Pillars, each with their own director, who report to Chris. That said I’m not sure in the big picture we’ve really evolved agile practices in some novel way, but again I’m not an expert in this domain.
There was some clarification of Traveling between Server Meshes:
A particular mesh of servers (what we refer to as a shard) is completely enclosed from each other, and you cannot automatically transition from one shard to another. They are independent simulations, with their our view of the persistent state of the world.
There were a series of questions asking when will getting disconnected from the game mean that we can reconnect without losing our ship and cargo and character persistence?
With icache and global persistence we’ll be maintaining server/shard histories beyond the lifetime of the servers, and this will allow us to do things like full recovery after a server crash. This may not be part of the first roll out of the system, but it is something we’ve been keeping in consideration throughout our design and implementation.
As far as freight, in addition to the global persistence/reconnect behavior, we have long intended to have cargo and item insurance to further protect against both gameplay behavior as well as bugs. This is why when we introduced more ship persistence in 3.0 we got ship insurance in the same release, otherwise bugs and crashes would’ve been too punishing. This is also another reason why we introduced the LTP database.
Chad clarified some points of Client Side OCS – Tick Rates and Entity States
Client Side OCS allows us to stream out entities on clients so that they don’t update at all and this does not effect the server behavior whatsoever.. There is a separate entity component update system that handles updating spawned entities, and this allows for many various configurations to optimize performance, including distance to players, player visibility, time ranges, etc…, but this update policy will be the same on the server and client for any given entity component.
More over to this how are the states updated when a player enters an area does this cause snapping or rubberbanding?
The most straightforward approaches will just snap to the server state on the client, but programmers can always make more sophisticated systems that handle things like interpolation, etc…, to make the client behavior look more natural. This is part of the work for the actor network changes. Player movement and animation is something people are highly attuned to seeing flaws in (we are humans after all) and getting it looking natural and fluid is a ton of work. You also have to take into considerations the impact on gameplay, for example your dead reckoning implementation may end up favoring people shooting rather than the people getting shot, where a server discrepancy occurs.