Planar Retainer is 3D Arcade Space Shooter where the purpose is to fight back wave after wave of enemies to protect the universe. It features an array of weapons, physics-driven wall warping, and multiple enemy types.

The Planar Retainer project started out as a two-person team but at the start of the second semester grew into a three person team. I acted as the technical director and my programming responsibilities were to create and maintain the physics, audio, and input engines in addition to originally establishing the game engine's framework. This project marked my first game that would modularize code into separate libraries as well as one that strived to be as data driven as possible. A total of three libraries are used in the game: a common library, the graphics library, and the physics library. In the end the way I programmed things the audio and input engines could also be modularized relatively easily--something we didn't plan for at the start of the project--but we decided to not take the time to do that. This marked the second time I worked with "secondary" systems like input and audio (TCubed was the first) and I discovered I enjoy working with them more than major systems such as graphics and/or physics.

Robot Apocalypse Racer, a 3D arena battle racing game, you pilot a vehicle that can change from a boat to a car to a plane. It features randomly generated terrain, a dynamically moving water level changable by the players, and 8-person LAN multiplayer.

The Robot Apocalypse Racer project spanned two semesters but was plagued with problems the first, effectively limiting its total development time to one semester. On the four person team I acted as the project's technical director and was in charge of the graphics for the game. In the start the game was going to be a straightforward lap-style racing game in the vein of Mario Kart but the aforementioned problems forced us to redesign the game into what it is today. Thus I tasked myself with creating the random terrain generator which was designed around the need for rolling hills and gentle slopes as our physics engine wouldn't be able to handle anything more. I also implemented a quadtree to speed up rendering of the terrain which in turn allowed me to increase the vertex count of the plane I morphed into the random terrain. We also wanted to keep the three-tiered vehicle transformation as originally designed so I added the water plane which added the new gameplay mechanic of the players being able to change the height of the water at will. I had to learn how to work with the networking and it needing to be able to create the same map on both sides as well as many other pitfalls that having networking in a game opens up.

During the production of this game I ended up working too hard on parts of the game to the detriment of the game as a whole. The first was making the graphics engine use not only shaders but to have a fixed-function pipeline renderpath in case the game was being played on a computer that had no shaders. The second was putting too much work into making the user interface a full-fledged, expandable, dynamic windowing system. In both cases I was overreaching what I needed to do: I was attempting to create a professional grade system while working on--and within the timeframe of--a student product. As such a lot of time and effort placed into these systems could have been reallocated to make the end product better. I'm happy to learn such a lesson in school which means I can avoid it in the real world.

TCubed is 2D sidescrolling action exploration game where you are tasked to cleanse a computer system of a virus while inside of the computer. It features four distinct zones, an innovative disk-based battle/puzzle solving system, over an hour of content (including hidden secrets) and a multiplayer minigame.

TCubed was created by a four person team. I acted as the product manager and I was in charge of programming the audio and input systems but I extended my job to also include the user interface as well as the entire multiplayer minigame. We ended up programming the game so quickly that we had enough time to add tons of content to the game. It takes me about 50 minutes to beat the entire game with 100% completion. Such a level of content is really unheard of in DigiPen games. Also because of our excess time I was able to effectively make two sound engines: one that used DirectSound for playing background music I composed using DirectMusic Producer, and one that used fmod to play the player's own music. To accompany the fmod system I created a standalone tool that could take folders of music or playlists and tell the game to use those for each zone just like how a different song would play based on zone while using the game-provided music. I didn't realize at the time what a luxury the extra time we had was and so I went into junior year starting with that approach (and if you read Robot Apocalyse Racer's section you can see that I learned my lesson).

The user interface of the game was my first attempt at doing one. It ended up being relatively simple but completely functional. The idea to make the beginning menu take place within the context of the game rather than it being just a text menu was to keep the game's theme coherent. The pause menu and tutorial boxes were all added late in the production cycle to polish the game but unfortunately because the decision was made relatively close to the end I couldn't create a visual style that allowed the pause menu to match the main menu. Likewise with the creation of the map: I added it after focus groups complained about getting lost but if I had planned it from the beginning a minimap would have been placed in the top bar and the design would have matched the overall design of the game itself much better.