Reply To: Star Citizen – Year Four
Forums › Main › Star Citizen – Year Four › Reply To: Star Citizen – Year Four
Another more technical discussion for those interested in such things. Let me explain as best I can this world building issue.
1) Take a piece of paper
2) Draw a box and imagine each side of that box is 8km. You now have a box that is 64 sq. km
3) Divide that box into 4 equal sections with each side ends up being 4km. This is a zone within the scene. You now have 4 of them
4) Put an x anywhere inside each box and call them x1, x2, x3, x4. Do this such that x1 is top-left, x3 is bottom-right
The max “map/scene” size in CryEngine3 is 8km x 8km or 64 sq. km
Imagine (regardless of whether or not you keep the 1:1 scaling) trying to fit the larger ships in there and having them fly around with enough space.
The Javelin is 345m long, while the Idris-P is 240m long. More info on the ships.
That’s the problem that Star Citizen has.
5) Now draw a bigger rectangle (not a box) around the larger box such that the left side (h) is 200 km and the bottom side (w) is 5K km
You now have a rect (map/scene) that is 1m sq. km. Note that we’re disregarding z-depth atm. But even if it were factored in, it would probably be no less than w (5K km)
6) Put an x anywhere inside each box and call them x5, x6, x7, x8. Do this such that x5 is top-left, x7 is bottom-right
So that brings us to this…
Regardless of whether or not they use 32-Bit or 64-Bit world positioning, they can’t exceed the max map size of the engine without super-extensive modifications. And even if they did that, they still have one massive problem: the physics engine
I don’t believe that they’ve done this. It would be absolutely insane and time consuming to do that. Plus, for a space combat game, it would have no benefit. Elite Dangerous did it because right off the bat, they built a game engine from the ground up to do just that.
What I believe they’ve done is what Chris has been hinting at and which most people (if you’re not a tech) keep missing. They’ve zoned it. As in shards it. Because that’s the easiest way to do it in any engine, especially CE3 without hassle. You still need 64-Bit positioning because you still need to calculate that accurately in a game whereby you want to keep everything in sync and accurate.
From my diagram above since the inner box is within the extents of the engine, you’re not going to have position precision issues as long as you don’t get too close to the 8km edge. But for a space game, 64 sq. km is woefully inadequate. Unless you’re in a close combat shooter like Arena Commander or the mission based SQ42 which can design missions to keep players within these world constraints. For Star Citizen, nah, not gonna work.
They don’t use jump gates or anything (more on this below) of the sort (like I did in my massive world games, Battlecruiser 3000AD / Universal Combat) to link these zones. They wanted it all to be seamless and appear as one big open space.
So, you are going to need 64-Bit positioning precision to avoid problems with objects outside of the 8km range; especially in an open world game that gives all the interactions that Chris has promised.
And if they went with doubles (yikes!) the performance and problems with physics alone, are going to be headaches from start to finish (?). If they didn’t, then my post about them cheating with a hack, is probably what they’ve done; as they would have no choice but to calculate positions of objects in the world based on the player’s current camera viewpoint location.
Even so, at a 5K km range, they are going to have to use logarithmic Z which gives them a significantly higher level of precision in the Z buffer in order to alleviate visual anomalies which we have been seeing in the PTU 2.0 builds.
Again, I do *not* believe that they’ve made such extensive revisions to CE3 that they can now build *single* scenes of up to 5K km per side, up from 8km. Not only would that be insane (when you can just zone it all), but all the existing regions would need to be redone because re-sizing it in the editor will completely screw up the pre-existing object positions and introduce a whole new set of problems. It would be a lot of work to redo the maps. Then again, considering how many things they’ve had to do over, they may have done just that. Plus they only had one anyway.
So, assuming they’ve zoned it, the end result is that object x1 moving to the position of x5 is going to seamlessly transition from it’s own zone (assume it to be less than 8km on any side) into that zone causing that new zone to be loaded. It’s like two mat pieces being stitched together. And since this is space – with not that many objects to handle – the loading times are negligible. Crashes can/will happen at this point btw. Especially since it appears (I monitored it in a test I ran yesterday) that they are in fact streaming in the zones.
And transitioning between these streamed zones is what they are referring to as “jump tunnels”.
In order to even do what I think they’ve done, they would’ve had to do something called “world origin rebasing” (look it up). You use this to shift the player’s world origin position as closer to the camera as possible when it’s too far from the current world origin where precision loss tends to cause problems. A combination of this and zone streaming is what they may be doing as it allows them to build this massive world with the appearance of it being one seamless piece as shown in their starmap.
I know that UE4 has it (they don’t recommend using it for multiplayer games without writing a custom server solution), but I’m not sure that CE3 does. And I’m not sure why it would. Here is a discussion from earlier this year about large seamless worlds in CE3.
Which brings me to the issue of borders.
A few people have actually hit a literal brick wall going in one direction that took them to the world extents of the zone. If this were one massive universe that is 1m km sq. that should never happen. In my games, the way I handle this is I have a region called a “null zone”. As soon as you breach the boundaries of the world – usually by some fluke – you enter in world the same size as the one you left, but with nothing in it other than a jump anomaly that brings you back to known space. I built it like a Russian doll puzzle. No brick walls.
Hope this helps those who are genuinely interested in the complexities of building massive worlds like this and the challenges presented.