dsmart
Forum Replies Created
-
AuthorPosts
-
@tonci I don’t know how Blizzard handles it. All games will handle it different since it is game/design specific.
We’re going to need 1 box for the first two and calc their interaction in a local space, second box for the next 3 and next two (farthest away) or one big for the whole rest… In case 2nd and 3rd can’t interact… but what if they can… how does, e.g. a projectile, is calculated when it goes through different zones? Recalc for every new zone it enters? What when it is in the same time in two zones (transition period)?
You just described the problem right there.
Here is a better analogy:
Imagine having a box split in two. You are on one side and someone is on the other. Your “zone” is loaded while the other is not. This means that you won’t know about anything going on over on the other side. So if you fired a weapon at the other person, nothing happens. Even if both zones were loaded, it would still take some serious crap to get everything in sync.
Yup. And the reason they’ve been “stagger” releasing it is because they know they will get flooded with tech support issues, it will chew up a ton of very expensive server bandwidth – and too many people will experience all these issues and add to the noise.
Last I checked, they had up to 16K in the PTU 2.0 now.
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-rightNOTE:
The max “map/scene” size in CryEngine3 is 8km x 8km or 64 sq. kmImagine (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.
The jittering issue is not the most “damning criticism”. It’s about something they said they’ve spent the better part of one year addressing. That 64-Bit positioning issue was the Red flag that sparked my first blog this past July.
So to me, as an engineer, it just tells me that they haven’t or can’t address it. Which means that, just like the whole Star Marine farce – which is still ongoing – it’s still another broken piece of architecture that’s either going to take awhile to address or they’re just going to say fuck it, then leave it broken. Just like Arena Commander, buggy buggies, buggy hangar, ArcCorp etc
If you think this is trivial, ignore the jittering and just think about the massive z-fighting which is also a symptom of this problem with the custom engine they’ve building using CryEngine3 as base.
Also, this is what they promised. All of it. For $95m+ thus far.
…and they have yet to deliver even 10% of that.
And what we’re seeing in this 2.0 release, despite it being in the PTU and not final release, is precisely what I predicted would happen back when they released the buggy social/planetside module.
I have no confidence – none – that they will ever deliver the Star Citizen they promised. At least not in 2016. From what they just released to the PTU as 2.0, my estimation is still that this project is at least 2-3 years and another $75m (if they are frugal) away.
If they survive 2016 long enough to deliver SQ42 EP1 (they promised 70 missions. lol!!) which they are now heavily pushing, my guess is that’s the good faith they’re now shooting for. Guess what? All existing backers are already entitled to it. And now it’s being sold separately for $45 to non-backers. Imagine then how those who have spent upwards of $30K on this project will feel when all they will have got is a half-baked Star Citizen and a SQ42 that others only paid $45 for.
There is absolutely no fucking version of this where it ends well for anyone. Chris has completely and totally screwed this once promising project.
I wrote a short missive about the 2.0 jittering issue today; along with an exchange between Chris and an engineer 🙂 You can see the full Twitter exchange in these tweets.
@SJ Thanks for stopping by. I have also stated, just as you did, that if I am proven to be wrong about this, and Chris does ship the game that he pitched and promised, that not only would I apologize, but I would also retire (I am semi-retired) from game development – completely.
A LOT of people don’t really understand the nuances of what’s at stake here. They just see some angry, jealous (insert choice adjective of the day) raising the alarm, asking people to look closely, ask the tough questions etc. But instead, they just want to attack, attack, attack. YET they wonder why such extremism in the Star Citizen community, has now completely and utterly tainted it.
The 2.0 they released yesterday is more than enough evidence that they have a LONG way to go with this project IF they ever get to finish it. And if they do, it’s easily another 2-3 years, plus another $75m+ to get there.
UPDATE: I have added an update to my latest blog. It’s at the bottom.
Yeah, it’s precisely what most of us expected. Just another money grab. You’d think that they would have done a demo of all the stuff Chris mentioned was going to be in 2.0. Thing is, he didn’t say when it was all going to be in there. Just that it was going to be. And given all the crashes from those who got it, it is understandable why didn’t show anything live.
And two of my contacts got the invite and so far, neither one of them has seen even 5% of what Chris said was going to be in 2.0.
Here is what I’ve been predicting all month long ahead of this:
Nov 2nd: https://twitter.com/dsmart/status/661306828568023040
Nov 5th: https://twitter.com/dsmart/status/662384623880642560
Nov 17th: https://twitter.com/dsmart/status/666661407144955905
-
AuthorPosts