I posted this on SA. Just copying it here.
The Titanic posted:
My thoughts on landing and day night cycles:
CIG can pull off a day night cycle currently as well as a planet rotating (not orbiting anywhere, just spinning in place) by not requiring the ship to actually land. Just get close to the planet and you auto-land in a loading cutscene.
They can also time the FPS sun to the orbit sun pretty easily. Of course they should also be able to have the ring on their space station rotate easily too, so there's a good chance they'll fuck this up if they try it.
But a loading zone, planet rotation that doesn't require actual reentry, and an FPS day and night cycle could be very doable for their 3.0 stuff.
- Planet rotating. They can't do it because due to how CryEngine works, they would have to make the sphere an entity object - with a collider - and animated. Have you see the Port Olisar rings?
Probability of them doing it: 0%
- Planet orbiting. They can't do it because that would mean moving the spherical entity through the world. Which means adding a physics body to it.
Probability of them doing it: 0%
- Day and night cycle. They can do it in the editor as they have shown, because they are manipulating the light source manually. Doing that dynamically in the client is completely different ball game.
It's not trivial, and it will completely fuck up your lighting in both day and night cycles, requiring most of the object materials to be redone to compensate. I should know this because we ran through the same problem. We use SilverLining (and Triton for water) by
http://sundog-soft.com/ software because it was cheaper than doing it from scratch. Then we had to integrate it into our custom engine. It fucked up everything. And we had to redo a number of our asset materials. And we had to go back in a mess with the scene lighting because at some times at night, it was so very dark. Done right, you end up with results like the
LoD day/night shots.
Probability of them doing it: 50% (if they cheat instead of doing it correctly like SilverLining)
- Tying the TOD to the star
This is not needed as it's arbitrary and doesn't need to be mapped to any Sun. You just create a curve that's matched to your virtual day/night cycle. e.g. in LoD, a full day<->night cycle is 3hrs. But I can change that to anything I want. In fact, in the last server update, I made it 1hr so that we can continue to quickly test lighting issues in day or night without having to use our console cheat code to change the TOD.
Probability of them doing it: 0%
- Procedural world generation
There are two parts to this :
1) World Terrain
Involves creation of the world terrain (space or planet) using either 1) procedural generation or 2) handcrafting
No Man's Sky does 1
All my games use a combo of 1 & 2 depending on the game e.g. LoD has no procedural generation other than the ground terrain generated from pre-computed height map data
In my space/planetary combat games such as Battlecruiser/Universal Combat/Echo Squad, the entire world is data generated, while the planet/moon surfaces are procedurally generated from data. The POIs (star base etc) are hand-crafted in an editor, and placed in the desired locations.
In LoD, everything - aside from the ground terrain data - is handcrafted. The ground terrain data is generated from heightmaps which are stored on disk. That terrain is loaded into our editor so that the POIs can be placed where designed.
In SC, their SolEd tool is apparently used for them to design their world space to match what they have in the Star Map. All it does is say where things are. It doesn't actually generate anything. That data is stored on disk so that when the world is loaded, it knows where everything is located.
I have the same tool. It's called TED, is over 30 years (I shit you not) old, and looks like this (showing the Jupiter region). All it does is allow the manual placement of objects (planet, moon, jump anomalies) so that when the world is loaded, those entities are then mapped by data files which determine how to handle them in real-time via procedural generation. That's all it does.
2) World Assets
Involves placing assets in the world using either 1) procedural generation or 2) hand crafting
No Man's Sky does 1 & 2 . All my games use 1 & 2
My legacy games (Battlecruiser, Universal Combat, Echo Squad) which have space combat, use TED to create the space world, and PTE to handcraft POIs with pre-computed terrain. It looks like this.
This editing tool not only allows you to setup and test things like weather, ToD etc, but it also allows the creation and placement of POIs anywhere on a planet, anywhere in the game world.
There is a full album with more shots here:
http://imgur.com/a/KQ2IiThis entire world map you see below from Battlecruiser/Universal Combat series, was built using only those two tools. The engine does everything else in real-time.
And because the client and server handle all this crap on-the-fly, there are no loading (other than disk access depending on where you are on the planet) times or performance issues to contend with.
As massive and complex as it is, not to mention having low visual fidelity due to age, you can download the latest version of Universal Combat CE right now on Steam, and see everything they're trying to do - besides the fps in ships/stations part - working just fine. Just like in ED (though it doesn't have planets).
And the beauty of it is that a lot of world object such as stations, starbases etc are totally scripted into the game world. This way they can be added/removed as-needed; something that you can't do with a world built with static geometry. For e.g. you can destroy any space station in BC/UC/ES games, but you can't do that in Star Citizen.
This Vimeo video shows what Universal Combat CE looks like with a single space region, complete with orbiting planet, station etc.
Not a valid vimeo URL
A few months back, I
released the modding tools UCCE 3.0x. Even if you don't own the game, you can download it and check out the data files and tools.
STAR CITIZEN 3.0:They are apparently using World Machine for their terrain height maps. There are several tutorials on the Internet showing how to create surface terrain in CryEngine.
The terrain data is generated on-the-fly using some procedural techniques for terrain relief, rocks, fauna etc. No way you're going to handcraft all that crap manually.
They have tools that also allows them to 'paint' terrain features, generate relief data, as well as repeating objects like rocks, fauna etc giving more control over POI areas.
As above, they are also manually adding POI assets (base, derelicts, mission data) in the editor.
The problem they are going to have is in
performance and networking.I predict that 3.0 is going to be an unmitigated disaster if they release it before year end. But they will, because they have no choice. They have a LOT riding on this one, and Spergs really think this is the 'one' that brings salvation & vindication to the flock.
None of this is rocket science or brain surgery. You just need to build the tech, along with an engine to power it. You can build engine tech (e.g. see Outerra, Infinity Battlespace, Duel Universe etc) all day long, putting a game on top of it, is a whole different ball game.
And God help you if you put the cart before the horse, as they've done with Star Citizen - then your project is FUBAR. That's where they are now.
All they had to do was this:
1) Pick the right engine (not CryEngine) or build a custom engine from one that wasn't designed primarily for one type of game
2) Build the world editing tools for creating both space and planetary terrain
3) Build the space terrain so that the entire space world (as seen in the Star Map) is there
4) Build the space related missions and features
5) Build the planetary tech. Since this would be isolated from all of the above, it doesn't break continuity because, like what ED did, once you have it working, you LATER just edit your space world to handle planet entry into planets and moons
6) Build the planet related missions and features
But no, that was too easy, and they had an incompetent buffoon who hasn't worked in a dev team, let alone build a fucking game in almost two decades, at the helm. I would bet that, aside from Squadron 42 requiring ALL the tech they're building for Star Citizen, it too probably has planet based missions. Which is probably why they're now having to build this in 3.0, instead of fleshing out a "game", then adding that later. All this time could have been spent on 3-4 above to keep backers happy and dropping their knickers with each patch. Then you hit them with planetary tech one day - and boom - all their clothes come off. But you see, as backers have been giving them money this whole time, they had no reason to plan properly, let alone show meaningful progress. I mean,
6 years + $155M later, as I
mentioned here, look at this shit.
LOOK AT IT!!- 3.0 (Moons) is planned for Aug 2017
- 2.6 (Star Marine) // Dec 2016
- 2.0 (Persistent Universe + Multi-Crew) // Dec 2015
- 1.2 (ArcCorp Social Module) // Aug 2015
- 1.0 (Arena Commander) // Dec 2014
- 0.x (Hangar Module) // Aug 2013
They're so fucked, it beggars belief. No wonder they are now talking about 5 - 10 systems at "launch", when in fact they don't even have 1 (Stanton) ready.
Now, if 3.0 actually comes out, this is how much it has been scaled back....
Compared to what was promised almost a year ago
NOTE: The
LoD game engine was built from various middleware (why re-invent the wheel), and is completely different from what we've used for our legacy games. It was built from scratch.
And in case you missed my post about the furor that the GameStar preview has caused, you can
read it here.
This was Aug 2016
