Involuntary Runner is a technically demanding runner-style game with a twist! Jumping is automatic. Instead, you control a man’s four involuntary organ systems. Beat, breathe, eat, and fart your way to insane distances!


You can play for free online!


After completing the project for the scope of the class, our game received recognition on a variety of press and indie game blogs:
Rock, Paper, Shotgun
We also have big fans in Europe:


Here’s a cool shot you’ll never get a chance to see in-game.
These are all of the game’s platforms and food pick-ups. Planning ahead for mobile releases, only two texture files are referenced for all of the game platforms seen here to keep draw calls at an absolute minimum. Clever texture space planning, (like not having to see the back-sides of any platforms), and re-usage helped save room for necessary decals, like the weight limit bridge sign.
All back-facing geometry was manually deleted ahead of time to ensure culling optimizations. I was uncertain how Unity’s engine deployed on various mobile platforms would handle draw culling, so I did this step as a precaution.
Fun Fact: It takes 21 days for a habit to form.



On the left, the model wireframes. On the right, the diffuse texture of all the “dock” platforms in the game.
No normal or specular maps were used in the game (with the exception of the metal checkpoint buoys). We decided against the use of specular or normal maps namely to save time, but also to focus the visual style in a way that could be translated to a small mobile screen.
Fun Fact: 10,000,000 have the same birthday as you.



Here is a side-by-side comparison showing off the dynamic lighting system within the game. As you run, days pass by cycling through day and night time because that’s awesome.
To accomplish this, I engineered a system to manage two complementary lighting rigs – a global and player rig. The global rig consists of a directional “sun” light to cast shadows and illuminate platforms. The player rig consisted of three position-relative point lights, each with different lighting responsibilities. Two point lights act on specifically the character model. One of these was positioned betwen the camera and the player model, whereas the other acted as a rim light and placed behind the character. A third light was positioned above and attached to the character, but did not light the model. Instead it acted as a sort of “light radius” to help focus visual interest on the busy screen.
Fun Fact: There is a town in Nebraska with a population of 1.



This is the high score screen of the game, viewable from the main menu or when you finally lose. There’s a lot of neat stuff going on here, so I’ll break it down.
On the left, there’s a fairly clear highscore table. It tracks username, keyboard input (we call it “style), and distance ran. This data is gathered from each playthrough and sent to a server-side database. The bottom lower left has what you could refer to as a “live feed” of incoming scores. It updates as soon as scores come in. This feed gives the game a really cool sense of connection to the greater player community, especially when tons of people were playing.
I accomplished this highscore system by using a MySQL database, queried with PHP. The system is very flexible and let us track a whole lot of additional data not shown here. All scores, whether submitted to the high score board or not are tracked and stored in the server. This gave us invaluable data to help in balancing the gameplay experience to fit the average play curve we were looking for. We also gathered data on music selection, how the player died, and how long the player stayed in-game.
On the top right, you can see what we refer to as the “death string.” This is a generated at random from a large selection of witty or not-so-witty sentences that reflect one of the many ways you can die. This feature helped make each death more personal and unique.
The rest of the interface beneath the death string is basic GUI that allows the player to submit their score the leaderboard.