top of page
Aaron Petrek
Game Developer

Project Specifications

  • 2023 Jam (10 days)

  • Developed in UE5 5.1 (Blueprints)

  • Shooter on rails

Project Goals

  • Practice rapid prototyping gameplay mechanics

  • Collaborate with another developer

Team project submission for the 2023 Game Jam. The theme for the game jam was “Life in 2 Dimensions”. To address the theme, our team built a shooter on rails game that transports the shooter on rails ship from a 2D arcade screen to 3D. I served as a developer for this project.

My contributions included:
  • Shooter on rails movement

  • Enemy AI

  • Rail build Tool


Game Summary

In the back of a local bowling alley sits a dusty arcade room. Only one of the machines still works.

Even though no one has been seen playing the arcade machine in ages, the room’s lights are always left on and the machine runs perpetually.

After bowling for a few hours with your friends, you decide to poke your head into the arcade to check things out.


Bit Ridge Blitz is a shooter on rails. The player starts in an arcade with only one working machine, where he is able to play a 2D shooter on rails game. After a short time, the game begins to malfunction as the player appears to get sucked into the machine. The player then finds himself in a high-fidelity 3D version of the same game he had been playing.

Ship on Rails

The player-controlled vehicle rides down a track created from a spline. The player input then controls the offset of the player ship from the center of the track. I identified the majority of the behavior would be the same for the 2D and 3D ships. Therefore I created a base class that the 2D and 3D ships could be derived from. This base class handles all of the ship movement. By adjusting the class member variable in the derived Actors Blueprints for the 2D and 3D ships, our team's game designer could get the intended behavior and player control feel for both ships. 


Bit Ridge Blitz was developed entirely using Unreal Engines Blueprint visual scripting. The development of this project was great practice for rapid prototyping game play mechanics that were not my own idea.

For this project my main contributions were the player controls and ship movement, Enemy AI, and level streaming transitions.

3D ship
2D ship

Rail System Build Tool

The rail system for the 3D map is constructed from a spline and various Instanced Static Meshes. The spline is treated as the center of the rail and the Instanced Static Meshes make up the walls and ground that create the canyon the ship flies through. The position and random transform offsets of the Instanced Static Meshes are calculated and set automatically in the Rail's Actor Construction Script. This allowed our designer to easily configure and test different track designs. By simply adding and adjusting points on the spline, the canyon walls were automatically placed around it.

Enemy AI

The enemies are spawned behind the player on the rail system. They then move in front of the player to engage in combat. The number of enemies that can be present in the map changes as the player progresses along the rail, the farther the player gets the more enemies they will encounter at once, therefore increasing the difficulty. The enemies are derived from the same ship class as the player, they also ride along the same rail system. The input to the enemy ships is directly provided by their AI controller. The enemy AI will go through two states: engage player, and combat.

Engage Player State

When the enemy ships initially spawn they will be behind the player and start in the engage player state. While in this state the enemy ship will travel much faster than the player. Once the enemy has traveled a set distance along the rail in front of the player, it will slow to match the player speed. When the speed is reached, the enemy ship will enter the combat state.

Combat State

While in the combat state, the enemy will check and update its offset position on the rail, adjust its speed, and fire at the player. The enemy will remain in the combat state until it is destroyed.

Offset Position On Rail

While in combat the enemy will continue to maneuver by adjusting its yoke input which will change the ship's relative position from the rail center. If the enemy relative location from the center rail reaches the max distance, a new input vector will be calculated and applied to maneuver the enemy away from the maximum relative offset it has reached. The enemy will only apply the same input vector a set amount of time. Once this time is exceeded a new input vector is applied. This is done regardless of the enemy ship's relative position to the rail.

Adjust Speed

Unlike the player ship, the enemy ships can adjust their speed to get closer and farther away from the player. Enemies will stay within a minimum and maximin range in front of the player. When the distance between the player and the enemy is less than the minimum distance, the enemy will lerp to a new random speed that is greater than the player's speed. Then when the distance between the player and the enemy is greater than the max distance, the enemy will lerp to a new random speed that is less than the player’s speed.

Fire At Player

The enemy will fire in bursts at the player at random intervals. The enemy shot location is determined by selecting a random point in a bounding box in front of the player's ship. As the player progresses farther down the rail this bounding box shrinks, increasing the accuracy of the enemy AI shots, and therefore increases the difficulty for the player to avoid being shot by the enemies.

For this game jam there were a total of 984 entries. Unfortunately the results did not go in our favor. In player's reviews there was a consistent issue with the enemy AI being too accurate. This was unfortunate because the enemy AI system I designed and programmed allowed for the enemy accuracy to change dynamically. If given more time and having others play test the game this issue could have easily been corrected. I feel the game as a whole suffered from this issue.


Project Reflection

This was an ambitious project. The most significant lesson I learned from this project was the importance of play testing with a wide range of individuals. Most of the reviews for the game were simply that it was too hard and the enemy aim accuracy was too high. This could have easily been adjusted as I made the enemy aim accuracy scalable and dynamically changed as the play progressed farther down the track. This issue may have become apparent had other developers played the game before the game jam submission.

bottom of page