Run!

Platform: PC
Genre: 3D Action Platformer
Development Time: 12 Months
Team: Interdisciplinary team of 5 programmers, 6 artists and 1 producer
Languages: C++, Lua, XML

This was a huge project on a big team over a long time, and I very much enjoyed myself. Run is a parkour-like platformer set in a steampunk universe. We called it an "action escape game" because the goal was to get away from the guards in the city who were chasing you. Parkour is a sport (some would argue, a lifestyle) who's main focus is freedom and efficiency of movement. Many parkour-runners leap across gaps and vault walls and climb and hang and roll over any kind of urban terrain. Steampunk is a fantasy subgenre essentially mashing the Victorian era with high-technology, as if steam and brass clockworks were the leading technological powers of the time.

Our game was created as a junior project at DigiPen over about 12 months. Run is a 3D game built on the PC in C++ and scripted with Lua. My official role on the game was Game Designer and I had many other responsibilities besides that.

I was somewhat of an engine architect, and I designed an implemented the game engine structure, from level loading to engine communication using an event system and messaging system. I was also the scripting engineer, and I integrated the Lua scripting language into Run and made it available to the other programmers to use. I spent a lot of time working on the Lua system, and I added many features I am quite proud of. Any of the other programmers could expose any functionality of their engines to the Lua scripting system in one single function call. The lua system also had a built-in self-documenting system, so that when a programmer added a new function to the Lua library, they could easily document it so other programmers would know how to use it. This was also tied to an in-game console. It allowed the programmers to call any Lua script while the game was running. Furthermore, they could look up the documentation for any function at run-time. This was built on a system of function delegates (in C++) that I developed for the engine. During the course of the game, because I was the scripting guy, I got to know Lua in and out and backwards, but the rest of my team was still unfamiliar with it, so I created some notes (which you can find here) and led a seminar for my team to teach them the basics of Lua and how to use my system.

Using the function delegates and the Lua system already in place, I worked with the graphics programmer to build the GUI system. Designing the UI of the game was both the most fun and most challenging aspect of my experience on Run. The artists on our time (whom I might refer to affectionately as "our artists") were phenomenal. The art quality was simply stunning and I loved working with them. But sometimes working with artists is hard, and I learned and got to respect their work so much over the course of the year. The GUI had two parts, one was the in-game menus and HUD, and the other was a developer GUI for debugging and testing. The game's menus, loading screen and hud were beautiful. I developed a 2D animation system in Lua for the menus, and they were full of spinning brass gears and levers and such. The debug GUI (from which the console and in-game library documentation were created) used a third-party piece of software called AntTweakBar. This software let me put buttons and text boxes and other small editors on the screen in no time. I heavily modified the system to allow the use of my function delegates (rather than callback function pointers) and "object-orientify" it by providing a class wrapper and lots of utility methods. The other programmers loved it, and the guy creating our level editor used it all over the place. The physics guy could easily modify object properties in real time, and the graphics guy could turn on and off effects and change lighting positions, etc. while the game was running.

I was also the level designer for our game, and when it was complete, it had two, fun to play levels. I spent a lot of time using the level editor. The editor had three stages, the tile editor, the building editor and the city editor. I didn't do much in the tile editor, that's where the prop/scenery artist and physics guy would set up the textures and collision data for parts of the scenery. The building editor was used to put the tiles together and form full buildings. The city editor was used to place and orient buildings, set up triggers and place entities in the world. I spent most of my time in the city and building editors. I have some experience in using editors like Valve's Hammer Editor and Blizzard's Warcraft III editor, so it was a fun experience for me.

Here are some screenshots from the game during development:

Back