How Bleeding Edge is Star Citizen?
Hello & Welcome to some more Star Citizen we have had yet more Dev Responses from CIGs Chad McKinney the man is a legend and we are going to summarize the questions and look at the answer that Chad gave on SC’s Engine, Game Mechanics, General Development, Persistence, Orbiting Planets, iCache and more… this is a slightly more technical episode this time.
Will we have dead body persistence in the future?
I have mentioned this else where, but we already have a system for cleaning up entities that age out, and dead bodies will be no different. This is a system that will see more development int he future to deal with the increased challenges introduced by global persistence and server meshing, but fundamentally the idea is that certain entities won’t necessarily last forever in all places depending on the kind of area, so for example you would expect a dead body to just sit around in the streets of a busy city, at some point someone is gonna get thing that cleaned up, but on the other hand you may expect a dead body to stay around for a long time in some random derelict with very low traffic.
Any more info on Player Inventory?
There will be improvements to player inventory and management, I don’t want to go into details yet as not everything is finalized, but along with physicalized inventory we also want to improve how you view and interact with said inventory.
We are using something we call a StarHash which is a kind of geohash formatted specifically for our 64bit scale solar systems.
https://en.wikipedia.org/wiki/Geohash
These will allow for spatially querying a service called the (you guessed it..) StarHash service, which allows us to query data quickly in certain areas, with the main use case being server streaming. We’ve had a version of this running as an internal background job since the initial server streaming implementation went in, but now it will be moved out into its own set of services so that server nodes can mutually query on this data set.
Are there any improvements planned towards the functionality of the shopping kiosks in the PU?
There are plans to improve the shopping kiosk UI/UX, but the question is more about exactly when that work will get scheduled, rather than if. Given that the design work itself hasn’t been finished (and generally we try to ensure the more detailed parts of a design are done close in proximity to implementation) I don’t want to get into specific details on what exactly those changes will look like
Do any of the devs use machine/deep learning for any of the tech in SC?
We don’t use any in the runtime game right now, though there have been some discussions about various possibilities in all kinds of domains. The tricky bit with machine learning is that it is inherently probabilistic so you have to consider exactly what you’re wanting to get out of said systems and how good your model is going to perform in a real time situation. For the most part in games you can easily throw together some rough heuristics for say an AI and get decently good enough behavior that the player can be convinced of some higher level thinking (F.E.A.R often cited here as an example), but getting some model to behave like this would be an entirely different ball game. I think there’s definitely some interesting territory here, but it would require R&D to investigate.
Outside of the game itself, we are starting to incorporate some AI into other aspects of our tooling such as analytics, which for anyone keeping up with that field, should not be entirely surprising.
Will we see various insignia on player characters for different guilds & reputations?
We are working on the new reputation system which will at least at the data level allow us to track various reputation stats, including ranks, against entities and organizations. We will be looking to find various way to communicate these reputation levels and ranks in lore and in the interactions with the game world. I am not necessarily saying that armor customization will be included in that (first we’d need a whole armor customization system which doesn’t exist) but things along these lines are certainly being considered.
how bleeding edge is cig (or gamedev in general) in picking up new research?
Depending on the domain we do keep up with various interesting developments coming out of more formal research groups. I don’t think I’ve seen this cool looking cloth on dragons (!) paper going around, but very often there will be discussions on all kinds of things like new developments in robotics that improve jerk calculations to whatever the hot new paper out of SIGGRAPH is that talks about damage and deformation in meat!
Sometimes we’ll actually move to incorporate these ideas if they are simple, but often times the context these papers work in are very far removed from the realities of a realtime game, so it is more for inspiration. Another thing to consider is that another word for “bleeding edge” is “unproven” and by now the games industry has fairly well proven out how to make a 3D game, and now everyone is pushing to see where to take risks or find novel improvements, but in many ways engines are not all that different from the Quake days and many engines (including some modern ones) are even direct descendants of the quake code base:
We need to move past the traditional projection/rasterization method, I think raytracing and SDF is the future.
There were questions on planetary orbit mechanics & blockers to getting the tech in game…
To be clear, the navigation I mentioned regarding orbiting is only one of many that surface when orbits are turned on, so it is not the real blocker, really it is more that there are so many different systems impacted that we haven’t yet prioritized it to the point to have a concerted effort across teams to address these various issues.
I think it would be reasonable if jumping from one planetoid to another landed you “behind”, where that planetoid “used to be” prior in its orbit, if you’re jumping from very far away.
The design direction at the moment is to always jump to where the planet is ending up, not where it was before you jump, in order to avoid needing to do any kind of “fix up” secondary jump. I think from a gameplay pattern perspective it could get very frustrating to have to make a second jump every time you wanted to go somewhere just to get more aligned with the target, especially when you would expect at the point in the future you should be able to route a path to where you will need to be to be within a reasonable distance of the planet, accounting for travel time.
Of course, this is assuming that object containers even CAN BE anything other than a primitive solid… assuming that it can be a “ring” as described. It’s understandable if having a hole in it may not necessarily be a thing that object containers can do…
One thing to note here is that object containers don’t move, in fact that are completely static. They may be spawned in a zone that moves (like a planet) and their child contents may be moveable (like say some crates) but the object containers themselves are fixed in zone space, though they may move in world space if their zone moves.
What programming language was used to create SC?
the game engine is almost entirely C++ (with a bit of assembly), and in fact we removed Lua so not even game scripting is done in Lua. To improve iteration time we use something called Recode that allows us to hotswap code changes at runtime which is much faster than restarting the whole game, while allowing us to maintain the performance benefits of writing native code. Now the designers do script in a visual scripting language called subsumption for AI behaviors and mission logic, but that is a very small amount of “code” that is executed during runtime.
Elsewhere we use C# and python for tooling and C++, C#, Ooze, and Typescript for various backend services.
Do you have any plans on hiring more people to go fix the backlog of bugs?
Last I checked we have like 100 open jobs, so yes we are looking to expand significantly. Now that said we do want to maintain our standards and I can at least speak for the engineering department that even though we’re trying to expand we don’t want to let code quality suffer in that endeavor, so it will take time to fill these roles. Also, another thing to understand is that even with an expanded work force their focus likely won’t just be on bug fixing, as it can be counter productive to fix bugs in game systems that still have designs in flux. Additionally we have some very large pending technical endeavors like icache/global persistence and server meshing still in development that will have an impact on current and in-development systems. For now we have to balance bug fixing and feature development. As we get closer to a beta we can then switch to focusing largely on stabilization and performance.
As a follow up – are you willing to have programmers from Australia?
For the most part we look for people who can work on site as gamedev is an incredibly collaborative endeavor. On occasion we will do remote but often this is temporary until the new employee can move. Since we are still planning on moving back into the on site studios for the most part we are still mainly looking at applicants who are willing to move to work on site at one of our locations.
I have mentioned this else where, but we already have a system for cleaning up entities that age out, and dead bodies will be no different. This is a system that will see more development int he future to deal with the increased challenges introduced by global persistence and server meshing, but fundamentally the idea is that certain entities won’t necessarily last forever in all places depending on the kind of area, so for example you would expect a dead body to just sit around in the streets of a busy city, at some point someone is gonna get thing that cleaned up, but on the other hand you may expect a dead body to stay around for a long time in some random derelict with very low traffic.
Any more info on Player Inventory?
There will be improvements to player inventory and management, I don’t want to go into details yet as not everything is finalized, but along with physicalized inventory we also want to improve how you view and interact with said inventory.
We are using something we call a StarHash which is a kind of geohash formatted specifically for our 64bit scale solar systems.
https://en.wikipedia.org/wiki/Geohash
These will allow for spatially querying a service called the (you guessed it..) StarHash service, which allows us to query data quickly in certain areas, with the main use case being server streaming. We’ve had a version of this running as an internal background job since the initial server streaming implementation went in, but now it will be moved out into its own set of services so that server nodes can mutually query on this data set.
Are there any improvements planned towards the functionality of the shopping kiosks in the PU?
There are plans to improve the shopping kiosk UI/UX, but the question is more about exactly when that work will get scheduled, rather than if. Given that the design work itself hasn’t been finished (and generally we try to ensure the more detailed parts of a design are done close in proximity to implementation) I don’t want to get into specific details on what exactly those changes will look like
Do any of the devs use machine/deep learning for any of the tech in SC?
We don’t use any in the runtime game right now, though there have been some discussions about various possibilities in all kinds of domains. The tricky bit with machine learning is that it is inherently probabilistic so you have to consider exactly what you’re wanting to get out of said systems and how good your model is going to perform in a real time situation. For the most part in games you can easily throw together some rough heuristics for say an AI and get decently good enough behavior that the player can be convinced of some higher level thinking (F.E.A.R often cited here as an example), but getting some model to behave like this would be an entirely different ball game. I think there’s definitely some interesting territory here, but it would require R&D to investigate.
Outside of the game itself, we are starting to incorporate some AI into other aspects of our tooling such as analytics, which for anyone keeping up with that field, should not be entirely surprising.
Will we see various insignia on player characters for different guilds & reputations?
We are working on the new reputation system which will at least at the data level allow us to track various reputation stats, including ranks, against entities and organizations. We will be looking to find various way to communicate these reputation levels and ranks in lore and in the interactions with the game world. I am not necessarily saying that armor customization will be included in that (first we’d need a whole armor customization system which doesn’t exist) but things along these lines are certainly being considered.
how bleeding edge is cig (or gamedev in general) in picking up new research?
Depending on the domain we do keep up with various interesting developments coming out of more formal research groups. I don’t think I’ve seen this cool looking cloth on dragons (!) paper going around, but very often there will be discussions on all kinds of things like new developments in robotics that improve jerk calculations to whatever the hot new paper out of SIGGRAPH is that talks about damage and deformation in meat!
Sometimes we’ll actually move to incorporate these ideas if they are simple, but often times the context these papers work in are very far removed from the realities of a realtime game, so it is more for inspiration. Another thing to consider is that another word for “bleeding edge” is “unproven” and by now the games industry has fairly well proven out how to make a 3D game, and now everyone is pushing to see where to take risks or find novel improvements, but in many ways engines are not all that different from the Quake days and many engines (including some modern ones) are even direct descendants of the quake code base:
https://upload.wikimedia.org/wikipedia/commons/6/63/Quake_-_family_tree.svg
We need to move past the traditional projection/rasterization method, I think raytracing and SDF is the future.
There were questions on planetary orbit mechanics & blockers to getting the tech in game…
To be clear, the navigation I mentioned regarding orbiting is only one of many that surface when orbits are turned on, so it is not the real blocker, really it is more that there are so many different systems impacted that we haven’t yet prioritized it to the point to have a concerted effort across teams to address these various issues.
I think it would be reasonable if jumping from one planetoid to another landed you “behind”, where that planetoid “used to be” prior in its orbit, if you’re jumping from very far away.
The design direction at the moment is to always jump to where the planet is ending up, not where it was before you jump, in order to avoid needing to do any kind of “fix up” secondary jump. I think from a gameplay pattern perspective it could get very frustrating to have to make a second jump every time you wanted to go somewhere just to get more aligned with the target, especially when you would expect at the point in the future you should be able to route a path to where you will need to be to be within a reasonable distance of the planet, accounting for travel time.
Of course, this is assuming that object containers even CAN BE anything other than a primitive solid… assuming that it can be a “ring” as described. It’s understandable if having a hole in it may not necessarily be a thing that object containers can do…
One thing to note here is that object containers don’t move, in fact that are completely static. They may be spawned in a zone that moves (like a planet) and their child contents may be moveable (like say some crates) but the object containers themselves are fixed in zone space, though they may move in world space if their zone moves.
What programming language was used to create SC?
the game engine is almost entirely C++ (with a bit of assembly), and in fact we removed Lua so not even game scripting is done in Lua. To improve iteration time we use something called Recode that allows us to hotswap code changes at runtime which is much faster than restarting the whole game, while allowing us to maintain the performance benefits of writing native code. Now the designers do script in a visual scripting language called subsumption for AI behaviors and mission logic, but that is a very small amount of “code” that is executed during runtime.
Elsewhere we use C# and python for tooling and C++, C#, Ooze, and Typescript for various backend services.
Do you have any plans on hiring more people to go fix the backlog of bugs?
Last I checked we have like 100 open jobs, so yes we are looking to expand significantly. Now that said we do want to maintain our standards and I can at least speak for the engineering department that even though we’re trying to expand we don’t want to let code quality suffer in that endeavor, so it will take time to fill these roles. Also, another thing to understand is that even with an expanded work force their focus likely won’t just be on bug fixing, as it can be counter productive to fix bugs in game systems that still have designs in flux. Additionally we have some very large pending technical endeavors like icache/global persistence and server meshing still in development that will have an impact on current and in-development systems. For now we have to balance bug fixing and feature development. As we get closer to a beta we can then switch to focusing largely on stabilization and performance.
As a follow up – are you willing to have programmers from Australia?
For the most part we look for people who can work on site as gamedev is an incredibly collaborative endeavor. On occasion we will do remote but often this is temporary until the new employee can move. Since we are still planning on moving back into the on site studios for the most part we are still mainly looking at applicants who are willing to move to work on site at one of our locations.