Some of the stuff we are working on
I came up with the plan for the game while reading Orson Scott Card's "Ender's Game". The idea is that you start off by controlling a single fighter space ship, and can then zoom out to control a small squadron. By continuing to zoom out, you can control larger groups of ships in an RTS style game.
I want the movement for the game to be physics based. You should be able to accelerate, decelerate, and turn based on the power of your ship thrusters and the mass of your ship. You should also be able to execute cool maneuvers using gravity such as gravity slingshots. To do this I am using Unity's force system which is attached to object rigidBodies. This allows me to add forces as vectors which makes changing velocity simpler.
With the movement system working, its time to implement gravity into the game. To do this I am using the formula for gravity in a vacuum.
The gravity manager script looks at all of the gravity affected objects in the scene and calculates the distance between them. It then
calculates the force between them using the formula:
$$F=G{m_1m_2 \over r^2}$$
Where F is the force, G is the gravitational constant, m1 is the mass of the first object, m2 is the mass of the second object, and r is the distance
between the two objects.
The next step is to apply the force to the objects, this means they accelerate relative to their masses and heavier objects have more inertia.
The movement feels kind of gross right now. The ships feel unresponsive and it's difficult to decelerate if you've been moving in one direction for too long. My initial thought on how to solve this is to change the movement so that there is a maximum speed your ship can reach but that removes the possibility of using gravity and other fun tricks to accelerate. The solution I settled on involves removing turn thrusters and setting a specific turn rate which already makes the movement feel a lot better. The next thing I added was a brake button that allows the player to quickly decelerate their ship in a fraction of the time it took to accelerate it. This allows the ship to feel more responsive and will be much more forgiving of mistakes and misinputs.
The current background is pretty boring. I think it would be cool to have a procedurally generated background and I think I can use some old code I wrote for procedurally generated objects to add stars to the background. This is a fairly perlin noise script that generates a noise map and then looks for points on the map with values higher than a certain threshold to spawn stars.
The perlin noise worked to distribute the stars but it distributed them a little too evenly. I want a more organic feeling for the background and it would make sense to have some less dense sections of stars and some more dense clusters. I am going to try using a script I wrote for terrain generation which layers multiple perlin noise maps over eachother with various strengths to achieve a much more natural clustering effect.
The noise looked kind of cool but wasn't quite the vibe I was going for. Generating thousands of stars also significantly slowed down the program and as that's not the main focus of the project, I deemed it to be unworth the hassle and have decided to shelf that portion of the game for now. In the future I may revisit that portion of the background and use shaders applied to 2D planes to cut down computing costs.
I've started experimenting with shaders recently. They are going to be useful for much more than just the background and I plan to use them for dynamically generating the planets and moons. Setting up the system for shaders has been quite a challenge and it would have been easier if I had planned to use them from the beginning. As it is now, I am trying to migrate my project from Unity's default project space into the Universal Render Pipeline to allow for the use of compute shader graphs.
I have been using Unity's built in mass system attached to object rigidBodies because it is really easy to manage and I can use the builtin force systems for my custom gravity script. Unfortunately, this mass and force system has a few major limitations. The first limitation, is that there is a limit to how massive an object is able to be. For most projects, that would be alright, but for a space game where some objects need to be orders of magnitude heavier than others it causes problems. The second problem is that there is no way to give a negative mass to the system as it wouldn't know how to handle that with the different forces.
I'm beginning to think that the solution to this problem is creating my own system to manage the mass and forces applied to each object. This is going to be quite a challenging project but I think it should be manageable. I will need to create a system that dynamically handles forces and masses to prevent me having to hard code in all of the inputs.
While I don't have any enemies to add to the game quite yet, a good starting point is making weapons for the ships. I've decided that I want to
make the weapons system modular and easy to change to allow for future changes and overhauls to the way things work. To do this, I've made a few
different weapon sizes and have made it so that the different ships have the ability to fit certain amounts of weapons.
The weapons installed on a ship are stored in an array where each weapon and the amount of time before it is able to fire again are tracked.
Using a linked array like this allows me to have a much easier time adjusting the fire rates of ships and allows me to install different types of
weapons and have them fire on a delay from one another to produce a staggered firing sequence.
Having so many projectiles generating every time the ship shoots is expensive for the computer. With a little bit of extra work, I've used a trick
called object caching from an old project to speed things up a bit. Instead of creating new projectiles every time, I create all of the projectiles
I'll need at the beginning, and then when they are no longer used, instead of destroying them I simply hide them away in their own little area to be
called when needed. This makes shooting much more efficient and slows down the computer much less.
Link to project using object caching
This new gravity solution is going to be a lot of work and require me to build a new physics system almost entirely from scratch. Requirements
for this system will be:
The first thing I built was a very quick physics handler that contains variables for velocity and mass. I then added a function to the class called
ForceAdd which takes a two dimensional vector input and then calculates the change in velocity that should be applied to the object. The reason for
the somewhat backwards name "ForceAdd" is that the method "AddForce" is already a method in Unity's physics system. I am still using a lot of Unity's
built in features so I can't simply disable the section that the physics system is in.
The next thing I added was a physics object class that inherits from the physics handler. This allows each of the physics objects to have their own
mass and velocity. Each physics object also has a bool called isGrav which determines whether or not they should be dealt with by the gravity manager.