Technology is a key element of the game. To optimize the exploration of the galaxy, the Galablin are going to need to improve their current technology or they won’t stand a chance. Their only hope of developing new tech in short times is to find blueprints and notes during their expeditions.

During expeditions, the player is going to acquire Tech Points (probably of 3 different types, TBD) that can be used to develop technologies back at the HQ. Some technologies are too complicated for the Galablin scientists to figure out, so, in order to unlock them, the player must find the corresponding Blueprint during their expeditions.

The image above shows an example of a part of a tech tree. Tech #1 can be developed freely, the only requirements is having enough tech points. Techs #2, #3 and #6 are marked with a start and need a blueprint to unlock their development. Techs #4 and #5 need previous techs in order to be developed (#1 and #2, and #3 and #4 respectively). Tech #7 needs a blueprint AND tech #5 and #6 to be unlocked.

Blueprints and Tech Points can be obtained during expeditions by completing quests, exploring places, by looting other vessels, and more. The exact number and types of currency has not been decided yet, but they are going to be related to specific objectives. For example, destroying enemies is going to award tech points and blueprints related to military tech, while exploring unknown places will give rewards related to exploration. This means that the player can optimize their ship to look for specific rewards if they wish (more on this later in the devlog).

Technologies can be developed before departing for a new expedition.

The Black Box

As stated in the Introduction chapter (link here if you missed or don’t remember) the Galablin have developed a device to send information back to their home when the ship is destroyed. This device takes the name of Black Box (final name TBD). This Black Box has a limited space, meaning that the player must decide what of all the things they collected they want to send back.

Looking at the image above we can already see a big problem with this system. The Black Box (shown by the horizontal bar at the bottom) has a capacity of 100 and it’s full, but the player still has a lot of tech points and a couple of Blueprints still in the inventory that are going to be lost and that can become frustrating quickly for the player. Player could decide to just suicide after they reached their maximum Black Box capacity as any other rewards would just overflow and this is against the goal of the game. The two ways that I’m considering right now (not final yet) to tackle this problem are Compressing Stations and Post Stations.

Compressing Stations:

Compressing Stations are artificial stations that can be found around solar systems that can compress Tech Points and Blueprints to take way less space in the Black Box. Already compressed techs can be compressed again at another Compressing Station. This way the player is encouraged to look for one to avoid losing important techs found during the playthrough (kind of like looking for a bonfire in Dark Souls when you have a lot of souls).

Postal Stations:

Postal Stations are artificial stations that, similarly to Compressing Stations, can be found around solar systems that can send a limited amount of tech directly back home thus avoiding losing them. Same as before, player are encouraged to look for one after a while.

They work differently but the purpose is the same: avoid losing important rewards. Players are encouraged to keep playing even after reaching their maximum capacity because the overflowing tech points are not necessarily lost. The way towards one of these stations can be a high tension step in the playthrough of the player and it can also become one of the points of strength of the game.
Right now I’m more leaning more towards the Compressing Stations but maybe further in the development process I’m going to change my mind or find other ways to tackle this problem.

And this concludes this quick introduction to technology in the game.

Being Project Planets a space exploration game, gravity has an important role in the gameplay. It needs to be strong enough to actually have an impact on the ship, but not too strong that it becomes frustrating for players becoming unable to control their ship anymore. There is also the problem of balancing between strong gravity wells (stars and black holes), and weak gravity wells (planets and moons).

The first thing that I noticed is that a realistic gravity formula wouldn’t work. Using the inverse of the distance squared makes the gravity too weak at medium to long distances while becoming way too strong at shot distances. After playing with different formulas I decided for the custom curve (that is similar to an hyperbole) that can be seen in the picture below.

This curve alone wouldn’t work, it needs a few other components to do its job as intended. Each gravity well has a circle collider of a set radius. Outside the collider other objects are not affected by the gravity well’s gravity. Inside the collider objects are affected depending on the distance from the well (distance is calculated from the surface of the well, not the center). The distance is normalized between the surface of the well and the edge of the gravity range, the value obtained is then used to evaluate the previous curve (Image 1). Each gravity well has a maximum and a minimum gravity value. A curve value of 0 equals the minimum value, a curve value of 1 equals the maximum value, other values are interpolated.

Vector2 direction = transform.position - gravityObject.transform.position;


float distance = direction.magnitude - _coreSize;


float coeff = distance / _gravityRadius;


float forceMagnitude = _gravityForceBounds.x + (_gravityCurve.Evaluate(coeff) * (_gravityForceBounds.y - _gravityForceBounds.x));


gravityObject.ApplyGravity(this, direction.normalized * Mathf.Clamp(forceMagnitude, _gravityForceBounds.x, _gravityForceBounds.y));

This code excerpt shows how this is applied.
_coreSize is the radius of the gravity well (i.e. the radius of the planet).
_gravityRadius is the distance between the surface of the gravity well (i.e. the surface of the planet) and the edge of the gravity collider.
_gravityForceBounds is a Vector2 where the X value is the minimum gravity value and Y is the maximum gravity value.

This allows me the flexibility to calibrate each gravity well as I need. Normally the highest value for the gravity force is exactly at the surface of the gravity well, but by increasing the _coreSize I can create a ring around the gravity well that has the maximum value for the gravity force.
The curve can be customized as well to create different gravity wells, even with weird behaviors if needed.

Some of you may have noticed that the gravity is applied as a force, regardless of the affected object mass. This is not how gravity works in real life but this helps me achieve a behavior that it is more fun in my opinion. Lighter objects are affected more from gravity than heavier ones. This means that physical bullets are affected more than a spaceship. If a ship is in stable orbit around a planet and starts firing with a physical weapon (more on weapons later on in the devlog) bullets are going to fall towards the gravity well.

In the image above we can see in red the trajectory that the ship in orbit is following (more or less), and we can see the bullets (the orange dots) that, even if they are faster than the ship, they start falling towards the star instead of going to a bigger orbit (as it would happen in the real world).
This makes fighting against enemies when close to a gravity well trickier as gravity should be taken into consideration when aiming (unless an energy weapon is used but, again, more about this later on).

Some of you may remember that in the previous entry we discussed about a counterforce applied to the ship to limit the maximum speed that it can achieve. But the gravity code does not feature any of this. By using gravity a ship can theoretically accelerate above its maximum speed because that’s the maximum speed that its thrusters can achieve, not an hard limit per se. This also explains why the counterforce has a cap equal to the force exerted by the thrusters. If this weren’t the case we would have the absurd case where by engaging the thrusters the ship would decelerate (if the ship is currently above the max speed).
This makes navigating through strong gravity wells even more challenging for the player and can lead to fun and original areas to explore.

This concludes this initial analysis on the gravity of the game.

The first thing I worked on is the ship handling. Having the ship move exactly as I want it to it’s something of crucial importance in this kind of game.

The ship only has a thruster on its back, so the only way to change course is to rotate on itself and start burning in another direction. As there shouldn’t be any resistance in space, burning continuously can make the velocity of the ship skyrocket quickly if not kept under control.
Since upgrading the ship is going to be a key part of the game, just having more powerful engines as upgrade is not going to cut it as a ship can potentially reach any speed if it keeps accelerating. This is why I decided to put a maximum speed that the ship can reach using its thrusters that can be increased with upgrades.

But how do you cap the velocity of something that travels in space? After a few experiments I opted for adding a virtual resistance to the ship while its engines are thrusting. At first this may sound strange but this worked better than hoped, solving a few other problems on its way.

In Image1 we can see a ship that’s accelerating from zero. The red line represents the totality of the forces applied to the ship, starting from zero only force applied is the current thrust. This is when the virtual resistance starts kicking in. When the ship is thrusting with its engines, another force that is proportional to the current speed of the ship but facing the opposite way. This opposing force is calculated so that when the ship is standing still it will receive the full thrusting power from the engines, and when it reaches the theoretical maximum speed it perfectly opposes the engines’ thrust making the acceleration null.

        Vector2 force = transform.up;
        Vector2 velocity = _rigidBody.velocity;
        force *= _thrust;
        float velocityCoeff = Mathf.Clamp(velocity.magnitude / _maxSpeed, 0 , 1);
        //Add thrust
        _forcesToApply.Add(force);
        //Add counterforce
        _forcesToApply.Add(_thrust * velocityCoeff * -velocity.normalized);

In this code excerpt we can see exactly how this is all applied.

In Image2 we can see the counterforce in action. The ship has a certain speed (shown by the green line) and we can see that the red line, representing all the forces applied to the ship, is shorter than before. This is because there is a force opposing the engines’ thrust.

As you can see in Image3 the ship reached its maximum speed and, even if the engines are firing, the total forces applied to the ship equal zero as the thrusting force and the counterforce cancel out.

All this make the ship accelerate faster when it’s standing still while gradually reducing acceleration as the speed increases. But this is not the only effect of this system. The more observant of you may have noticed that with the current code, if the ships rotates 180° and starts firing in the opposite direction of the velocity to slow down, the opposing force is going to be added to the thrust of the engine as it is always opposed to the velocity, not the thrust direction. This it’s actually an indirect feature of this system. When playing games that have realistic space physics is often hard to judge when to start braking to avoid overshooting the target. The players usually want to get there as fast as possible so they start braking when it is way too late, overshooting their target and ending in frustration.
With this system the opposing force helps the ship slow down making it easier to control and harder to overshoot targets.

In Image4 we can see the resulting force of a ship burning in the opposite direction of its speed is a force so strong that the visual gizmo goes out of the camera (compare it with the one in Image1).

Someone could argue that this may make controlling the ship while turning unintuitive because the force applied to the ship does not match the direction the player is facing.

As seen in Image5 the actual force applied to the ship is not in the direction the engines are thrusting. This may seem unintuitive but the end result is actually a lot closer to the expected result than many would think. The resulting force is the sum of the thrust from engines and the opposing force. the opposing force reduces the component of the thrust that is parallel to the velocity while the component that is perpendicular is left untouched. This means that the component of the thrust that should make the ship change direction is not affected by the counterforce; it actually looks stronger as can be seen by looking at the resulting force. By looking closely we can see that the resulting force points to the right of the ship (relative to the ship’s facing), and if you think about it, if a player starts burning while facing right relative to the speed it means they want to steer the ship right. As with the reasoning we made about making it easy to brake, this actually makes steering the ship easier as the ship is going to be pushed in that direction even more. This makes reaching an alignment between ship’s facing and actual velocity faster.

This concludes the analysis of the ship’s movement. In the next entry we are going to talk about the gravity model.

Preface

Project Planets is a personal project that I’m developing in my spare time, and I decided to write a devlog about it.

The game is a roguelite about space exploration, where a race of technologically inept creatures (we are going to call them Galablin, from Galaxy and Goblin, until I find a better name) starts a space program without any consideration for basic safety. They developed an FTL drive that instantly moves the ship to almost any place in the galaxy. The only problem is that they can’t figure out how to control the destination and each time they fire it they find themselves in a different place.

Getting home this way is impossible, so they decided that each mission is going to be a one-way ticket to destruction somewhere in the galaxy, and the crews of the spaceships are ok with it (go figure…). There is just one problem with this: if the ship is not going to return home, how is that useful for the space program? The Galablin found a peculiar way to “solve” this problem. They developed a device that can send information back to their home planet from anywhere in the galaxy. There are only a couple of drawbacks: it has a limited capacity, meaning that not everything that is discovered by the crew can be sent back in one go, and it needs a huge amount of energy, so high that it overloads the ship’s reactor blowing it up almost instantly.
How do you think the Galablin “solved” this little blowing-the-ship-up problem? Well, they didn’t. Since every mission is basically a suicide mission, they decided to rig the device so that it starts transmitting when it detects the ships is on the verge of being destroyed. The ship is already blowing up, so it’s now a problem if we blow up the reactor, right?

And this is the clearly inefficient way the Galablin decided to use to explore their galaxy.