Last Stand

Screenshot

Screenshot

Screenshot

Year: Senior
Role: Co-Designer and Co-Technical Director
Team size: 3
Language: C++ and Lua
Website: Here
Download: LastStandInstall.zip

Last Stand is a hybrid RTS/FPS (Real Time Strategy / First Person Shooter). You play the part of a lone marine who must defend his base on a strange planet from swarms of incoming aliens.

I'm very proud of this game! I started this project with one other guy. We decided to keep a small team so that we could retain a lot of creative control. We started work on the game over summer break before senior year so that we could get a head start. A third member joined us for the first semester of senior year. In the second semester we were back down to two, since the third graduated. Even though we were the smallest team in our class, our game is one of the best in our class!

This game has a lot of cool stuff going on. I'll talk about some of the things that I worked on.

The terrain is heightmapped and completely deformable. The initial heightmap is read from a file, then from there many random elements are added to the terrain based on parameters in the scenario file to give the terrain a unique look every time you play. When an explosion occurs, a depression in the ground is created, and dirt particles fly away, re-depositing elsewhere. As the battle rages on, the ground begins to look war-torn. I also developed an elaborate system to draw only terrain tiles that are in view, and to drop off the detail of tiles the further out they are to make the game run faster.

I did all of the A.I. for the game. There are four different enemy types in the game. The ant types (the ones that look like bouncing fuzzy balls) lay scent trails as they wander around the map. Other ants follow the trails of the leaders. If ants die, they send "bad" scent back up the trail, so that other ants may decide to pick a new path. By doing this, enough ants can avoid your turrets and exploit your weaknesses. The grunt types use the A* pathfinding algorithm to navigate around walls and into your base. The soldier types are ranged units that simply attack the first thing they see. Commander types also use the A* pathfinding algorithm to find which side of your base is weakest, then they take troops of grunts and soldiers around to that side of your base to do maximum damage.

We wanted our game to have tons of enemies on screen at a time. This created some challenges for the turret A.I. With so many enemies, it would be inefficient for every turret to check the distance between itself and every enemy to find the enemies in range. Instead, when turrets are placed, they leave a "footprint" embedded on the terrain. Whenever an enemy walks onto the footprint, it sends a message to the turret, signaling that it is available for targeting. Then the turret simply chooses an enemy in its list to attack.

The player has full collision with the ground and structures. He uses a jetpack to get around the world quickly. The jetpack causes the player to always tend toward a set height above the ground. His movement while using the jetpack is acceleration based, giving the jetpack a believable feel.

There are a lot more cool things about this game, and you should definitely check it out!

For more info, screenshots, and downloads, be sure to visit the game's website.


Damage Control

Screenshot

Screenshot

Screenshot

Year: Junior
Role: Producer
Team size: 4
Language: C++
Download: DamageControl.zip

In Damage Control, the player builds a robot, then enters it in a rink with other A.I. or networked human controlled opponents. Players remotely control the robot as it moves around the arena with realistic physics, collecting nuts as it goes. Robots can attack other robots using weapons, causing them to lose parts or nuts. Whoever has the most nuts when time runs out is the champion!

I was the producer for this game, so I did such tasks as organizing meetings, writing the timeline and milestones, making sure everyone was on task, resolving conflict, and creating periodic producer reports for the management (our teacher).

Junior games were required to have four major components: 3D graphics, A.I., networking, and physics. These were split between our four team members. I chose to do the graphics for the game, because I had never done graphics before and wanted to learn something new. The graphics were done in OpenGL. I created all the graphical systems in the game: Loading and optimizing models from 3DStudio Max, lighting, projecting shadows to the ground plane, rendering 3D images to a texture (such as the damage indicator and the machine preview in the machine builder), HUD/Menu 2D drawing, text with 2D and 3D positions, and particle systems.

Non-graphical work I did includes the menu framework and transitional effects with the large central gear moving up and down and rotating and the side flaps opening and closing. I also did the game logic relating to projectiles and damage.

This game suffered from having overly ambitious physics. Full rigid body rotational physics is not easy to build from scratch. Our physics guy was brilliant and was finally able to pull it off, but not with enough time left in the project for us to give the game the extra balance and polish of a professional title. Because of this, the game is more of a tech demo than a fun, finished game.


Run Time Crash

Screenshot

Screenshot

Screenshot

Year: Sophomore
Role: Designer
Team size: 5
Language: C++
Download: RunTimeCrash.zip

Run Time Crash is a 2D top-down action game in which the hero, Sarge, has crash landed his ship on earth only to find the population strangely hostile. The player must help Sarge explore, solve puzzles, and destroy enemies by using weapons and vehicles. Three huge levels and giant boss battles stand between Sarge and saving the world!

If you download this game, be sure to go into the Options menu and click the "FPS" button so that it reads "60". This will make the game appear less choppy. (If the game then runs too slow, switch back to 30.)

I was the designer for this game. As designer, my major responsibility was creating the levels. To help me do this, I created a tile editor for the game using C++ and Windows API. The editor can also be used to place objects in the world such as enemies and doors. You can link up objects as well, for example a switch can open a door or play a sound. The third screenshot to the left is of the editor, complete with the ugly programmer art it uses. You can download the editor if you like:
RunTimeCrashEditor.zip
The zip contains a readme file to help explain how to use it.

Other things I did on this game include the tile display and scrolling engine, boss battle logic, object trigger system, tile artwork, and dialog recording (although it's not my voice).

I wrote the soundtrack to this game using Music Write 2000. Here are the music files from the game:
Level 1 Music
Level 2 Muisc
Level 3 Music
Menu Music
These files end suddenly because they are intended to loop back and play from the beginning.


Mobius

Screenshot

Year: Freshman
Team size: 6
Language: C++ with editor in Visual Basic
Download: Mobius.zip

This is a freshman game, so don't take it too seriously!

Mobius is a text-based adventure game in which time plays a critical role. You are a man who continually wakes up and relives the same day over and over again, much like the movie Groundhog Day. Certain events happen at certain times and places during the day. You must pay careful attention to these details if you hope to stop the disaster that recurs at the end of every repeated day.

Mobius was our first chance to practice all working together on the same project at the same time by working on different files. I created the game engine and worked equally with a teammate to create the game editor. The editor has been lost, but it was a powerful tool that could be used to specify all rooms, objects, events, items, and descriptions and save this information to our own file format. This way, our game engine was separate from all content.

I worked with a teammate to create the initial game concept and design. However, after this point I became in charge of the technical design and mostly ignored the game design. The game is fun to play and explore, but near impossible to win by deduction.

Mobius was a two semester project. For the first semester, we created a prototype of the game that was purely text, displayed in the Windows console. I've put it here for download so you can see how far the game came:
MobiusPrototype.zip


Hoon's Balloons

Screenshot

Year: Freshman
Team size: 7
Development Platform: DigiPen's ProjectFUN
Download: HoonsBalloons.zip

This is a freshman game, so don't take it too seriously!

Hoon's Balloons was the first game I worked on at DigiPen. It was created using DigiPen's ProjectFUN development environment. You play the role of a young boy who is throwing balloons off of a roof in order to hit the innocent pedestrians down below. You have a set amount of time to hit enough pedestrians to get the score needed to advance to the next level.

This project was difficult to work on in a team because the assignment was to use ProjectFUN. This environment makes it difficult for different people to work on different parts of the code, since everything is integrated together in one file. I wrote the vast majority of the code for this game, as I had more programming experience than my team members. Some ended up only doing artwork, unfortunately.

I wrote the soundtrack to this game using Music Write 2000. Here are the music files from the game:
Level 1 Music
Level 2 Muisc
Level 3 Music
These files end suddenly because they are intended to loop back and play from the beginning.