*snipped a bunch of rubbish*
I messaged a CIG developer on the RSI forums and asked outright, quoting your comment:
I hate to break it to you though, but that's pure - and utter - rubbish. You all know this.
64-Bit floating point precision map is NOT the same as 64-Bit positioning. In fact, on Nov 22, 2015, I wrote a missive explaining that.
But despite the fact that even the engineers have gone on the record debunking that nonsense, some of you still keep parroting it.
Basically, all the scenes are "stitched" together in order to have a cohesive whole that quantum travel sequence hides.
The dev was kind enough to respond to me. Here is part of the reply:
it's true that things get *authored* as isolated scenes. That's just good sense. But this whole "stitching" thing is just lack of imagination on his part, I think. Or a setup for him to backpedal and say that because assets get loaded as you approach them, he was right all along.
If all you want is a dev saying he's wrong, well, he's wrong.
I am a tier 1 engineer, I deal in absolutes - not semantics. There is literally
NOBODY in the
ENTIRE team over there, that has worked on
ANY project of this type and/or scope. And the past 4 years has proven - without a doubt - that they're just winging it, spending a lot of time on R&D, tech demos etc - still no game. So excuse me if I scoff at anything that any "engineer" over there has to say.
The "stitching" thing is 100% factual and isn't even open to discussion because I am 100% correct. That's how it is being done, it's how to do it because it would be impossible to fit an entire world into memory. Why? Because it's not procedurally generated.
When you have two scenes (S1, S2) which are different, and part of the game "world", they have to be stitched somehow. It's not only efficient, but it also gives more options for scene and player management. As big as Elite Dangerous is, they do it. ALL my games do it. Including Universal Combat (see this
), which has the largest (until ED, it was the largest in gaming history) game world.
The key to having a "seamless" world is either i) procedural or ii) stitch it
If you go with (i) you use data values to generate the scenes in real-time
If you go with (ii) then that's where loading screens come from. When player moves from S1 to S2, you unload S1, then load S2. This is what
ALL games with different scenes do.
If you want to give the illusion of a "seamless" world, then you have to come up with ways to stitch S1 + S2 in order to give that
illusion as it being one cohesive whole. And there are several ways to do it. The two most popular ways are to either (i) stream load S2 when the player hits a trigger point in S1 or (ii) create a transit illusion when the player is committed to moving from S1 to S2. The commit phase is why you use one of these to go from S1 to S2. You can't get out of it.
In ALL my space combat sim games (Battlecruiser/Universal Combat), I use option (i) to go from space to planet, and vice-versa - via an external camera transition when the player's ship breaches the planets gravitational pull, or when they climb up high enough and hit Escape Velocity to leave the planet. And I use option (ii) via a jump anomaly (jump gate, wormhole, fluxfield) to go from one space region to another.
This is what
the segmented world of BC/UC looks like. It's not procedural; so each scene (space and planets are different) is completely separate. Each space scene is a simple small binary file with data that the top-level AI script parses in real time, to generate the scene, and pointers to everything in it. It's fast and efficient - hence no loading times.
This is what the data definition file for the Earth space region looks like:
Ted32 text format file id:191550422,1
Unit:3 (Km)
group:MAIN
size:0,origin:(0,0,0),extents:(0,0,0)(0,0,0)
(
points (11):
pid 0:(72496,860087,393344)
pid 1:(-413288301,-330238555,350381112)
pid 2:(-65804045,-697187263,-524462638)
pid 3:(-737764523,172603385,85956996)
pid 4:(476547561,7329222,-30087638)
pid 5:(-6221827,592913797,-389212126)
pid 6:(654311881,647176854,-325243888)
pid 7:(-436135255,370818784,-42587638)
pid 8:(737466352,-598273156,225537362)
pid 9:(565000000,145000000,435000000)
pid 10:(410000000,-395000000,435000000)
structures (10):
[0] col:2 at:0,use:PLANET.3D:EARTH
[0] col:11 at:1,Rx:85, use:JUMP.3D:JMP-01
[0] col:11 at:2,Rx:90, use:JUMP.3D:JMP-02
[0] col:11 at:3,Rx:94, use:JUMP.3D:JMP-05
[0] col:11 at:4,Rx:94, use:JUMP.3D:JMP-04
[0] col:11 at:5,Rx:89, use:JUMP.3D:JMP-10
[0] col:11 at:6,Rx:90, use:JUMP.3D:JMP-12
[0] col:11 at:7,Rx:89, use:JUMP.3D:JMP-11
[0] col:11 at:8,Rx:92, use:JUMP.3D:JMP-03
[0] col:7 at:10,use:MOON.3D:MOON
subgroups (3):
include:PLANET.3D
include:JUMP.3D
include:MOON.3D
)
This is an excerpt from the master data file showing what the data definition for Mercury, Venus, Earth planet region looks like:
#
# SOL SYSTEM
#
."SOL","skybox08"
#
# MERCURY
#
:Mercury.3d,p,"MERCURY","SOL","PLANET 1/9"
:Mercuryz.3d,s,"TERRAN","SOL","SECTOR D9"
mercury,p,mercury,ptype01,ptype01,hot,TERRAN,4440,4878
jmp-10,j,earthz:TO..EARTH
jmp-15,j,venusz:TO..VENUS
flx-04,f,mercuryz,snv01z,blk01z
#
# VENUS
#
:Venus.3d,p,"VENUS","SOL","PLANET 2/9"
:Venusz.3d,s,"TERRAN","SOL","SECTOR D9"
Venus,p,venus,ptype02,ptype02,hot,TERRAN,25000,12100
jmp-02,j,earthz:TO..EARTH
jmp-14,j,plutoz:TO..PLUTO
jmp-15,j,mercuryz:TO..MERCURY
#
# EARTH
#
:Moonp.3d,p,"MOON","SOL","EARTH MOON"
:Earth.3d,p,"EARTH","SOL","PLANET 3/9"
:Earthz.3d,s,"TERRAN","SOL","SECTOR D9"
Earth,p,earth,earth,earth,temp,TERRAN,1440,12756
Moon,m,moonp,mtype07,mtype07,cold,TERRAN,38880,3476
jmp-10,j,mercuryz:TO..MERCURY
jmp-02,j,venusz:TO..VENUS
jmp-01,j,marsz:TO..MARS
jmp-04,j,jupiterz:TO..JUPITER
jmp-05,j,saturnz:TO..SATURN
jmp-03,j,uranusz:TO..URANUS
jmp-11,j,neptunez:TO..NEPTUNE
jmp-12,j,plutoz:TO..PLUTO
In both of the above, there are no scene "levels". It's all procedurally generated from pure data files. I wrote that back in the
eighties, and have improved on it throughout the years, and is the tech still used in the upcoming
Universal Combat - The Lyrius Conflict.
This is what
the segmented world of LOD looks like.
The space (4 scenes), planetary (4 scenes), stations (4 scenes), carrier (3 scene decks) are all
hand crafted in a scene/level editor because the engine is totally different from my previous engines, and was developed specifically to power this game. It fits the purpose because, though LOD takes place in a small (Syrius region) region of the IP world (see the UC map above), it was designed to be multiplayer, and so more control over the scene loading, population etc - were required due to the design of the
Wide Span Global networking tech we built to handle both session and MMO based connectivity.
When the player goes from one scene to the next via a jump anomaly, a loading screen is required because it's both efficient in terms of memory, performance, but also in terms of determining pop count. The "stitching" of these scenes to give the illusion of a cohesive world, is standard fare. Nothing ground breaking about it.
And it was built this way because my long term plan for LOD is to build the ENTIRE game world (that the IP is based on) via DLC. Doing it this way, is both efficient and cost effective. So one day, in addition to Sirius (already in LOD), we could end up with the adjacent systems (Sol, Barnard's Star, Alpha Centauri, Polaris, Tau Ceti, Omicron Eridani, Procyon) in the TERRAN quadrant. Then build the other quads over the years. And THAT'S why I spent all this resources on the game, but still started off small. And doing it this way then allows me to incorporate other game play mechanics such as trading and exploration, while bringing in assets such as
all the transports and capital ships (cruisers, carriers) in the IP. The end result is a much accessible - and much simpler Battlecruiser/Universal Combat game - with multiplayer. And in the end, the FPS on planets and inside stations, will carry over to the capital ships - which is why the 3-deck Starguard carrier is in LOD as a test bed in which you can do all those things - besides fly (only devs can) it. I didn't have $130 million from a bunch of gullible fools to build it. I funded it 100% on my own.
Star Citizen is doing
EXACTLY what LOD is doing. All their scenes are hand-crafted in CryEngine editor, and "demand loaded" when a player needs to transition from one place to another. In the case of going from one place to another in space, this "stitching" "hidden" behind a jump transition sequence. And if by some miracle they happen to create a planetary region, it too will be hand-crafted and demand loaded - and "stitched" - in the
SAME EXACT WAY. Why? Because they
DO NOT have procedural generated scenes (space or planets) because the terrain surface area is just a map they generated in the editor; then populated.
NOTE: The "dev" above, pretty much confirms what I said above, but uses semantics to deny that the entire world isn't cohesive, but rather, is "stitched".
"
it's true that things get *authored* as isolated scenes. That's just good sense. But this whole "stitching" thing is just lack of imagination on his part, I think. Or a setup for him to backpedal and say that because assets get loaded as you approach them, he was right all along. If all you want is a dev saying he's wrong, well, he's wrong."
Using buzz words doesn't change the facts. And "buzz words" and "semantics" are what the Star Citizen devs excel (clearly, they can't build a game after 4 yrs and $135 million) at.
Anyone who thinks that this starmap of the
game's universe is one cohesive whole that isn't "stitched", is a
FOOL. And if you believe that they are actually going to build (LOL!!!) all of that, and you will be moving "seamlessly" from place to place - sans "stitching" - please, do go and buy an Idris while you wait.
And
NONE of the above has
ANYTHING to do with a "64-Bit world" - which Star Citizen simply does
NOT have. And they haven't stated anything to the contrary either, instead, relying on obfuscation to keep backers guessing and theory-crafting bullshit on-the-fly.
Here's a recent interview with Sean Tracey that seems to suggest you're wrong as well.
The moral of this story is very simple. Just because you don't think something is viable or possible doesn't mean it can't or shouldn't be done. They've done it. Claiming otherwise just makes you look even more ridiculous than ever.
Good thing that you're not a developer, just another clueless fool who i) believes what's coming from a band of KNOWN LIARS ii) doesn't understand ANY of what Brian said in that video
HINT: No, he didn't - in any way, shape or form, disprove what I've stated.
Here's a neat trick, go ahead and show your "developer contact" this post, and have him explain to you how they are building their worlds, that it's not "stitched", doing transitions etc. I'll wait - right here.
ps: While you're at it,
see this OP where I discuss some of their "tech"