Ruin Runner is an iOS game made using Unreal Development Kit. Players tap locations to set waypoints in the environment. Once they have a few waypoints set, they tap the start icon to send their character running from point to point. As they run, players can swipe upward to jump over pits, downward to slide under traps, and sideways to dash past an obstacle.
- Engine: Unreal Development Kit (iOS)
- Development Time: 4 months (during a very busy school year)
- Roles: Lead Design, Level Design, Producer, Scripter
- Other Contributors:
Design and Production Considerations
Given that the game was built for iOS, controls and screen space were big considerations when it came to design. Several ideas that involved tracing patterns with your finger, and a game where the device acted as a window to another world were discussed, but were eventually thrown out due to the large amount of risk involved with such a project. The mobile version of UDK had just been released that month and we knew that there was a high potential for bugs in the engine. The current design was settled upon because it was simple yet deep from a gameplay perspective, and low risk from a programming and art production perspective.
Strategy and Action
Ruin Runner was designed to have a balance between strategic planning and fast paced action. In the first phase of gameplay, players would plan out their route, taking into consideration both obstacles and point pickups, and time the start of their run so they could make it through to the end. Most levels were to have several paths through them, allowing for different skill levels and play styles to show.
The player begins each level with a base score that doubles as a timer for a stage. In the video for example, the timer begins at 1000 and subtracts 1 point every second. Setting down a waypoint costs 25 points, and picking up a gold bar adds 100 points. This means that dying even once can potentially be devastating to getting a high score if a lot of waypoints are required to beat a level. It also means that mastery and perfect execution of a string of moves is rewarded quite handsomely. This incentivizes choosing an optimal path through a level, setting as few waypoints as possible and picking up as many gold bars as possible.
Due to the very simple design, very few mechanics had to be changed due to production constraints. One thing that did change however was the ability to climb up walls. This change made planning levels for the game very different, as it greatly limited player freedom when it came to choosing a path through the level. Levels became much more about timing and execution rather than planning a path, and designs were adjusted accordingly.
- Death Pit: A simple pit that is either bottomless or has a floor covered in spikes. Players can jump over these by swiping up while running.
- Blade: A circular razor that shoots from a slot in the wall. Players can slide under these by swiping down while running. They can also be avoided simply by timing a run so the blade does not shoot out when the player is in its path of flight.
- Crushing Wall: A stone block that protrudes from the wall on a set interval. These often come in pairs that slam together when both blocks protrude. Player can touch these and not die as long as they are not crushed by them.
- Spiked Wall: A Crushing Wall with spikes attached. These can kill the player individually and do not often come in pairs. This is important because it means they can be placed in more locations than crushing walls.
This is an example of a typical level. There are several paths through the level and different challenges depending on what path is chosen. Traps are marked in red and paths in yellow.
The two primary paths through the level are seen below. The first takes longer but is safer while the second is faster but much riskier. This sort of risk/reward choice is very important in Ruin Runner, with choices having a profound difference on a level’s final score.
The main difference between these paths is the kind of traps that are found along them.
Path One: On this path, traps are more numerous but in general easier to avoid. They include two Death Pits, a Spiked Wall, and a hallway with two Blades and a Crushing Wall. Players have ample space to stop and calculate their next run, and can get close to traps which makes timing easier to figure out.
Path Two: This path has three Death Pits, a Blade and makes creative use of a Spiked Wall. The player can normally jump over a gap that is two units wide, but along this path there is a Death Pit that is three units wide. The only way it can be crossed is by timing your jump so that when the Spike Wall extends outward, the player lands safely on top of it and quickly runs to safe footing. Because of the distance between the player and the spiked wall, it is much more difficult to time this jump than it is to avoid the traps on Path One.
This is an example of a basic level that focuses on timing and execution of controls rather than strategy. There is only one path through, but execution is quite difficult which results in a timing/twitch style of challenge.
Basic tweaks to the player’s run speed and jump distance are the most fundamental changes that can be made. These changes would be to standardize actions such as jumping and sliding to to take up one block rather than two. This would give the game a much more satisfying rhythm when in action.
Adding this mechanic would greatly increase strategic depth as players would have more choice about what path they want to take through a level. Some blocks would be scalable while others are not, and some blocks would have ladders on them which assist the player in the climb. In gameplay, standard scaleable blocks would require the player would swipe upward to initiate the climb, whereas ladders would not require this swipe. And of course unscalable blocks would not be able to be climbed at all.
Additional Traps and Triggers
Other additions include other traps and interactive pieces in the environment. This would include blocks that break when you walk or climb on them, vines used to swing across gaps, and various pressure plates that can move environment pieces or activate traps. These would all serve to add variety to gameplay and help create interesting gameplay combinations for experienced players.
Since score decreases at a constant rate, a challenge mode could be implemented where the game continues from level to level with a persistent score, and only ends when all levels in the sequence have been completed or the player’s score reaches zero. This takes better advantage of the existing scoring system where gold bars add points and setting waypoints subtracts points.
One final feature would be and undo button. A player would begin a game with 3 undos and earn an additional undo every 5000 points until they reached a maximum of 5 undos. The amount of undos a player has at the end of a round earns them bonus points. This is a nice way to handle the point system because players are not punished for using undos but rather rewarded for not using undos.
Given that UDK for iOS was in the first public release, using this engine was a large risk from the beginning. The team understood this, but was confident after experimenting with it that the game could be completed, however a blatant lack of documentation at the time caused us to lose many work hours trying to figure out simple problems that should have taken very little time.
This project was very educational to me in terms of my own limits, and how to work with and around other team members’ schedules. The semester of Ruin Runner’s production was extremely busy for everyone on the team, so creating a work schedule that fit everyone’s needs was extremely difficult. I also took on far too many roles, stretching myself quite thin.