4 ms·

I'm a Star Citizen fanboy, and have kept a close eye on the development process. Yes, the development has been full of fits and starts, but they've also solved

I'm a Star Citizen fanboy, and have kept a close eye on the development process. Yes, the development has been full of fits and starts, but they've also solved some amazing technical challenges. The 64-bit map size aspect was critical for having solar-system-sized maps with proper precision for multiplayer. The independent physics grids per ship implementation was a big deal. Also, they were able to pick up many of the core CryTek engine developers who had built the engine in the first place, and that's paid off with the rapid development of their procedural planet generation technology. Sure, the development has been repeatedly behind schedule, and we've learned to pretty much ignore any projected deadlines they announce. But, they've got several hundred people working full-time on a pair of AAA-class games and the current alpha versions _are_ playable, so it's not just vaporware. They also have been posting the current project task planning info on the website for about the last year, with info drawn directly from their internal JIRA, and the community is watching that eagerly to calculate weekly progress update diffs. Supposedly CIG is aiming for quarterly patch releases this year based on what's ready at the time rather than a specific feature list target, with 3.1 due out this month. We'll see how that pans out, and if they can actually manage more consistent releases. I pitched in for them to make the game of Chris Roberts' dreams, and I'm enjoying watching the development process. As long as they continue to make progress, I'm quite happy to sit back and wait for them to get it "right".

everyone 9y ago
"The 64-bit map size aspect was critical for having solar-system-sized maps with proper precision for multiplayer" No. When something is very far away from you, it will probably not even be visible, if it does appear it will be very small. You will not be able to interact with it. From your perspective its position does not need to be precise. With a sane game architecture for this kind of game you dont need higher precision floats. This has been done in loads of games. I mentioned KSP because a tiny team did this in Unity (not even their own engine) Considering how it will instantly double all the payloads, this is something you'd particularly want to avoid for a multiplayer game. I can only guess that they did this because they used cryengines built-in physics, and every ship in an instance is in the same phsyics 'world' (which is insane) "The independent physics grids per ship implementation was a big deal" Thats not a big deal. Its relatively trivial to do imo. You just have multiple physics 'worlds' and any bodies which protrude into another system are represented by kinematics in the other system. Transitioning from one system to another could look very weird, simply because the fantasy of the game does not cog with consistent physics, but they have not overcome this problem either. I imagine implementing it whilst using cryengines built-in physics system may have been the truly colossal task. But why in gods name are they using cryengine (an engine strongly geared towards making crytek fps games) to make space game?
- acemarke 9y ago
  I'll point back to a couple interviews and reports from the Star Citizen developers discussing these topics: - 64-bit map sizes: https://www.gamersnexus.net/gg/2622-star-citizen-sean-tracy-64bit-engine-tech-edge-blending https://www.gamersnexus.net/gg/2622-star-citizen-sean-tracy-... - Multi-crew ships and physics grids: https://robertsspaceindustries.com/comm-link/transmission/15222-BTS-Multicrew-Physics-Grids https://robertsspaceindustries.com/comm-link/transmission/15...
  - everyone 9y ago
    I skimmed those articles. And tbh it seems like they are just whitewashing their backers who dont have game programming experience. Eg. For the 64bit precision one they have a decent amount of detail explaining what it is. But not why they are doing it when its not necessary. (I assume the only reason one could possibly do this is cus every ship in a game instance exists in the same phsyics world (which is a crazy bad implementation))
    - allthesethings 9y ago
      The problem with making guesses about any of the technical decisions is that this is a software project with hundreds of people in multiple studios. There are no design efficiencies to be had here: somewhere within those hundreds of developers a rationale for taking on a more complicated architecture arises - a specific feature, or combination of features, that causes a cascade of requirements inflation. For example, one reason they might want higher precision is for editing and processing persistent data: a need that doesn't apparently have anything to do with the physics simulation, but subsequently ripples down into "well, if we want to allow editing in real-time, then..." It is interesting work, but nothing that you would want to emulate as a best practice for making a Better Game. It's just a result of the software aspects being scoped and executed in such an uncompromising way. A good majority of the work to date has been on the organization-building work of teams and processes that can execute at this scale.
      - everyone 9y ago

everyone 9y ago

"The 64-bit map size aspect was critical for having solar-system-sized maps with proper precision for multiplayer" No. When something is very far away from you, it will probably not even be visible, if it does appear it will be very small. You will not be able to interact with it. From your perspective its position does not need to be precise. With a sane game architecture for this kind of game you dont need higher precision floats. This has been done in loads of games. I mentioned KSP because a tiny team did this in Unity (not even their own engine) Considering how it will instantly double all the payloads, this is something you'd particularly want to avoid for a multiplayer game. I can only guess that they did this because they used cryengines built-in physics, and every ship in an instance is in the same phsyics 'world' (which is insane) "The independent physics grids per ship implementation was a big deal" Thats not a big deal. Its relatively trivial to do imo. You just have multiple physics 'worlds' and any bodies which protrude into another system are represented by kinematics in the other system. Transitioning from one system to another could look very weird, simply because the fantasy of the game does not cog with consistent physics, but they have not overcome this problem either. I imagine implementing it whilst using cryengines built-in physics system may have been the truly colossal task. But why in gods name are they using cryengine (an engine strongly geared towards making crytek fps games) to make space game?

acemarke 9y ago
I'll point back to a couple interviews and reports from the Star Citizen developers discussing these topics: - 64-bit map sizes: https://www.gamersnexus.net/gg/2622-star-citizen-sean-tracy-64bit-engine-tech-edge-blending https://www.gamersnexus.net/gg/2622-star-citizen-sean-tracy-... - Multi-crew ships and physics grids: https://robertsspaceindustries.com/comm-link/transmission/15222-BTS-Multicrew-Physics-Grids https://robertsspaceindustries.com/comm-link/transmission/15...
- everyone 9y ago
  I skimmed those articles. And tbh it seems like they are just whitewashing their backers who dont have game programming experience. Eg. For the 64bit precision one they have a decent amount of detail explaining what it is. But not why they are doing it when its not necessary. (I assume the only reason one could possibly do this is cus every ship in a game instance exists in the same phsyics world (which is a crazy bad implementation))
  - allthesethings 9y ago
    The problem with making guesses about any of the technical decisions is that this is a software project with hundreds of people in multiple studios. There are no design efficiencies to be had here: somewhere within those hundreds of developers a rationale for taking on a more complicated architecture arises - a specific feature, or combination of features, that causes a cascade of requirements inflation. For example, one reason they might want higher precision is for editing and processing persistent data: a need that doesn't apparently have anything to do with the physics simulation, but subsequently ripples down into "well, if we want to allow editing in real-time, then..." It is interesting work, but nothing that you would want to emulate as a best practice for making a Better Game. It's just a result of the software aspects being scoped and executed in such an uncompromising way. A good majority of the work to date has been on the organization-building work of teams and processes that can execute at this scale.
    - everyone 9y ago