Star Citizen Dev Response Chad Special
Star Citizen and to a Dev Response Special Edition focusing on information from – Chad Mckinney – Lead Gameplay Engineer at CIG.
There is a load of questions here from Spectrum that he answered, but there is a couple that I’ve tacked on from a couple of other threads & devs too.
Did a first basic version of Item Cache and Persistence sneak into 3.10?
As some items persist in ships…
Chad Replied – No, these changes aren’t related to icache, but rather design is using an existing methodology to persist things properly by putting the weapon racks on vehicle itemports instead of loosely placed in in objects containers. ICache and global persistence will allow loose entity persistence globally including in ships.
There was a question How will we spawn when server meshing comes in?
As There’s only a few hundred beds at the stations and cities.
Chad Replied – There’s definitely design questions here, but a few things to consider:
- The universe is very big, and we have more than enough real estate for everyone in the game, many magnitudes more in fact.
- Player Hangars, Habs and Outposts will be a thing, and so not all players will spawn in major landing zones
- Landing zones will have rentable habs that are effectively like loading containers, which are modular so players logging in will get slotted into available space.
- Players can and will continue to be able to log in/out in ships with beds
There was a follow on Question – So if the single “server” is in place while we just have the stanton system, is it not going to happen until such things as player habs and outposts are a thing? Chad went on to say – hangars, outputs, habs, etc… will have to be supported by then, if we soley relied on our current methodology you are correct it would not scale.
Chad Replied again – This is a combination of issues that can happen when the spawn queue is full on the server, usually because of a sudden large influx of spawns because of a streaming event. In our main branch we just introduced parallel spawns which should help this issue, and further down the line we’re going to go further and introduce a better prioritization scheme for situations like this where a particular spawn has a short latency requirement.
There was a thread talking about in game reputation asking about reputation in game and faction exclusive missions/gear, chad responded:
We’re currently working on finishing on the first big push for the new reputation system (server meshing ready and with global persistence!), but it may be a couple quarters before it gets integrated into the game in various places and leveraged to it’s fullest extent.
There were questions about how many devs vs artists there are working on the game with Chad Saying – I can’t directly speak to the number of artists, but there’s definitely more artists than programmers, however that is not unique to our studio, most studios these days are like that given the increased fidelity in modern games. We have a fairly large number of programmers in the project, around 90 total, including developers on the game as well as dev ops. We are always looking to expand though, and if you look at the company website you’ll see programmer positions available for all the studios. The company as a whole is approaching (or perhaps we already surpassed) around 600 employees globally across all our studios. Also for those that were looking, Linkedin is not a good resource to gauge employee levels because many people don’t have accounts or even if they do keep them up to date.
On the engine side of things Chad also said they were hard at work trying to improve low server frame rates, service overloads, and asynchronous requests AND they have a multithreaded update system for the components in addition to asynchronous and threaded spawning. Their engine is the most multithreaded game engine Chad has seen, especially on the game code side.
Moving Away from Chad Mckinney now there was a thread on Why can gas cloud tech not be used for a V1 implementation of crusader? Medic-CIG waded in:
So this was something we did to try and explore and had done tests on but ultimately as this tech wasnt built to be used in this way, we encountered issue such as sorting. But to create a VDB as big as it needs to be, to even encapsulate Crusader, i wasn’t able to generate a sphere with a high enough resolution as it would crash my PC. Even if we had managed to do so, there was a high chance you would be able to see each individual voxel and ultimately not do Crusader the justice it deserves.
But why not make smaller patches and stitch it together in engine? Good question my good friend, The amount of small patches to put side by side would be huge. But you would also be able to see the seams of the patches as they are laid side by side.
So really its not that we don’t want to, it’s just that the gascloud tech wasn’t intended for it. But what it was intended for which is space scaping, it’s fantastic at and feels like it really adds to the universe
And they’re fun to make as well.
And Finally for this video anyway there was a thread on Signed Distance Field Tech asking if someone can explain how it’s going to be used mpiatek-cig was on hand to answer:
I can only speak from VFX point of view so take that into account.
SDF is just a type of data but a really cool one. Distance Fields are generated for a specific object and data stored in them are bespoke to that object. So a distance field of a Gladius would be a 3d texture where every single pixel stores the closest distance to the surface of the Gladius. How pixels can store distance? Well, each pixel can store up to 4 numbers (red, green, blue, alpha). Usually these numbers represent colours but in games we bend a lot of rules and we use textures for storing data. For distance we only need one number and it’s why SDF textures only need a single channel. Word “Signed” refers to the fact that pixel can store values below 0 (negatives numbers with lots of decimal places potentially). Unsigned textures can only store values Greater than or Equal to 0.
Ok, but how do we use them? Our particles can collide with SDFs. This is great because we lost a lot of collision functionality when we switched from CPU to GPU particle system. Not because we were loafing around but because it is really difficult to do collisions with the environment for any GPU particle system (not just ours but any particle system in games in general). You have to have some form of geometry representation which can be easily accessed by the GPU and textures are the equivalent of the golden ticket to Willy Wonka’s factory of particle collisions. We had Z-buffer collision for quite a while but that has the limitation of not being able to collide with objects which are not rendered (including back side of geometry).
Because we can collide with SDFs we can use existing particle system functionality to spawn other particles at the collision point. Particles can also avoid SDFs (by treating SDFs as a source of negative force), be attracted by them or flow along the surface. New atmospheric entry uses this a lot. We are literally shooting invisible particles at a ship and when they collide we spawn actual visible atmospheric entry particles and we let them slide along the surface.
What else? I definitely missed few use cases for SDFs we have in the VFX as I didn’t consult the team before answering this question but… the sky’s the limit! It’s a really nice, compact, efficient and useful piece of data and I’m pretty sure with time we will find other crazy use cases for them. There is a lot going on with SDFs on AI and physics side of things. But I’m not an expert on that so I will remain silent!