We have had a big Star Citizen info dump from CI’s Chad McKinney Lead Gameplay Engineer for Star Citizen, Answering various questions again with a big focus on The Dynamic Universe Sim, Points of Interest, Renting Habs & Hangars, iCache, Server Meshing and Much more.
For the Dynamic Universe Sim Is the 9 to 1 NPC vs player ratio still the plan? As in the Birthday AMA they said “we won’t need more than 100K per system to get the desired effects.”
What you consider the ratio is going to get very fuzzy because of quanta, probabilistic generation, virtual AI, and missions. In some ways you could view it as way beyond that ratio, just depending on what you count as an NPC.
Tony Zurovec had previously Said SSOCS (Server Side Object Container Streaming) will “break us free from these limitations in terms of how many locations and how much content we can put in the solar system … well now we can add all these new locations without impacting the frame rates at all… So what this is going to allow us to do is put more outposts, more space stations, more derelict ships, more caves …”
SSOCS did work as intended and Tony’s point is still valid. There are some other reasons why we haven’t pushed the envelope on the number of these satellite areas, including work done on the procedural generation tools to make that content interesting and improve the pipeline for authoring it. The move to icache will also help us move in that direction since we can pre-seed the database with the content and not have to store it locally in memory on every DGS like we do now with the current prototype backend ssocs is using.
It is in heavy development, in fact I just saw a really cool demo one of the designers threw together to show off progress, however we aren’t ready to show that publicly yet. More to come!
Buying and renting spaces has long been part of our vision, though icache and global persistence are key to make that possible.
Follow Up Question – have there been any changes to these ideas and if so, could you tell us what they are?
Yes I’m sure there have been changes over the years depending on who you asked and what quote you are referencing, so it would be hard to say exactly. That said if I could generalize it I would say that with procedural plants and global persistence we’ve afforded ourselves the possibility of being much more ambitious with these ideas than was originally thought possible.
Hey, here’s at least one thing I get to say at least does not depend on icache haha. No in the end there’s many smaller issues that crop up when you turn on orbiting (which we’ve been able to do for years actually!), as it causes problems in many gameplay systems. One example: Navigation. Imagine you want to plot route to from a satellite to an outpost on a moon across the solar system. Depending on your ship this may take quite a while and by the time you get part way through the jump the route you took can become invalid as it may be blocked by something that moved into view. This isn’t an insurmountable problem and we have plans on how to deal with it, but we just haven’t done the work yet.
Will NPC Spawn lockers be used to “fake it” rather than have NPCs with full life cycles?
The spawn lockers are indeed going to be part of the long term solution of the game, but there are some key details you may not be aware of. First, there is an assumption here that the entities spawned by these lockers are completely blank slates and when they despawn will never be seen again. This isn’t going to be the case for all of the NPCs as there’s at least two mechanism we are going to use to which would result in a similar behavior to what you are looking for. First, there will be a class of NPCs of higher importance that will have some amount of virtual simulation even when no players are around. These NPCs could be part of a mission for example, and their schedules and movement through the verse will be simulated in the backend. When you encounter once of these they may spawn or leave an area via a spawn locker depending on the circumstance, and you will likely see them again later.
Another case is that the backend will actually track entities that have been created via a character archetype creation service, and each of these entities will have various properties and tags that can be used to pattern match against future requests. That means for example if you possibly steal something from a shop or try to mug somebody and security gets called in dynamically, there’s a chance the same security officer may bust you later or get called in for back up at a traffic stop.
Given the scope of the world we are trying to create it would be actually impossible to simulate all their schedules and every detail of their life, but we can split the difference by using a combination of dynamic creation, virtual simulation, and pattern matched reuse to bring the kind of gameplay you are looking for.
Spawn closets/spawn lockers are simply a way to get entities into/out a place, but they aren’t the progenitus of that entity in our game world, instead the character archetype system is what will track these, so their scheduler may have them board a train, go to work, come back, get dinner, go to sleep etc.. and yes in some of those movement points there maybe be a spawn locker involved, but it doesn’t mean that every NPC you see is only probabilistic. The idea is that quanta and the other systems like the dynamic mission system will be able to use spawn lockers to facilitate to help move entities throughout the world, and when there are surges necessary (security backup etc…) have a way to get NPCs in the necessary areas without breaking immersion.
Also keep in mind the spawn lockers won’t be the only way this can happen, as when you’re out in the middle of space or in a random area on a planet other mechanisms can be used, like QT spawned NPCs or drop ships.
Every case is different so there isn’t a single answer. In some cases the teams are just working on something else, however there are places where certain parts become available for internal usage and testing so that features can start to be developed against it even though the entirety isn’t ready for release.
It is always a balance we have to strike between bug fixing and feature development (and generally getting movement towards a 1.0 release). We could stop what we are doing and really focus on wiping out the bugs, but then the next patch would be very light on features. Also, when you work on new features often bugs can re-occur or the system that had the bug is modified or even removed, so the issue is you’re always aiming at a moving target. Games that don’t have to support a live product have the advantage that they can let things be broken in various ways while they’re finishing the game and allow room for flux. Towards the end you then have a big push to polish and finalize things off (and often land with a day 1 patch to boot). For live games though you have to keep things afloat while simultaneously try to keep moving forward, so in the end it’s just a balance and the more you focus on bug fixing the longer your dev goals may take.
Do the devs use rubber duck debugging? – For people that don’t know that’s when you explain your code to a rubber duck so that logically check through it and catch anything you might of missed.
Mark Abent famously has a literal rubber duck on his desk for exactly this! But yeah rubber ducking is very common and often times I’ll have someone call me or walk over and ask me a question only to stop themselves halfway through and say “thanks!” then walk off.
They don’t currently. The UI framework could have this added optionally, partially it is a design question, and then there’s a bit of though that would need to go into how you dictate the default choice, then the existing implementations would need to be updated, but it is possible. I may run it by the UI team and see what
What’s Happening with “Combat Assistance” Mission/Contract Pop-ups?
The service beacons and contracts are something we do plan on revisiting including better handling for the notifications. We have scheduled work for a new notification system that will allow for queueing into a mobiglas app so that we don’t have to just rely on spamming players, as well as have configurable filters for muting types of notifications. The service beacons and other gameplay systems will be ported over to this new system and hopefully you’ll get some peace and quiet!
There are plans to address the state of spawning and hangars including from where these operations can be invoked. I don’t want to go into too many details yet, as I’m not entirely certain what has been made public, but the goal is to improve here.
Each solar system will use the full 64bit range, and we will use a unique zone for each of these solar systems to differentiate coordinates from various systems.