Ideas for our game concept
Hello, in this devlog we would like to talk a bit about the current state of the game and our main problems we are facing.
First of all, our biggest problem is of course time. We can't work full time on this game, so updates will usually take a bit to make. Also, this game developed out of a jam game. We have constantly to rework old code and concepts to be able to build in new features. In a matter of it, we are now working on the version 0.3.0 where some big features will be implemented!
Planets and orbits
One of our big changes will be a solar system where you constantly are captured by another planet or sun. Our idea is currently to have two suns moving around a central point. It's called a binary star and will make the solar system hopefully much more interesting. Here are we currently at a point where the base mechanic works, but many other problems occur:
- it's complicated/unintuitive to navigate in space
- travelling needs a lot of time
- the preview of the orbits take way long to calculate
If you ever have played KSP, you might have noticed that it wasn't easy to dock to another ship of yours. You have to be in the same position at the exact right time with the same velocity. This would also apply if you want to attack an enemy. We don't want you to focus on this part of the game, because there are so many other things around you that are way more interesting. Either we support the player by implementing a guiding computer that handles all those calculations and/or we make the moving unrealistic with a mode where you move your ship but don't affect your orbit. We haven't tested one of these ideas, but it is both will likely have major problems. If there are players out there who want to control the satellite manual, we will implement an expert option, but at the moment it isn't worth the work.
Travelling to another planet or moon takes a lot of time. We are unsure of solving this issue by a fast-forwarding the time like in KSP or take a whole different approach with a warp system, called "Starlink".
At last, all the calculations for a preview path are currently far too heavy, as we want that anything affects everything. This is because you need to calculate the path every frame if you accelerate. We might go with a more simplified calculation where we hard code who affects who. But there are tons of things I already tried to improve the performance, like using a Compute Shader, and I will also try more ideas I have. It is a very tough topic with many papers available on the internet, but all of them have very complicated math with takes time to understand, just to realise that they don't work for our situation.
Besides those problems, it will be an interesting situation for the player if they are somehow behind a planet and have almost no energy because the solar panels are not working. There will be more ways to generate power later (probably not in this version) but we talk about this topic below.
It was quite weird to fly in space without any visual feedback. It was in theory very simple: build a thruster as a module, then loop in the update through all of them, look at the orientation and fire them if the player presses a key. And after a few days, it worked as intended!
We decided to put on every unused connection little thruster so the player will always be able to control the
satellite. These don't have enough thrust to go anywhere so the player has to build big ones if he wants to go to a
different place or flee of an enemy. Also, we decided to have no fuel because then you would run into the problem of
not being able to manoeuvre and it would be necessary to have a fuel production.
Currently, they look as in the picture below, but we might change the look of them.
We want you to be capable of creating multiple ships in this matter, it was necessary to rework the build system. As a first step, we divided the construct stuff and the logic code of the ship. In the past, we used connectors on each module to connect to other modules, in this way each module hat up to four connectors that knew the connectors of the related module. It was like a bridge for attached modules. These connections also consisted of the colliders to build new modules.
Now each module has a direct reference to all attached modules. This is a lot easier to navigate. But to build this structure we need a new way. This is now handled with a grid and if you ask now: Wasn't it a gird in the past, too? Yes, kind of but this was achieved through the modules itself. They all hat a size that fits in the grid. Now it is a lot simpler to create modules that are bigger than one grid block.
This rework lets us build new modules easier, we can provide more content and the best is, that the code is now readable.
We want to have a wider range of asteroids because there should be fields of asteroids. It takes a lot of effort to make them because we have to paint each one, cut it into parts and tell Unity how to explode when it is destroyed. So we tested a system where each asteroid is procedurally generated and we just have to make one mouse klick to be finished. The main problem was that the generation was very slow. It took about 10s to generate a 512*512px shape. There I came along with Compute Shaders. It is a technique where you run code over a GPU and because we want to render an image it is the perfect task for this. Now it takes about 35ms and therefore it is much easier to play around with different settings for the generation.
As you can see it is only the rough shape at the moment and looks a bit clunky at the moment. We will further experiment with it, but it isn't at our top priority list.
Get Starlink: uprising
Leave a comment
Log in with itch.io to leave a comment.