Trigger Happy was my graduate capstone project developed in 2010. It was a networked first person shooter that saw players placed one of two teams. There are three match modes that players have at their disposal; King of the Hill, Assault, and Deathmatch. Players strive to use teamwork and strategy to win each game with the assistance of Modifiers. Modifiers are devices that allow players to change the landscape of a battle almost instantaneously. Effects rendered from Modifiers include reversing gravity, shrinking and enlarging players, reducing their grip to the ground causing them to slip and slide all around the world, and even create decoys of yourself to distract opponents!
I worked with a team of 4 other people who’s skills ranged from artist to tools programmer to audio designer. As a team, we all wore many hats in order to finish this project. Along with building the game itself, we were also tasked to building the engine as well as write a full industry level game design document. The project spanned about 30 weeks from concept inception to final touches. The engine is a component based engine developed in C++/DirectX 10 with Trigger Happy running on a LUA front end.
-
- Screen grabs and asset previews from Trigger Happy
Designing Trigger Happy
Along with designing a game from the ground up, we also went through the documentation process designed to mimic the game industry itself. This included coming up with the idea, pitching the idea, and then refining the idea until the pitch was acceptable. We also wrote various documents in order to further Trigger Happy’s concept. This included an elevator pitch, a high concept document, and a game treatment document. These were all done before writing the massive bible that would house every idea related to Trigger Happy. Below is the table of contents extracted from our final document write-up that was submitted along with the finished project. Further exerts from this document can be made available upon request but due to the massive size of the document (418 pages!), I won’t put the whole thing online.
Designing the game states and menu flow
One of the things that I wanted to achieve with the menu system was a sense of fluid movement. When writing the comparative analysis for our game, the games we compared to specifically for game state analysis were Halo 3, Team Fortress 2, and Unreal Tournament 2004. When looking at these games, we made note of what state the player was in during any part of their game experience. We made note of a basic set of states the player went through and used those as a baseline to create our game-state and flow chart. In the end this is the game state flow chart we used for Trigger Happy.
During our analysis, we found that the basic states included a main menu, some sort of lobby configuration, a match lobby, a spawn state, and an in-game state. We took that data and built our flow chart around those. The notable design challenge was to decide how the player would move from the match lobby to the in-game. The starting point for this was asking ourselves, “what would the player need to have once the game started?” That’s where the decision was made to have the player go straight to the weapon selection screen. This allowed the player to think about and decide what weapon and modifier configuration to take into battle. It was here that we were also able to setup a basic set of weapons to attach the player should they simply click through this state and to the respawn state.
Scripting the Menu System
As an example of how we scripted our menu system, here is the scripting file for the spawn screen in the game. This file shows a basic example of the structure we used for the menu system. Overall to script Trigger Happy, we tried to employ an object-oriented system to keep things organized. We approached the structure from the point of view of the client player making the assumption there would be only one person operating the game on one computer at a time.
For the screens, all GUI components are generated in the initialize function. All the GUI components have functions mirrored from the C++ components they represent inside our engine. From there, whenever the screen is live, we run that update function to determine if a clickable GUI component has been activated.