To me, there's
nothing in that interview that says
anything about
how they actually
did it. It talks about the difference between
64-Bit Engine vs 64-Bit positioning. Something I have written about numerous times, and extensively.
1,
2,
3,
4,
5. But yet, here we are. Again.
And as MTBFritz pointed out earlier, I posited about what I thought they did,
as far back as Nov 2015;
ahead of the 2.0 PU release, and long before they even started talking about it, due to all the noise that my claims had been generating.
I know what they did. I've documented it. They've basically confirmed it. The rest is history.
FYI: As Ben Parry keeps reminding us, Sean Tracy is an artist, not an engineer. So, he wouldn't know anything about that, other than what he's been told. The people who would have probably explained that better, are either Todd Pappy, Ali B, or Brian Chambers; since they're in the chain that
should know.
But none of that is important. The fact remains that their scenes/levels/maps are a finite size. Like ALL games. There
will be boundaries. There
will be limits. And as of now, seeing as they haven't even finished building a
single star system (that being
Stanton), it's anyone's guess why that is; when instead they're busy building ships to sell, instead of actually building the game world - even if it's an empty template.
And what I believe their "mega-map" (only in single-player as per the recent 2.6.1 patch) is, has ended up being precisely what I argued (
1,
2,
3,
4) tooth and nail with Ben Parry about, just months ago. Aside from reducing loading times, I suspect that they're going to later be "stitching" scenes together in order to give the illusion of expanse. They don't have the tech to do that in multi-player yet; which is why, even though they could have built out the "100 star system" world all these years, even if it were empty, they still haven't done it. And given that SQ42 takes place in the same world, I bet that's also part of that game's delay because unless they want to be using loading screens between areas, they have to build it in such a way that it gives the appearance of expanse and seamless transitions not only between star system regions, but also planets.
Heck, even ED uses similar tech to "stitch" regions together. And that game has a phenomenal engine and team that has built a fantastic engine using pure alchemy it seems.
At the end of the day,
how they do it is largely irrelevant. As game designers and devs, we get to cheat all the time. That's the nature of "make belief". The key issue here is that there is currently
zero evidence that they actually
can do it as they've described, and seamlessly. So, for now, backers are stuck with four (hangar, arena commander, star marine, PU) modules which have zero connection to each other. And very soon -
if my hunch (which TheAgent also recently wrote about) - is right, they will be adding a planetside module to the list; and which, like all those others, may either end up being a standalone item via the main menu (like the other four), or a context sensitive menu item when you approach a planet from within the PU. You know, just
exactly like I did it in LoD for efficiency and control over client count.
- - - Updated - - -
No, they haven't. Their LumberYard implementation - at least as per 2.6.1 - remains purely in their use of AWS/EC2 (replacing GCE) via LumberYard's implementation.