Thunderbound
If you would like to read more about the game design process, please scroll down to the "design concepts" section (or use the navigation in the bottom left)
Role
Solo Developer
About
As my first project, Thunderbound was an opportunity for me to dive into game development with a blank canvas. Inspired by my love for games like Hollow Knight and Ori and the Will of the Wisps, I chose to create a 2D platformer using Unity as the base for both my first game and my first experience with a game engine. My goal was to create a compelling vertical slice of a ranged-based combat game where I could learn the fundamentals of engaging player movement and enemy AI.
​
Throughout development, I established a framework for how I want to approach future games. I solidified the importance of player feedback, iteration, and knowing when to let go of an idea. Thunderbound helped me create a game that feels structurally sound and taught me that I truly enjoy the process of ideation, iteration, and refinement. With this first game complete, I’m excited to take what I’ve learned into my next project in Unreal!
Timeline
July 2024 - Sept 2024
3 months
Tools
Unity
Adobe Photoshop
Davinci Resolve
Github
Miro
OBS
Assets
Music
Apotheosis by Austin Wintory (Journey)
Escaping a Foul Presence by Gareth Coker (Ori and the Will of the Wisps)
Playtesters
Carmen Chen
Noor Amin
Mannah Kallon
Buike Ndefo-Dahl
Stephen Oyarijivbie
Ben Duran
Design Concepts
Here I will talk about the my design ideas through the lens of the player, the enemies, and the game's internal mechanics. In each section I will highlight how my design concepts evolved from the prototype, to the first version of the game, all the way through the final version. If you would like to get a more in depth understanding of my ideas please check out my devlog!
Player
Prototype
Teleport Arrow
-
The teleport arrow allowed the player to shoot an arrow that stayed on screen and teleport to it on command. It was designed around the core challenge of a ranged character: staying at an optimal range where they can hit enemies but remain out of danger.
Reason for removal:
-
The teleport was inspired by zoners in fighting games like Testament (GGST), where setplay creates mixup opportunities. (video by GGST: High Level Gameplay)
-
In PvE, enemies don’t adapt to mixups, making the setup feel unnecessary.
​ -
For teleport to be useful, multiple conditions had to be met, leading to limited practical use and its subsequent removal:
-
The enemy had to be in range.
-
The arrow had to be on screen.
-
The arrow couldn’t be blocked.
-
Initial teleport arrow prototype
Teleporting to a set point was inspired by zoners in fighting games like Guilty Gears' Testament
Initially, empowered arrows were obtained after teleporting and did increased damage as well as well as broke shields
Empowered Arrow
-
The empowered arrow was an upgrade gained after teleporting, dealing increased damage and breaking armor.
-
This mechanic incentivized teleporting by offering:
-
A reward—higher damage.
-
A necessity—breaking armored enemies.
​
-
-
These incentives encouraged players to use teleportation as a movement tool rather than just running around.
Reason for adjustments:
-
Linking the empowered arrow to teleportation forced players to teleport just to attack armored enemies.
-
This made teleport feel like a mandatory step rather than a strategic movement option.
​
Dash
-
The dash was a reactive defensive mechanic, offering a quick escape when needed, unlike teleport, which required setup.
Reason for removal:
-
Though the dash filled the reactive defensive mechanic well, having two movement options, the teleport and the dash, felt redundant.
-
I wanted to have a reactive defense mechanic that did not have the overlapping movement option property that was present in the dash.
-
A more complete analysis on the relationship between defensive and reactive mechanics can be found on my devlog!
Prototype ground dash
Prototype air dash
Version 1.0
Shield
-
The shield replaced the dash, granting temporary invulnerability as a reactive defense.
-
The shield provided a non-movement option for reacting to an attack
-
To prevent overuse, the shield was limited to 3 charges with no way to replenish them. This ensured the shield remained a backup option rather than the dominant defensive tool over teleportation.
Reason for removal:
-
The shield itself had no issues, but instantaneous teleport emerged as a reactive defense, making the shield feel redundant.
-
This shift led to the removal of the shield, despite it being a strong solution for a non-movement-based defense.
The shield was used as a reactive defense mechanic, blocking enemy damage for a short time
Final Version
Instant Teleport
-
To expand teleport's usability, I made it instantaneous, allowing the player to teleport a fixed distance in any direction on button press.
-
The instantaneous teleport provided a reliable movement option without the setup constraints of the teleport arrow.
​ -
In order to encourage fast, skillful enemy clears while giving an option for skill expression, I introduced a teleport reset:
-
Normally, players can teleport once in the air to prevent excessive movement.
-
However, hitting an enemy in the air resets teleport, inspired by DMC5 mid-air resets (video by Cheeb).
-
Teleport was finalized as instantaneous movement a set distance in a chosen direction
Mid-air teleport can be reset by inflicting damage on an enemy
Mid-air resets inspired by games like Devil May Cry 5
Empowered arrow set to be triggered on attack button hold.
Updated Empowered Arrow
-
To remove the frustration of teleporting to access the empowered arrow, I made it charge-based instead.
-
Holding the fire button longer now grants an empowered arrow, thematically matching the idea of pulling back a bow for a stronger shot.
​ -
This change introduced multiple playstyles for clearing levels:
-
Empowered arrows: Slower, stronger shots for precise eliminations.
-
Normal arrows: Faster, weaker shots for overwhelming enemies with rapid fire.
-
Enemies
Prototype
Slime
-
The slime jumps toward the player on a fixed time scale, presenting two challenges:
-
The slime threatens both ground and air, though with limited range.
-
Aiming while the slime jumps is difficult, encouraging players to time their shots between jumps for better accuracy.
-
Reason for adjustment:
-
The slime lacked challenge due to its slow movement speed.
-
Players could often eliminate it before it got in range to attack.
-
Even if it got close, escaping was too easy, making it a minimal threat.
Enemy slime prototype
Armor on slime prototype could be broken with empowered arrow
Armored Slime
- The armored slime could only take damage after being hit with an empowered arrow to break the armor.
- The initial reason for this mechanic was to incentivize teleportation. Given in this version the empowered arrow was locked behind teleporting, this gave the player a reason to teleport.
Reason for adjustments:
-
Future versions of this enemy was expanded to be used on all enemy types
Version 1.0
Slime Updated
-
When in range, slimes now dash at the player mid-jump, then pause at the apex before accelerating downward.
-
This makes the slime a genuine threat, as its speed allows it to reach the player.
-
The pause at the apex gives players time to react and was inspired by The Skull-Crusher in Hades (video by Rajas221).
Updated slime movement included an acceleration towards the player followed by a ground pound.
Updated slime movement inspired by enemies such as the Skull- Crusher in Hades.
The wasp dashes at the player from the air after a short delay.
The was could capture the teleport arrow and needed to be defeated before the player could teleport again.
Wasp
-
The wasp dashes at the player from the air but will target and capture a nearby teleport arrow instead.
-
If the wasp captures the arrow, it flees, and the player loses teleport ability until the wasp is eliminated.
​ -
The wasp serves two key purposes:
-
Creates an aerial threat for the player.
-
Adds decision-making in enemy prioritization and teleport arrow placement.
-
Reason for adjustment:
-
The wasp's capture ability was removed when the teleport arrow was removed.
-
While I enjoyed this mechanic, the new teleport system created a more compelling game. Keeping the teleport arrow just for the capture mechanic wasn’t worth compromising the overall design.
Shade
-
The shade fires projectiles at the player from any range with line of sight and teleports away if the player gets too close.
-
This mirrors the player’s own playstyle, as the shade also seeks to keep its distance.
-
The conflict forces the player to dodge projectiles while struggling to close the gap.
Reason for adjustment:
-
The shade’s primary conflict was forcing the player to attack from range, which lacked meaningful challenge in a ranged combat game.
-
My first solution was to place the shade on platforms where the player had to wall jump or teleport to attack, shifting the conflict from distance to angle.
​ -
However, this created two major issues:
-
Stage design became too restrictive, as every level had to prevent the player from simply shooting the Shade from the ground.
-
The conflict remained weak, as the Shade still fundamentally required ranged attacks, offering little challenge.
-
The shade fires projectiles from a distance and would teleport away if the player got too close
To create conflict, the shade was put on platforms that required creative movement to hit.
Armor was made modular so that it could be applied to any enemy.
Armor cannot be broken with normal arrows and requires empowered arrows to break.
Armored Enemies
-
The armored enemy must be hit with an empowered arrow to break its armor.
-
Initially, I planned a specific armored enemy, but existing enemies already filled that niche. Instead, I made armor a modular addition, allowing it to be applied to any enemy type.
-
The armored enemy creates new variations of existing enemies, forcing the player to adapt while also reinforcing the use of the empowered arrow.
Final Version
Updated Shade
-
The shade now teleports between multiple points on a set timer while firing projectiles if the player is in line of sight.
-
A glowing orb indicates the shade’s next teleport location.
-
This shifts the conflict of the shade to timing and prediction:
-
Standing on an orb puts the player in danger upon teleport.
-
Mis-timing a teleport can lead to a missed shot.
-
Predicting the teleport allows the player to prepare a shot in advance, creating a satisfying moment of foresight and skill.
-
The final shade teleports on a set timer that is indicated by an orb popping at its next location.
Game Mechanics
Version 1 (no game specific mechanics existed in the prototype)
Point System
*(color was not correctly set while prototyping this system)
-
The point system rewarded precision and speed:
-
+1 point for hitting an enemy with a normal arrow.
-
-1 point for missing a shot or taking damage.
-
A countdown timer reset on each successful hit.
-
Empowered shots granted 3 points plus bonus points based on remaining timer time.
​
-
-
Inspired by DMC and Bayonetta (video by donguri990), this system:
-
Incentivized fast, successive enemy clears for higher scores.
-
Rewarded accuracy while punishing mistakes like missed shots or damage taken.
-
Reason for adjustment:
-
The point system had several issues:
-
Over-incentivized empowered arrows, as normal arrows lacked bonus points.
-
Balancing point values between consecutive normal shots and a 3x empowered shot became overly complex.
-
It was unclear to the player why they gained or lost certain points.
-
The emphasis on empowered arrows and penalty for missing discouraged a fast, free-flowing playstyle, making the system feel restrictive and confusing.
-
An early point system for removing enemies quickly
The point system was inspired by style systems present in games like Bayonetta
Final Version
Timer System
-
The timer system deducts 10 seconds from a countdown timer when the player takes damage.
-
Milliseconds were added to create a greater sense of urgency and provide an extra unit of improvement for high-level players.
-
This system encourages speed and avoiding damage while remaining simple and intuitive.
-
Unlike the previous point system, it does not restrict playstyles, allowing for more player freedom.
The final timer system caused the player to lose time when taking damage.
Inspiration/References
Here I will talk a bit about the games that I referenced, studied, and was inspired by in making this game. I will highlight the mechanics and themes I took from these games as well as what it is that I personally took away from them. In order to get more information about what I learned from these games please check out my devlog here!
Monster Hunter
World
Video by: Arekkz Gaming
Zelda Breath of the Wild
Video by: Tomsen21
Ori and the Will of the Wisps
Video by: D A
Titan Souls
​
Video by: Playstation
Towerfall Ascension
Video by: Playstation
Apotheon
​
Video by: CorePixels
Hades
​
Video by: Shagg x83
My Takeaways
-
Arrows don’t need to follow a parabola, straight shots allow for intuitive aiming without compensating for arc (MHW, BOTW).
-
Limited arrows add conflict, forcing players to manage ammo and positioning, but can slow combat unless paired with a melee fallback (Apotheon, BOTW).
-
Finite arrows emphasize accuracy over speed, leading to deliberate gameplay at the cost of fluid movement (Apotheon, BOTW).
-
No reticle increases skill expression but can make aiming feel like guesswork if misaligned with player intent (Titan Souls).
-
Bullet time and slow falling help players aim mid-air (Ori, BOTW).
-
Point-blank shots did not exist, short presses either cancel or shoot with a minimum distance, but no short press resulted in a shot falling directly in front of the player (most games).
-
Soft lock balances quick movement with aiming (Hades, Ori).
-
Simple arrows work, a hitbox moving in a straight line is enough (TowerFall Ascension).
-
Holding an arrow longer doesn’t always increase power, it can simply allow time to aim (BOTW).
-
Dash dancing with a bow is fluid and fun (MHW) (read more here).
-
High-speed movement conflicts with precise aiming, as overly sensitive controls make shooting accurately difficult (Apotheon).
What I Learned
Given this was my first game there was a lot I learned about the process of making a game that I find interesting. I want to tie together a few of those thoughts and leanings here.
-
Game mechanics without a player fantasy creates a disjointed game.
When I started, I wanted to explore teleport arrow interactions. After Version 1.0, I realized the mechanics worked individually but lacked a cohesive identity. I refocused on making the player feel untouchable, reworking mechanics to fit this fantasy. Instant teleport enabled quick evasion, teleport resets allowed skilled traversal, and milliseconds on the timer reinforced fluid movement. These changes unified the experience, giving every mechanic clear purpose.
-
Letting go of hard work is painful, but can create a better game.
One of the hardest parts was realizing the teleport arrow, the game's core mechanic, wasn’t working. Despite countless tweaks, playtests showed it was fundamentally flawed. Letting it go was tough, but I knew I couldn’t be proud of the game if I forced it to fit. In hindsight, it was the right call. The game is better for it, and the process taught me why some mechanics simply don’t work.
-
A game will never feel done, so scope must be everything.
To keep development manageable, I limited scope, no power-ups or multiple levels. But as I progressed, I kept imagining ways to expand progression. My to-do list grew, but playtests showed core mechanics needed refinement. I had a choice: ignore feedback, extend the deadline, or cut features. Since feedback and time were non-negotiable, I trimmed the list. The game may lack some ideas, but finishing it mattered more than endless expansion.
-
Sharing an incomplete product is worth momentary embarrassment.​
Ideally, players would only see the game at 100% completion. But as the creator, I knew what felt fun to me might not work for others. Sharing an incomplete game was daunting, but feedback on visuals, interactions, and fun factor was invaluable. It was tough to hear, but it shaped the game and will guide future projects. I’m deeply grateful to everyone who playtested, this game wouldn’t exist without them!