Portfolio About me Contact

Thrust Factor

Release date:
Dec 7 2024 (alpha), June 6 2025 itch.io release

Development time:
6 months part-time

Project type:
Solo, study-turned-passion project

Description

Thrust Factor is a tight, punishing, movement based space shooter roguelite, loosely based on the classic arcade game Asteroids. The player avoids lasers, missiles and space rocks while battling bosses and gathering upgrade modules to improve their ship.

Design Goal

I wanted to modernize the retro game Asteroids. Apart from sound and graphics, I set out to improve on four main aspects:
  • Modernized Player Character and game feel
  • Faster-paced and more active gameplay
  • More engaging enemy AI
  • Deeper progression and better replayability

I described the core player experience as high-risk, high-reward "glass cannon", demanding precision and rewarding mastery.
An early concept sketch, outlining movement, enemy behaviour and health systems.

Player Character(3C's)

Initial Design

One of the first things I did was establish the Player Character, the first step in anchoring the core player experience.

I wanted players to feel like they are piloting a fighter jet, with more deliberate strafing runs as opposed to obvious twin stick shooter movement. I also wanted to reward positioning (e.g. trying to get on an enemies tail, tactically retreating) and to have the player feel like a glass cannon: powerful but vulnerable.
First iteration of the Player Character. Note the smoothing effect, which prevents instant 180 degree turns. Boosting significantly slows down turning.

Base Setup

  • The player looks and shoots in the direction of flight and is pointed towards the danger, similar to a fighter jet. This means players have to actually commit to an attack.
  • The mouse controls rotation, allowing for precise and responsive aiming. A turn speed cap prevents instant 180s.
  • Boosting allows the player to reposition quickly, but also lowers turn speed, leaving them more vulnerable. Risk/reward.
I performed a general playtest using this setup with a basic enemy and some asteroids.

Iteration 1

⇒ Players thought the movement was disorienting.

Why? No bearing, movement with cam follow is relative, so players had no idea how fast they were going.

Solution: Adding a parallax background. This gave players a sense of speed and direction, and immediately made a huge difference in terms of character feel.
The parallax background consists of two layers: dust particles in the background (slow, 0.25x–1x speed) and clouds in the foreground (fast, 1.25x speed).
When boosting with the camera lookahead system active, the camera shifts forward in the direction of movement quite dramatically.

Iteration 2

⇒ Players didn’t boost, resulting in sluggish gameplay.

Why? Playtesters couldn’t really answer this, so I had to ask followup questions to dig deeper. It turns out that boosting got punished, because players could not see what was ahead, and as such were scared to boost.

Solution: Implementing a camera lookahead system, giving players more control over what they can see. This turned boosting into a well-integrated and enjoyable part of the Player Character.

Character Feel

A number of feedback systems work together to reinforce the feeling of speed and vulnerability:
  • Boosting triggers screen shake, speed lines, extended thruster particles, and a sustained rocket sound effect, really selling the velocity.
  • Getting hit triggers screen shake and outline flash.
  • Screen shake is reinforced through controller vibration, making feedback tactile.
Other improvements I made were the high contrast cursor sprite,
Final result, including all game feel systems. Obviously a video doesn't do the Player Character justice, try it out yourself on the itch.io page!
I'm glad I deliberately chose not to use a twin stick shooter setup, which would have been the more obvious choice. Though the current control scheme feels unusual at first, it sets the game apart from other titles and, according to playtesters, has a satisfyingly high skill ceiling, which is exactly what I was aiming for.

Playtesting really helped me iron out the Player Characters rough edges, turning it from an 'OK' proof of concept into a unique and satisfying base for the rest of the game.

Combat Design

Active Play

After adding basic asteroid enemies, I noticed a problem: just like in classic Asteroids, instead of moving, players would rather remain stationary, practically turning the game into a turret sim.

Instead of bloating the game with new, unnecessary mechanics, I decided to work with the tools I had and created enemy AI that encourages a more active playstyle.

Each enemy, as well as the asteroids, plays a specific role in getting the player moving.
The enemy variety matrix I used to quickly concept new content.
Asteroids have a high probability of spawning with a force towards the player.
The Lancier locks onto the player, and if the lock isn't broken, fires a tracking missile which takes effort and skill to dodge.
The Firefly, the most basic enemy, fires lasers that can't be shot down. They have to be dodged.
Drones fire laserbeams across the player's vision, who has to choose to either evade, or fly towards the drone to destroy it.

Dynamic Difficulty

Enemies and asteroids drop upgrade blips when killed, which fill a meter that can be exchanged for ship upgrades. These are the primary way to prepare for the boss, which arrives on a 3-minute timer.

Killing enemies faster fills the upgrade meter quicker, but also raises the max enemy count through a hidden combat score system. This system is self-balancing: A skilled player upgrades faster but faces more enemies at a time. A weaker player faces less pressure but arrives at the boss less prepared.
Example scenario with the hidden combat scores of two players. At point A the skilled player already faces 4 enemies to the beginner's 3. By point B the skilled player has hit the cap of 7, while the beginner faces 5 enemies.
The player gets hit continuously. Bottom left: Shield, bottom right: Health.

Less is More

Instead of health being a continuous scale, and damage being some arbitrary value, I opted for a tighter system with lower numbers: the player has 3 health points, and all hits deal 1 damage.

This system rewards precision, punishes carelessness, and is much easier to communicate!

No World Borders

My goal was to create a map without obtrusive boundries. Inspired by the "Blue Sphere" levels of Sonic Mania, I implemented a loop-around system. If an object is too far out of view, it loops back to the other side.

By fine tuning the map size, I was able to give players just the right amount of room to retreat, without being able to flee the action entirely.

This system is so seamless, not a single playtester ever noticed!
An in-engine view of the game's viewport.

Progression

A flowchart showing the game broken down into separate loops, and how they relate to each other. Note the addition of the meta-loop (yellow).

Loops and Progression

There are three important gameplay loops at play. The addition of a meta loop, acquiring permanent unlocks, was necessary to give players concrete and measurable goals to work towards in between runs.

I often break down gameplay systems like this, to make sure there are no holes in the design and to keep it consistent.

Difficulty vs Progression

The design pillars I established early on dictate Thrust Factor should be difficult and skill-based. The addition of permanent upgrades would clash with that idea. That's why unlocks do not simply make the player stronger:

Instead, they unlock new abilities, such as flares (defense against missiles), and their respective upgrade tree. It adds a layer of complexity and choice to the game.
1: The player buys the "Countermeasures" unlock in the menu. 2: The player chooses to upgrade it with "Auto Deploy". 3: The upgraded unlock in action.

Post Mortem

Turning Asteroids into Thrust Factor was incredibly fun and rewarding. The project taught me a lot about systems design, in particular the interaction between different game loops.

I didn't expect that the biggest challenge would be to get players to move around more. Some players still preferred to play more passively, which frustrated me at first. But I realized that the game supporting multiple viable playstyles is actually a good thing, and trying to force every player into a specific playstyle is counterproductive.

I haven't touched upon sound design and music, which I've put as least an equal amount of effort into designing and fine tuning as the rest, and I could dedicate another entire page to. You can listen to the soundtrack through the music player on this page, or on Soundcloud.