Rocket Science News

Tech demo of geometry generation. 100 000 meters above the ground

Hello everyone and welcome to another developer update of “How do you like it, Elon Musk?”.

I spent most of the last month trying to answer the question: “Can I generate planet in the game as big as Earth actually is?”. Moreover I wanted this planet to not only be big, but also look like Earth, because the lore of the game need this and because not many games try to do this. Usually there are completely procedurally generated planets in these games, but with the similar color scheme and physics parameters to the real ones from our Solar System. But this was not what I wanted from my game.

There were several problems that I had to solve to achieve this goal. First of all the size. You can not use single precision numbers in the calculations, because, for example, with the planet radius five times smaller than Earth, calculation errors start quickly accumulate and you have nice looking cracks in the ground (it worth mention that Kerbin 10 times smaller than Earth).



The only good solution was to use double precision numbers. But then you could not generate planet geometry on the GPU, because video cards don’t like these numbers and calculations would be very slow. But CPU generation took almost 20 milliseconds which meant less than 60 FPS already and besides generation there were a lot of calculations left, like orbital mechanics, game logic, user input, sounds and music.

So I searched for the solution and found it. It called Job System and Burst Compiler. This is completely new stack from Unity Technologies that utilizes all your CPU cores and heavily optimizes the game code. I had to rewrite the whole generation system from scratch to support this. But the results were amazing. The whole generation process took less than 2 milliseconds on my Intel Core i5-4590 with 4 cores. This processor is pretty average according to Steam Hardware Survey. And I think I can improve these results more up to 1 millisecond. But there is a downside of using this new tech stack — it is currently under active development and may be unstable on some hardware and software configurations (one more reason to release the game in the Early Access).

The second task was generating Earth-like planet geometry such as continents, oceans and mountains. I could use NASA heightmaps for that, but the problem is, that the maximum height map resolution that Unity supports is 8192 x 4096. One pixel of height map in this case gives you height information about 9 square kilometers on the surface of planet which is not enough. So I decided to use combined approach for this. I used NASA heightmap to determine base height of created 3 x 3 kilometers area and the smaller details will be generated procedurally. The only one thing that I didn’t solved yet is the rivers. Even the biggest rivers are too small to be presented on heightmap so I need somehow generate them. Maybe I will postpone this problem to the Early Access period.

Height map of Earth

The last one is the texturing. I could not use traditional height based approach, because on such large scale it looked very unnatural. Procedural approach even worse because it can create snow in Africa and subtropical forests in the Greenland. The combined approach saved me here too. I created the simple climate simulation system, that generated temperature and moisture maps, that I could use to determine which biome is present in this place and than apply the appropriate texture set to it. Due to simplicity of climate algorithm it produces not totally physically correct results, but it somehow looks right. And there is room to improve too.

First results of climate algorithm: moisture map of the Earth. Dark areas are dry, white areas are wet.

This three components are essentials for planet generation and they will be presented in the Early Access release. But this only the beginning of the path. I will definitely try to evolve planet generation system during the EA. I dream to implement grass, forest and cloud systems and it will be possible with your help and with the new technologies available today.

See you in the next update.

Hello everyone!

Here is the first Developer Update. Today I want to talk about features and decisions of "How do you like it, Elon Musk?", that make this game different from the main competitors, and what I need to do to successfully reach the release in the Early Access. One small note, before I start. The following is a current vision of the game, and it may and probably will change in the future, as it has happened before several times. You are now aware of possible changes, so let's begin.

The game loop consists of three huge parts: managing the spaceport, constructing the rockets and launching them into the outer space. The main focus will be on the spaceport building and management, while other parts will extend and add meaning to it. Like in Kerbal Space Program the main focus is on the designing your rocket, and other game mechanics (science, upgrading buildings, even flights) only exist to support it. So I had a difficult task, how to "reinvent" rocket construction and flights to make them fresh, interesting to play and at the same time not much distracting from the main theme of the game. And, I think, I solved the flight part of the problem at this moment.

You will have no direct control over the spacecraft. You will need to develop a flight plan before launch, assign it to rocket and rocket will execute commands from the plan to perform the flight. The flight plan is developed at the mission control center, where you can simulate flight and the state of the entire solar system for months in advance. The typical text version of the flight plan may look like:

• T -00:00:02 set the engine throttle to 0.5
  
• T -00:00:00 liftoff
  
• T +00:00:30 start gravity turn to the east
  
• T +00:01:54 decouple launch escape tower
  
• ...
  

And in the current implementation:



If something will go wrong, you'll be able to send the set of correction commands to the rocket and hope it will solve you problems. You will also be able to reuse existing flight plans for the rockets of the same type and do not repeat the same tasks all over again (such as getting rocket on low Earth orbit). But this way of handling flight has a trade-off. Physics simulation should be much simpler and performed for the whole rocket at once, not for its parts. Without this simplification planning UI becomes slow, unresponsive and very frustrating to use. Maybe I will be able to solve this in one of the updates in the Early Access, but this part is not as critical as the other ones.

The rocket building part is trickier and I didn't fully figure it out at this moment. I don't want this system to be as complex as it is in other games. But I like the idea of combining rocket parts with different parameters and different prices. It adds depth and good progression system to the game. There is nothing complicated about rocket parts, in fact, I have this system already in the game, but if we start talking about the attachments between the parts, I will quickly become mad. For example, you are able to attach any rocket part to almost any other one in KSP. This possibility produces an infinite amount of rocket configurations with more than 98% of invalid ones. And the failure to launch the rocket is fun. It is the solid part of the game. But I’m not sure if the launch failure will be fun when you have no direct control over the rocket and you can’t revert the flight after submitting and starting plan execution. Sure some unexpected accident will add the variety and add weight to your decisions, but rates of the failure should be much lower, to progress successfully in the game. Also due to simplified physics simulation it is very hard to validate the correctness of the assembled spacecraft and check if it is able to fly.

I have several ideas how to deal with this, but I need to prototype all of them to understand which is better. The first idea is to strictly define connection points and limit the part types you can connect to them. The second one is to define basic hull configurations for rockets and give to player the ability only to fill the insides. The third one will give the player a choice from which parts the rocket should consist and then automatically assembles it.



The other systems such as planet generation, basic spaceport building, orbital mechanics are in some form ready. So when the rocket construction will be implemented I can finally put them together and start to develop the basic game sequence. After that the content can finally start to arrive. It would be great to deliver the game with all described systems to the Early Access. If I will have not enough time for that, I will probably delay the spaceport building to the first update after EA, because the flight systems are fun even now, but spaceport building requires a lot of work and fine tuning to become interesting.

In the next developer update I will talk in-depth about planet generation and the world of HDYLIEM. See you soon