Hello everyone!

Just wanna share with you, that our game passed the first stage of "Indie Battle" contest from the Russian magazine Igromania and LG Electronics. And this is amazing! Despite I used the old screenshots in the pitch for the contest (the new ones are not ready yet), it got attention from the journalists. And now the industry experts and players will decide who wins.

I want to thank all of you for your interest in the game. Because of that I decided to apply and now gained +10 to productivity and chance to win. And it's time to get back to work.

P.S. Unfortunately, there is no English version of the contest web page, but here is the link if you are interested anyway.

Hi there!

Another month have passed and it’s time to give you an idea about current work progress and state of the game in general. So, let’s get started. Note, that all screenshots listed in this post are presenting work in progress.

I can split this month of work into three main categories. The first one would be an assembling different game systems into the working game. I talked about these systems in the previous dev updates, they are: spaceport building, orbital mechanics, planet generation and everybody's favorite rockets and flight systems. Before, they existed separated from each other and you had basically four different mini-games without gameplay.

Now the spaceport is located in the right spot on the Earth and have a correct day-night cycle, Sun azimuth and altitude and also proper night skies with stars. This spot is taken from the longitude and latitude configured via file. Moreso it correctly calculates the altitude of this position on the planet and places the spaceport right on top of the planet’s surface. While this spot will be pre configured on the release (with the longitude and latitude of Vostochny Cosmodrome), it opens up opportunities for future features, like selecting the place of the spaceport on the start of the game or for user mods (It was interesting to place the spaceport on the Mount Everest even for me).

From the spaceport building named Control Center you can open the map of Solar System and look at all launched spacecrafts at this moment. You can select any spacecraft and load it in the flight mode. You can also launch the new rocket from here by selecting rocket draft and flight plan. And finally, you can design your own rocket in the Assembly Shop from the parts that you have.



There is nothing new here compared to other games, but the basic game loop was established and I can start to finally evolve other systems, like spaceport building and flight planning from there.

Speaking of which, I finished the work on the flight planning interface and it will fall into second category. So, what I would say about it? It was the hardest part of the game to develop at this moment. I spent almost half of month on this task (significantly more, than I planned). There were so many nuances and edge cases that I could not imagine. But it was completed (with some bugs of course).

This works as follows: you pause the time, select the rocket part, and its interface opens. You make changes and flight command is added to the timeline. Then you can resume the time and see how the command affects the state of the rocket. You can move forward and backward in time, add new commands and move or remove the existing ones how you would like. And flight planning system will recalculate the whole word state for you!



As I expected, this system turned out to be great for complex flight planning, where high accuracy is required, like docking with the space station. And it is also great for flights automatisation. But as I thought, it feels over complicated for simple things, for example, if you want just launch the rocket and fly around for fun. So I will rethink this part of the game and with the high chance will return the direct control over the rocket back to the player. Of course, you will not be able to turn the time back or even pause it outside of flight planning interface. Also all commands will be immediately applied to the rocket. So you will basically get the ability to control the rocket like in other games. I feel like more different ways to perform a flight are definitely better for the game. On the other hand, it will increase the required development time, but more on that later.

And the last but not least is the UI design. I feel like a lot of indie developers hate to work on UI for games, often postpone this task as long as possible and just slap some default grey panels and white buttons into the game and then push the release button. I am also not very enthusiastic about working on the UI (it contains a lot of repetitive tasks, that you did millions of times in the past), but more than that I hate such “made to fuck off” UI. So I spent the remaining part of the month to lay the groundwork for the best interface I could make. Nothing fantastic here, but it looks acceptable for me.

For those of you who read this dev update so far I prepared and published the Development Roadmap and you can find it here. You can get the basic idea about planned features and current work progress from it. As always, everything is subject to change, but as a time goes, it will happen less often.

The last thing I want to talk about is the release date. Initially it was scheduled for May 31. But I thought a lot about it and came to the conclusion that I don't want to release some smashed together and barely working systems and hope that it goes away. Even in the Early Access I want to give you some complete game experience and minimum three hours of gameplay. And one month left is not enough to reach this goal. So I decided to postpone the release date to July. The exact date will be announced later. But I hope I will manage to prepare the game trailer and update screenshots for the store page by the end of the May.

Thank you for your attention, don't forget to join to our community on Discord or follow me on Twitter or subscribe to my Youtube channel. See you next time.

Hello, guys.

Today I want to talk about orbital mechanics and spacecraft physics in "How do you like it, Elon Musk?". Around the middle of December, I came to idea, that player will have no direct control over the spacecraft and all flights will be performed through the flight plans (you can read more about this in the January Developer Update). Before that I had an arcade prototype of flights in the 2.5D, like in the thousands of other games on mobile stores, where you can fly up as long as you have fuel. You should collect resources, repair kits, avoid obstacles and so on. In other words, it looked like this:



This was fun at the beginning, but as time goes by, and especially with the creation of planetary and atmospheric systems, it became more and more obvious, that this part of the game is out of place. Luckily, I got that idea about the flight plans during the discussion of this problem in the comments on the first article about the game. It sounded great, but I had several problems, that need to be solved.

• Flight system should be moved to full 3D
  
• Rocket assembly will became more complex due to p.1
  
• Unity physics will not work for the flight planning interface and in general for the game.

While the first to points were solvable, I had no idea what to do with the last one. Let me explain, why it was the case. Here is the prototype of flight planning interface:



It is like timeline with commands. You will be able to scale the time, fast-forward it or move to any point on timeline and then add the command (thick vertical white lines). When the command reaches the white arrow, rocket will execute it. Command is an any action, that can be performed by rocket part: engine start/stop, turning the spacecraft or decoupling of empty fuel tank. The problem with standard physics in this case is that it state-dependent. That means if, for example, you need to jump to 10-th minute of the flight, the game have to simulate the whole world state for 10 minutes with the step of 0.02 seconds. As a result, the game will hang for several seconds even.on the most powerful computers, which was not acceptable.

So, I spent plenty of time searching and implementing the solution. And it called “Two-body solver” and this is basically the orbital mechanics for celestial bodies from the physics textbooks, where the state of all bodies became a function of time. Which was exactly what I needed for timeline. Moreover, I could use real orbital and body parameters for all planets and their satellites of our Solar System. I got it from NASA website, added to the game and you can see the result below.



This was great feeling, because the game suddenly acquired an additional value: I could set any date and see the real positions and rotations for all planets of Solar System. But what does it mean for gameplay? It means that the content of the game became almost infinitely expandable: in the far far future players will have an opportunity to fly around and explore not only Earth and Mars, but the whole Solar System! It sounds very bold, but it really has that potential. If we stop dreaming for a moment and go back to Early Access release, the whole system will be here, but initially you will be able to land only on Earth’s surface. The Moon will arrive in one of the next updates and then one by one will come other planets.

The only drawback of two-body solver is that it can not be used for accelerating bodies and you need to use the state-dependent integration solver in this case, which is a bit slow. That’s why you can't speed up the simulation more than four times in KSP, when the rocket is throttling. As I mentioned in the first dev update, I managed to partially solve this by simplifying simulation and calculating physics for the whole spacecraft at once, not for its parts. By doing that I got the maximum of x30 time warping without significant loss of accuracy when rocket engine was working. I think, it can be further improved in one of the following game updates.

That’s all for today. It is a bit short, but release is closer and closer and I have so much things to do. Now I have to work for at least seven hours a day, seven days a week, to complete the most critical systems for the game. But I am very inspired by seeing your interest and support. And if you interested to joining to our space loving community, you can do it by joining to our Discord channel. Thank you and see you in the next update.

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