Endless Stride
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
Endless Stride is my second solo project, my introduction to Unreal Engine, and my third game since I started making games half a year ago. Inspired by Neon White, I aimed to capture the thrill of moving fast and looking stylish while doing it.
​
With this project, I wanted to deepen my understanding of what creates feelings of impact, speed, and power within a player character. This shift in focus toward crafting satisfying movement led me to approach enemy design differently than in Thunderbound. Here, enemies act more like stage obstacles than independent characters, allowing the player to maintain momentum as they zip through levels. This approach taught me a lot about creating meaningful player conflict with more static enemy designs.
I also explored level design in depth, learning how it connects to movement, abilities, and enemy interactions. Through Endless Stride, I experimented with using level layouts to reinforce speed, teach mechanics, and balance moments of rest and intensity.
I hope this game lets you experience the dynamic movement I worked to create over the last two months!
Timeline
December 2024 - January 2025
2 months
Tools
Unreal Engine 5
​Blender
Davinci Resolve
Github
Miro
OBS
Assets
Music
"Find the Flame" - (FFXVI)
Composed by Masayoshi Soken
Arranged by Soken and Yoshitaka Suzuki
Lyrics by John Taylor.
Playtesters
Carmen Chen
Sam Judd
Noor Amin
Buike Ndefo-Dahl
Isiah Gideon
Ben Duran
Narindra Peaks
Dotun Oseni-Adegbite
Atsina Corrington
Justin Quach
Josh Hee
Design Concepts
With this project I went through a significant number of iterations on essentially every concept; therefore, I will present my design concepts through the lens of the game at various stages. I will speak on the Player, the Enemies, and the Level Design at the Ideation Phase, the Playtest Prototype, and the Final Game. Enjoy!
Player
Ideation Phase
Projectile
-
The player's projectile is their primary method of clearing enemies.
-
I considered two approaches:
-
Hitscan – An instantaneous ray that destroys enemies on hit, providing clear feedback but lacking the tactility of a moving object.
-
Physical Projectile – My initial choice, as it better suited the game's theme. Unlike hitscan, which works well for unseen fast-moving bullets, a visible projectile reinforces the feel of casting a spell and watching it travel to its target.
-
Reason for adjustment:
-
Watching spells fly across the screen was satisfying, but as the player’s speed increased, projectiles began to feel slow by comparison.
-
This created a disconnect—players expected projectiles to match their pace and felt frustrated when they had to wait for them to hit in a game centered on fast movement.
Initial projectile prototype
Teleport shards allowed the player to teleport to that shard.
The gravity shift shard allowed the player to change the direction of gravity
Shards were originally inspired by the card mechanic in Neon White.
Shards
-
Shards were enemy drops that granted abilities, inspired by Neon White’s cards (video by GMTK).
-
Early iterations explored different activation methods, including shooting the shard, storing it internally, or having a single shard that could be activated with right-click.
-
The initial version used the single-shard approach for clarity—players only needed to decide whether to activate it or not.
Reason for adjustments:
-
While the single-shard system was simple and intuitive, it became repetitive—players fell into a rigid loop of shoot, use ability, repeat, limiting creativity.
-
It also tied shard usage directly to enemy count and placement, leading to stale level design where adding more shards meant adding more enemies.
Teleport
-
The teleport allowed the player to instantaneously transport to an existing teleport shard.
-
The goal was to create an ability in which player would be able to move "even faster" than the high speed they were already moving.
-
Additionally, the teleport served as a mode to traverse a variety of level obstacles while creating skill tests when the player would teleport over a gap, requiring them to quickly find a way to the next teleport point or ground.
Teleport shards allowed the player to teleport to that shard.
The gravity shift shard allowed the player to change the direction of gravity
Gravity Shift
- The gravity shift, allowed the player to shift the games gravity.
- Much like the teleport, the gravity shift, existed as a traversal tool that I believed helped create a fantasy of existing withing a magical world.
- The gravity shift skill test existed in trying to understand where the player would land and timing your gravity shift to make sure the player could land on the next surface after shifting.
Reason for adjustments:
-
Each gem stored information on which wall the player would rotate to, but it didn’t indicate this visually.
-
This led to unexpected gravity shifts and forced players to clear teleport enemies in a specific order, restricting creativity.
Playtest Prototype
Movement Speed
-
The fantasy of this game was to feel unstoppable, but the initial sluggish movement undermined that vision.
-
Since a change in movement speed would affect everything—game feel, enemy size, projectile speed, platforming, level design, etc—it was crucial to get it right early in development.
-
Despite the complexity that came with tuning this parameter, refining movement speed was essential to aligning the game with its intended fantasy.
Increasing player movement speed required a dramatic increase in platform size to accommodate.
The dash allowed for increased air mobility helping players reach platforms just out of reach.
Dash
- The dash provides a burst of speed on the ground and enhances aerial mobility, helping players reach slightly out-of-reach destinations.
- The dash also grants i-frames, allowing players to pass time-based skill tests.
Reason for adjustments:
-
While the dash provided strong lateral movement, players were often confused when air dashing still carried the initial vertical momentum.
-
To improve both horizontal and vertical control, dashing was made to nullify vertical momentum, allowing players to transition smoothly from rising or falling into forward movement.
Final Version
Ability Usage
-
The shard system was removed and replaced with a system in which abilities could be activated at any point as long as a condition was met.
-
Teleport can be activated by right clicking on a teleport sigil.
-
Gravity Shift can be activated by right clicking at any surface runnable surface.
-
Shifting between these abilities could be done using Q and E.
-
-
This change allows the player to have more agency on when and how they wanted to use their abilities.
-
Having the teleport be tied to a sigil rather than an enemy allowed for there to exist many opportunities to teleport, but did not create a necessity to teleport to complete the game.
-
This disconnected gravity shifting from the necessity of having an enemy to give a shard.
-
Allowing abilities to be used without shard constraints greatly increased the space for player creativity and expression.
Hitscan allowed for a much tighter connection between player input and on screen action.
Hitscan
-
The player projectile was changed to hitscan for a faster feel relative to the player while avoiding physics issues from high-speed projectile movement.
Player Movement
-
Player acceleration was made near-instantaneous, jump height was significantly increased, and gravity was strengthened to enhance snappy, responsive movement at high speeds.
-
During playtesting, the juxtaposition between fast horizontal movement and sluggish vertical movement felt jarring. Originally, low jump height was intended to guide players toward abilities and level features like trampolines, but it felt at odds with the player fantasy.
-
To address this, I increased jump height while also raising object heights, maintaining intended level design while making movement feel more natural.
-
Stronger gravity improved pacing by reducing air time after large vertical movements, enhancing both flow and realism—with a weight inspired by games such as Ghostrunner. (Video by Infusco).
-
Increased acceleration, jump height, and gravity gave the player a greater sense of direct control over their actions.
These changes in movement created a more weighty character giving a greater sense of realism, reminiscent of Ghostrunner.
Speed lines and camera shake helped sell the feeling of speed and impact when hitting the ground.
The FOV extension during teleport gives the player a sense of bending reality without lasting so long that it slows down the games momentum.
The boost after completing a gravity shift helps the player maintain a sense of speed after the shift has completed.
Juice
-
Camera FX were added to create a sense of reality and impact as well as sell the sense of magic while using abilities:
-
Camera animations were added for idle, run, jump, land, heavy land, and falling quickly.
-
Speed lines were added to the dash and when falling quickly.
-
FOV was extended on ability activation.
-
A sigil appears on ability activation.
-
A boost is given to the player after completing a gravity shift.
​
-
-
Camera shake was particularly tricky due to the scoping decision of not including a hand mesh, which normally conveys motion without disrupting the reticle. Without it, I had to move the reticle at times, so enemy sizes were increased to compensate for potential aiming difficulties.
Enemies
Idiation Phase
Enemies As Obstacles
-
My enemy design philosophy centered on two roles:
-
Targets for aiming-based skill tests.
-
Obstacles that create decision-making and timing challenges in movement.
-
-
Dying should result from a misstep in movement, not an inability to dodge projectiles. To achieve this, enemy projectiles feel as if they are aiming where the player used to be, maintaining a sense of threat without unfair difficulty.
-
This approach was inspired by Star Wars’ Stormtroopers—where the player, like a Jedi, feels untouchable while effortlessly dodging attacks.
This game looked to present enemies as immobile level obstacles rather than intelligent actors in order to give the player a sense of power.
Final Version
(no significant enemy changes in playtest prototype)
This enemy requires the player to quickly decide on a safe location and to follow up with executing on moving to that location.
Wall Enemy
-
This enemy spawns n hitboxes on surrounding walls, always including the one the player is on. After a charge period, the player dies if they remain on a marked wall.
- This mechanic created a necessity for the player to quickly make a decision based on in game indicators while not compromising forward momentum.
Teleport Sigil
-
The teleport enemy was replaced with a game feature, allowing teleportation as an option rather than a necessity for level completion.
In order to remove the requirement of having the player reach every teleport point, the teleport enemy was turned into a level feature.
Exploding enemies are marked with floating orbs.
Exploding enemies are capable of inflicting damage on both the player as we as other enemies.
Exploding Enemies
-
Enemies with swirling orbs explode on defeat, damaging anything nearby. This adds a level of decision-making when facing enemy clusters in which a certain enemy may explode.
-
If a teleport sigil is marked to explode, the player can still teleport to it, but the explosion will trigger. To survive, they must time a dash through the blast using i-frames, creating a skill-based timing test.
-
Originally, all teleport sigils required dashing post-teleport, but this felt like a chore, punishing successful aiming to a teleport point.
-
Instead, making explosions a general enemy trait increased enemy variety while maintaining engaging decision-making.
-
Fire Wall
-
The fire wall served as an early-game tutorial, teaching players to use dash i-frames to pass through the wall.
-
Previously, players struggled with the timing test of the exploding teleport sigil due to a lack of prior i-frame introduction. The fire wall ensured they learned this mechanic in a controlled setting.
-
This design was inspired by Super Mario Bros. 1-1, where increasing pipe heights teach players to hold the jump button for more height (video by Extra History).
The fire wall acted as a tutorial for player i-frames.
The inspiration for using a level obstacle as a tutrial was inspired by Super Level 1-1
Level Design
Ideation
Tempo
-
The idea of tempo was introduced to me my an amazing talk by Ghostrunner Level designer Marcin Kluzek.
-
When creating a high pace game that requires intense focus and execution by the player it is important to balance this with moments of rest in order to allow the player to recover between sections.
-
My goal to create this was through the wall running mechanic and the trampoline.
-
Neither of these offer incredible skill tests and can often take time between beginning a jump or wall run and reaching the destination.
-
This time can act as a moment of slowing down the tempo of the game before asking the player to pick the pace up again at the next section.
-
Reason for adjustments:
-
The wall run was eventually removed due to its redundancy with being able to run on the wall.
-
However, moments of rest still exist after trampoline usage and for longer stretches of platform after a gravity shift.
Wall jumping and trampolines existed to give the player down time between level sections
The concept of rest remained even when movement speed was greatly increased.
Playtest Prototype
Enemy Counter Wall
-
The enemy counter wall sectioned off a level into individual pieces where all enemies in a section needed to be cleared before the player could pass the wall.
Reason for adjustments:
-
The wall was removed and replaced with a counter of total enemies left within the player UI. In order to clear a level this counter needed to reach 0.
-
This largely came from the fact that the walls created a much smaller experience for the player where the goal of clearing a section became the primary goal rather than trying to reach the end of the level.
-
This change created an incentive to have a clean run across the entire level rather than clearing individual sections.
The enemy counter wall created a hard requirement that the player clear all enemies in a section before moving on to the next section.
Final Version
Creating a feeling of speed
-
To signal speed, columns and spikes on bridges served as visual markers for the player. Columns were more effective, but due to their high graphical cost, they were replaced with spikes as a less resource-intensive alternative.
Small spikes along the bridges gives the player a stationary object to use as relative context for speed.
Columns even further sold this feeling of speed as the player launches themself into the beginning of the level
Concepts such as the exploding enemy were first introduced in a simple context before being reintroduced in a more complex scenario.
Ramping Up & Teaching the player
-
Levels were designed to introduce abilities and enemies in straightforward scenarios before adding complexity.
-
New mechanics were first presented in isolation—like a single exploding enemy—followed by more challenging scenarios, such as multiple clusters with varied enemy placements.
-
Teaching elements, like the fire wall, introduced specific concepts (e.g., dash i-frames), which were then built upon with features like the exploding teleport sigil.
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.
Ghostrunner
Video by: IGN
Shady Knight
Video by: GameTrailers
Boomerang X
Video by: Nintendo of America
Mirrors Edge
Video by: jackfrags
​
​
Neon White
Video by: GMTK
​
Katana Zero
Video by: Nintendo of America
TitanFall 2
Video by: Titanfall Official
My Takeaways
-
When creating quick movement it is necessary to include some method to have the player maintain a sense of control, especially when needing to move in the air. This manifests through either a time slow down mechanic or a floaty feeling jump (GR, BX, NW, KZ).
-
When moving in first person it can be difficult to have an understand of when a is directly underneath you, so creating platforms that are large enough to be seen even when not directly looking at them becomes crucial (GR, NW, ME).
-
Speed is often felt through juice, and not purely based on how quickly the player character is actually moving (GR, NW, TF2).
-
Level design can exist such that part of the challenge can be figuring out where enemies are and how to get to them, but can also exist in a manner where enemy location is obvious but the challenge comes from understanding how to get to them or clear them. (GR, NW, TF2).
-
Enemies do not need to constantly be a threat, and can act purely as an object for the player to clear (NW).
-
Movement and impact is portrayed through movement of the camera AND the mesh, with further additions being VFX and sound (SK, KZ, TF2).
-
Having speed to clear a level be a choice and not a hard lock is an incredibly effective mode of creating replayability to a game (GR, NW, KZ, ME).
-
Melee combat introduces a challenge to the player of getting to an enemy that often not as prevalent in ranged based combat (GR, SK, KZ).
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.
-
Level design as a vehicle for structure
A key goal for this game was to make level design integral to its satisfying feel, something lacking in my previous projects. After finalizing movement and abilities, I created a sandbox for each ability, designing 10 distinct scenarios that embodied the player fantasy while varying difficulty. This resulted in 30-40 level pieces, which I then assembled based on the concepts I wanted to introduce and their difficulty.
This piecewise approach allowed me to deeply explore level design while ensuring each section complemented the game’s fantasy and challenge. Through this process, I also learned valuable lessons about enemy tuning, the impact of visuals on game feel, structuring levels for clarity, balancing intensity, and guiding players naturally through the game.
-
Go too far, then reel it in
While tuning parameters like movement speed, projectile speed, and jump height, I often spent more time than expected trying to find the optimal values. Initially, I would start low and incrementally adjust, but this led to a space where values didn’t feel wrong—just different—making it difficult to determine the best choice.
To improve this process, I began setting both a too low and a too high boundary first, creating a defined range to work within. This approach sped up iteration and ensured I wasn’t limiting myself by never pushing values far enough.
-
Working around limitations (both financially and graphically)
Scope has always been crucial to finishing projects on time, but this game introduced new challenges—specifically, hardware limitations and budget constraints.
Working in Unreal on a laptop quickly revealed my hardware limitations. For example, the fanning bridge sequence was originally meant to feature multiple high-density bridges, but moving them in-game was incredibly taxing. Financially, 3D assets proved far more expensive than 2D ones, forcing me to work within a strict budget.
While cutting or altering features due to these limitations wasn’t ideal, it was a valuable lesson in realistic game development. Learning to adapt and optimize within constraints ultimately made the project stronger.