I wanted to publish a game trailer today instead of the usual update, but I was blocked by a critical bug in the Unity engine, which crashes the build. And because I use only ingame footage in the trailers, we’re gonna have to wait one or two weeks until it will be fixed. On the other hand, It is not that bad, because I will add more content into the game in that time and trailer will only get better because of that. Let's talk about work that was done and need to be done, so I can finally release the game. Note, that there is a link to a small survey at the end of this update. Please take a part in it, it will help me a lot.
This is how the Earth miniature looks like in the test scene in the project (3km radius)
Preparing a game trailer is a kind of preparing to a small release. You need to add enough content, make sure, that everything is looks good and there are no horrible glitches. Also stable 60 FPS during recording is very important, so you need some time, to optimize the game code. On top of that, you need to think about the story in the trailer and what message you want to convey with it. And finally, you can’t waste a time making things, that aren't gonna get into the game.
That’s why it is hard to tell, what exactly was done for the game during past month. I made a lot of small features and fixes, scattered all over the project. Other than that I finally started making content for the game in form of rocket parts, but I'm not gonna spoil them, because they are part of the trailer. And yet I have prepared some things to share with you.
The first thing is a part attachments. I partially covered this topic in the May Developer Update, but there were a few questions I had to answer. The most important one is what to do with the side attachments. For example if we have fuel tank, there will be at least 5 different ways to connect something to the sides of it.
Here is a top view of the fuel tank and six different types of side connections to it.
Due to the fact, that all attachment points is preconfigured and precalculated, they can not be added to the rocket part dynamically. But representing every type of connection by separate item in the assembly shop UI means adding six same fuel tanks with the only difference in number of attachment points. Which adds a lot of clutter and not very intuitive. After some trial and error I found a good solution: part configuration.
Thus, in the case of fuel tank above a small icon will appear on the part UI, which means that this part is configurable. When you click on it, it will show available options.
The great thing about this, is that you can have different types of configuration per part. For fuel tank it can be not only number of attachments, but type of it contents: only fuel, only oxidizer, or both in right proportions. Obviously, these choices will have an impact on the flight characteristics of the rocket part. For example, even for different number of attachment points each variant will have slightly different mass and air drag. And I'm not even talking about the types of fuel tank content, because it opens up so many possibilities to build your spacecraft.
One interesting thing I learned from modeling rocket parts for the game, is how precise they have to be. Because the shape of parts matters and is involved in the physics calculations, even a small asymmetry can lead to instability and unpredictable behaviour of the whole spacecraft. Usually I am a little bit of perfectionist when it comes to modelling. But in this case it's really justified, especially for the parts that put rocket into orbit.
Another good task, that I did and can show something is improvements to interpolation algorithm of planet geometry generation. Earlier, you'd have noticed pixels on the planet due to the fact, that heightmap has finite resolution. Now everything is smooth.
Before the change
After the change
As for the future work on the game, it comes to making content and establishing the game loop and preparing to the release in Early Access. The only two systems, that are missing right now, are the direct flight controls and contracts system. The first one brings more fun into the game, if you don’t wanna plan your flight ahead, and want to just fly around and explore. The second system is needed for the Survival mode, where you should actually earn the money to pay salaries and unlock new rocket parts and buildings to keep your space center going. It worth to mention that the second mode will be Sandbox, with everything unlocked from the beginning, for those who like to have fun and experiment on their own. Both systems are not that hard in implementation, so I don’t see any big problems with them, compared to the rocket physics, for example.
For the preparing to the release, I need some data from you - my core audience. What hardware are you using and what are you waiting from the game the most. I can then set priorities correctly and concentrate more effort on the important things. So, to help me to do it, please take part in a small survey.
Thank you, stay tuned and wait for the trailer with the release date announcement in it! It will be published soon™.
October Developer Update
Hello, friends!
This month I made a great progress developing the game. I spent it almost exclusively on physics, implementing things I mentioned it the previous update. And everything worked out almost exactly as I planned and I did even more than I could have imagined. So, without further ado, let’s talk about it.
Some rockets were hurt while preparing this update
Rocket physics
The only good way to support timeline and time rewind is by representing the spacecraft with one physics body. But since the spacecraft is made by player and consist from different parts with different shapes and masses, I needed a good way to account for it in the simulation. Otherwise, you will immediately feel, that the physics is not correct. I solved it by calculating the forces that affect every part individually and then applying them at the right positions of rocket's body. So, if you will not balance your rocket right, and there is not enough auto stabilization force, it will eventually start flipping to the side with greater mass.
Aerodynamics
I used USSA equations for the atmosphere model. Since Earth and Solar system are in real scale in the game, the equations was not modified in any way. The only difference is that Earth atmosphere in the game ends at 110 km, where the pressure is so low that it can be neglected. The surface area and dimensionless drag coefficient are pre calculated for each part, which means that the shape of spacecraft will affect it flight characteristics. The approximations I used for calculating drag forces give decent results and have a good performance. But I am open for the better drag models in the future.
Collisions
This was the hard one. All collisions are handled by PhysX. And there is always a tradeoff between accuracy and performance. If the collisions were solved even a bit incorrectly, spacecraft will be immediately launched with 10x speed of light into abyss, because bodies has huge masses and moving with the high speed in the simulation. One small error and the whole experience will be ruined. But if you increase accuracy too high you will receive a poor performance and angry players. While I found a decent settings for collision solver, I will expose some of them in the game settings, so everyone will have chance to tune the game to their computer capabilities. Here are some funny gifs before I tuned the PhysX and fixed tons of bugs.
A simple collision with the ground threw a ten-ton rocket, as it was made of plastic
Here collision between two parts of rocket send both to the orbit of Pluto
What else?
For now the water physics is missing. I wasn't be able to quickly find the good algorithm for that. I could use the same drag model as for atmosphere, but with higher density, but I don’t think this is the only and right solution. So I will continue investigate this topic after release. For now there are two options: every spacecraft will immediately explode on the contact with water. Or it will just ignore the water and fall though it. I like the first option more, because it destroys immersion to a lesser extent.
Also I didn't implemented wings yet, but I will do if I will have time for it.
Not only physics
When I got tired of fixing physics, I switched off to another area of the game. The first one was stars. Initially I used simple texture for it. It was huge (almost 8 Mb with the resolution of 8192 x 4096), but even with that stars looked blurry. Also all of them had the same color which is far from reality.
Old stars
So I implemented own starfield system using the real world star database, which includes more than 110k stars. Every star now uses a color, brightness and position from that database. Even with 65k stars all the data occupied only 2Mb of memory, but you usually don’t need this many. You can see about 6000 stars with your naked eyes. And again I will expose starfield settings, so you can change the stars count. maximum brightness and exposure how you would like. The only thing I am missing now is the Milky Way, But I will make it sooner or later too.
New stars. It is better to compare both images in full-size in the browser
The second one is the orbit rendering. Initially I used builtin Line Renderer, but it was not good, when the orbit was far enough from the camera.
Well, time to implement custom orbit renderer!
It is better to compare full-size images here too
At the end of this month I felt like I created my own game engine for the flight simulation. Almost everything is custom: planet generation, orbital mechanics, drag and gravity, starfield and even my own version of the line renderer. Funny enough, I got around 80 FPS in the flight on my computer (i5-4590 and GeForce 970), where so many different calculations happens. And only 55 FPS in the spaceport, where nothing complicated is going on, just a bunch of objects and light sources.
It’s time to finish this update. I will leave you a gif where you can see the result of all work done in this month. It looks so simple, right? But it was not easy no get there.
Note: the gif was recorded on 5x time warp
September Developer Update
Hi there!
September was a very productive month for me. It is much easier to work, when there is overcast and +5 °C outside. During this month I managed to solve the most difficult task in my life: the rocket physics.
Let me explain. As I have said many times, the ability to plan flights ahead and perform them without direct player control and the Solar System in real scale are the main features of the game. But it also imposes several limitations.
For example, due to floating point precision of PhysX all physics calculations for rockets with running engines should be performed no further than 10km from the world's origin. Otherwise, the accumulated errors during calculations will lead to huge jittering and in the worst cases the Kraken will appear and destroy your ship. This is usually solved by constantly moving the world around the ship, so it stays near the origin all the time.
Imagine this sphere is actually Earth. Then the size of the area, where spacecraft could flight before shifting the whole world will be less than one pixel!
But here is the problem. Imagine two ships, one orbiting Mars and one near the Earth. The average distance between them will be around 225 000 000 km. And it happens that both turn on engines at the same time. What to do in this case? It is impossible to move the world in such way so both ships were simultaneously in the world origin. Well then we must sacrifice one of the ships, by moving another to the origin, because the error would be so huge, that first ship will instantly crash into the planet. Or the game should not allow that situation. But this ruins the whole point of the flight planning.
Initially I tried to implement simple flight physics in double precision on my own. It worked good for small rockets with one engine and gave extremely precise results. But the were much more cases that I needed to handle:
Several engines with different positions and angular forces they cause to the rocket.
Basic aerodynamics, where shape of the spacecraft will affect its movement in the atmosphere.
Collisions with the surface and other ships.
There were no way that I could ever handle all these cases in reasonable time and develop them without going crazy. And I could not release the game without these basic things.
So I started to search solutions. And after three months the solution came from the unexpected side. Less than a year ago Unity released the Multi-Scene Physics (or Multi-Word Physics) support. It means, that I could run several invisible physics simulations at the same time and they will not interact with each other. So in the case of two ships above I just needed to create two Physics Worlds, place physics representation of rockets into them, move the world in each simulation so that the ships are in the origin, perform calculations and then synchronize the results of the simulations with the visible world. Sounds simple, right? Of course it is hard as hell! But it was much simpler than reinventing the physics engine.
Here spacecrafts are far from each other and both simulated in separeted Physics Worlds (big green spheres)
But how ships will interact with each other, if they placed in separate simulations? This an interesting question. If the two or more ships are approaching each other and the distance between them become less than 6 km I will put them all in one Physics World. If the distance exceeds this number, I’ll move them back to separate simulations. And because I perform all calculations for whole rocket and not to its parts it works pretty good even on my 5-year PC. Obviously, there is a big room for performance improvements. Which will be one of the main tasks in the Early Access.
Now they are close and we are moving second spacecraft in the simulation of the first one
There are still a lot of work with this system. For example. I’ve solved different engine configurations and partially atmospheric drag at this moment. The collisions need to be implemented, but now I see the way and feel confident, that it would work. And, of course, there are tons of physics bugs waiting for the fix. Maybe I will prepare some funny gifs with them next time.
Thanks for attention and don’t forget to join our Discord community!
P.S. Valve have changed Steam algorithms two weeks ago and game’s store page traffic went almost to 0 after that. So, if you have friends, who love space and rockets, please send them link to the “How do you like it, Elon Musk” page. You are my only hope.
August Developer Update
Greetings!
Today will be a short update, because I am at small vacation right now, visiting my grandparents. They happen to live in such place of Russia where stable Internet connection is rare than a good indie game on Steam these days. But I found a base station deep in the fields and managed to write and publish this update.
This is also the place to draw inspiration from and get good references for the development
The first thing I am excited of is recent announcement, that High Definition Render Pipeline (HDRP) will be out of preview this autumn. HDRP is a high-fidelity next-gen render pipeline built by Unity to target modern (Compute Shader compatible) platforms. It provides great new tools to author content, like a Shader and Visual Effect Graph, solid API for high performance custom rendering systems, and a lot of features from volumetric lightning to subsurface scattering. I started to use it a year ago, when it was in alpha stage. Even in that early stage it gave good results. And now Unity Technologies promises, that HDRP will become stable just before the HDYLIEM release! So I started updating the game to the latest version of Unity to get the stable HDRP as soon as it will be ready.
Example of volumetric lightning in HDRP
Secondly, I’ve added the Moon heightmap into the game. It was easier than I thought, so the next in line is Mars. I have also rewritten the planetary configuration system, so every planet will be present in the Solar System even there is no heightmap or textures for it yet. Such celestial body will look like a white sphere, but you will be able to land on it anyway.
Test scene with the Moon heightmap applied
The last thing is the planet texturing system. The old system supported only 16 materials (which is nothing for real scale planet), produced poor results and have no room for configuration and future improvement. So I had to develop a system that would procedurally select materials based on set of easily configurable parameters. I researched how it was done in other space games and in the popular libraries on the market and came up with my own solution.
I’ve developed procedural texturing module for planets that includes a configuration file which supports 32 layers of materials (and I can increase this number up to 64 in the future). These layers work like in Photoshop, but they have a bunch of parameters, which controls if the material will be placed on top of the previous one or not.
Inspector that I use to configure procedural texturing
As you can see, there are four main parameters for each layer now: height, slope, temperature and humidity. Each of them is a curve which specifies the probability of material selection depending on the parameter value. There are more parameters in the config for granular tweaking of each material such as weight, tint and blending contrast. This config then encoded into texture and passed to the shader. And finally, the shader decides which material to use at this particular point on the planet's surface. Combination of all parameters with the addition of some noise function give the results I like. Moreover all these configs were built with the mods support in mind, which I will add into the game as soon as API and feature set are stabilized.
Another test scene with the procedural texturing. Here only three materials are blended together, and there is already no tiling and repetition
That’s all for now, I'll try to get out of the field, and I wish you a productive autumn!
July Developer Update
Hello friends!
On August 1st, 2018 I decided to leave the prototype of the isometric shooter I was working on and make something small in one or two months. I started with a 2.5D arcade about launching rockets into space, where you were able to collect resources, bonuses and boosters during the flight and then spend it to upgrade your spaceship or buy new parts for it. And I don’t know how it has happened, but here I am, a year later, working on one of the biggest and ambitious games in my live. The great news is that the game vision has not changed since January, when the first Dev Update was also published. And I am slowly but steady getting closer to the goal.
Prototype of the game that I abandoned for HDYLIEM
As for development, I need to work on three main areas. First of all is the game sequence, which is important not only for the release, but for early playtests too. It is the hardest task I have ever had, because the first three hours of the game in Early Access will determine the future of the game in store. This includes compilation of all game systems into solid gameplay and making content for it as well as creating tutorial and hints for all of that. And I can’t even send the game to my friends to try it out before the tutorial will be developed. And it is hard to make the tutorial, when you not sure if some particular parts of the game is working as intended. But sooner or later, I will figure it out.
The second one is to brining all game systems to the “ready for Early Access” state. For example, I am happy with the planet generation system, but I am not satisfied with the planet’s rendering. There is an annoying tiling on the surface and lack of different materials. I need to develop a texture layering system to remove tiling and give the biomes more natural look. Another example is the water, that looks like this in the game right now:
Not great, not terrible
I found a several good water shaders, but they work only on planes and need to be rewritten to work with planets. This is very interesting task and it will be really exciting if the water in HDYLIEM will look like this:
Good water is usually 1/3 of the success
Another thing about planet generation is that I found the way to increase the heightmap resolution from 8192 x 4096 (the max allowed by Unity) to pretty much unlimited. The only limitation is the memory and disk space. For example, I found and will use 43200 x 21600 heightmap for Earth, which means that instead of 4x4 km area, one pixel of heightmap will cover 0.7x0.7 km! If you know, where I can find heightmap with the higher resolution, please let me know in the comments.
This is the part of heightmap with the Himalayas. You can even see rivers here.
Every other game system has some things that need to be finished too. For example, I need to implement patched conics for orbits, to show the spaceship trajectory, when it is leaves or enters the sphere of influence of the celestial body. Direct controls for flights without flight plans need to be done too. And there are a whole bunch of spaceport building, flight planning and rocket assembling tasks waiting for my attention. But the great thing about this is that I can switch between them every time I tired of the previous one. They all are completely different and each of them brings an unique set of problems and challenges.
The last one is the polishing pass that includes sounds, effects, optimization and quality of life features, like game settings. Unfortunately I haven't even touched this yet, but I finally started to think about this it, which is a good sign.
Every day the game is one step closer to what I imagine in my head. Not only this, but my passion for space, as well as your constant support, helped me to overcome this year-long journey and keeps me going. Thank you and see you next time.
June Developer Update
Hello everyone!
First of all, I have updated some screenshots on the store page, so you can go and check it out. It is still a work in progress, but I think, they better represent the current state of the game and show more gameplay, than the old ones. Also I am often asked about game trailer and I agree that it will describe the game better, than the thousands words. But good trailer requires well established gameplay, a lot of game polishing, and enough content to not disappoint anyone (and I still changing a lot of things in the game on a daily basis). So, I think I will be able to publish the trailer three weeks before the release in Early Access. And I hope it will happen in the 2019.
Now it’s time to talk about spaceport building in “How do you like it, Elon Musk?”. As I always said, this will be the main focus of the game. While this game mechanic is pretty easy to implement from the coding perspective, it is hard from the game design point of view, because there are too many ways of how you can approach this problem. You can also pretty easily stuck infinitely iterating over it and keep adding new systems to the point, when the game becomes unplayable complex mess of mechanics, numbers and buttons.
I should have come up with a set of rules and restrictions to avoid falling into this trap. And set them in stone after that, no matter how it will be difficult to follow this restrictions, because it is only way to find your way. So I will outline the set of found restrictions in the following paragraphs and we will deep dive into them in the next developer updates.
The story begins, when you get under control the ruins of the old Soviet spaceport. All you need is to transform it into the space center of the future. Unfortunately, the building permit was not given and you are not allowed to build anything on the surface. The only way to expand is to build deep into the Earth. Each building opens up new opportunities, complements existing ones or makes life easier. For example, laboratories allow researching new rocket parts and buildings more quickly, storages and workshops - to store and process items into resources, and generators - to produce electricity on your own.
Sounds familiar, right? The next step was to make this gameplay unique in its own way. I spent a lot of time thinking about it and came up with the first rule:
Nothing works without people.
Every building requires staff to operate. There are workers, engineers and scientists you can hire and assign to buildings. The more staff requirements fulfilled the more features the building have.
For example, each worker unlock more space to store items in the storage and when you will assign all four of them to the building, you will receive the ability to automate collecting or delivering resources to other production buildings. But don’t forget, you should pay every employee at the end of the month. And if you don’t, they will quit and will never return.
The second rule almost immediately arose from the staff system:
Every action takes time.
The game will be in real time. And the time will become the second main resource after money. Do you want deconstruct the Soviet ruins? It requires four days. Do you want to build a coal generator? The workers will finish it in a week. Of course you will be able to speed up time up to one day in a second. But you should think twice about this, because the end of the month is coming and you should not only pay salary, but taxes and bills too.
The third rule is the matter of my own taste. I hate routine and monotonous tasks in games if they lasts for entire game and not required by narrative. But in the right proportions they can set the tone of the game or make you feel current situation. It is just another tool that you should use carefully. So, the third rule is:
Every routine and monotonous task should be automatable.
For example, in the beginning of the game you will have few resources and money. And you should do some tasks manually such as moving resources from building to building, or throwing coal into the furnace of the coal generator. But when you’ll make some money you will be able to hire more staff to make it for you. But the option to do something manually will always exist, for example, if the hard times come, you can save some money by performing all this work by yourself. By the way, the flight plans system was born because of this rule.
The last rule is my preference too. I’m not a fan of linear upgrades systems in the games. Sometimes it’s ok, like in Action/RPG, where the upgrade trees exist just to make you feel the growth of your character. Or in Civilisation you feel how is you nation developing, thriving and moving from one era to the another. But I think that in some games it is a waste of content and potential. Why you should build, for example, the tower and then upgrade it ten times to do something useful with it? And very often there is even no situation, where you actually need the tower of level 5, so there are no interesting choices to make. The actual fun is delayed by meaningless actions to increase the playtime and create an illusion of depth.
So the fourth rule:
Avoid linear upgrades system as much as possible.
This the the hard one, because every game needs the progression system and linear progression is the easiest one and you almost instinctively want to add it into the game. But I think I solved it in theory and came up with nonlinear system with interesting choices and room for sinergy. And it called “Mechanisms system”. I hope I will tell you more about it in the next updates after I actually try to implement and play with it.
Now you know the four main pillars of the spaceport building. As always tell me what do you think and see you next time.
May Developer Update
Greetings!
Today I will talk about the rocket construction in “How do you like it, Elon Musk?”.
As I described in the January Developer Update I had three ideas how to develop this system. And I had one important requirement, that this system needs to be simple enough but at the same time giving the possibility to combine rocket parts in different ways. So after some experimenting and theorycrafting I decided to stay with the slot-based system. But the problem was that there were at least five different approaches to creation of this system with its own advantages and disadvantages!
Let's imagine that we have four classic rocket parts: command module, decoupler, fuel tank and liquid fuel engine.
Note:this and folowing images are from the prototyping process
I wanted the slot system to validate this set of rules:
you can attach as many fuel tanks to each other as you want;
you can not attach engine to command module or to decoupler;
you can not attach any of this parts on top of command module.
So the first thought was to restrict attachments by part type. For example, command module has two connection points: top and bottom.
Imagine that you can attach only utility parts on top and fuel tanks or coupling parts to bottom. Two problems immediately arise. The first one is how to visually tell the player what you may or may not to connect to each other. List of part types in the tooltip is not a good idea. And secondly, this system is too restrictive. What if I want to attach six small engines to fuel tank instead of one big engine? Or if only some of utility parts can be connected on top of command module?
After weeks of suffering in search of the best solution I finally came up with one. And as always, it seems very obvious when you found it. So, meet the two pillars of the attachment system:
Connector:
Connection slot:
Each part will have from one to seven connectors or slots arranged in a specific way. Attachments from the above rocket parts now look like:
You will ask: “How does it work?”. The answer is, that there is only one rule now. All connectors from rocket part should be placed into connection slots from another part. That’s basically all.
This system will provide me the ability to restrict some invalid part configurations. Also I can try to implement a bit more complex rocket physics now. At the same time it gives you a lot more freedom to construct different rockets from the same set of parts. For example, you can connect two or three medium engines (with two connectors) to the fuel tank above. Or from one to seven small engines with one connector!
Also part attachments can be easily represented on the part selection UI:
I also experimenting with the UI color scheme and you can see it here.
While this system is pretty simple from the player point of view, it is a nightmare from the implementation side and it will shift the game release further away. But I think it is totally worth it. Also I have several ideas how to further extend this system, without losing its basic simple rules.
So, what do you think about this system? I appreciate all feedback, always read it and take to consideration, so do not hesitate to comment.
Indie Battle
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.
April Developer Update
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.
March Developer Update
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.
