Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Get the latest Education e-news
 
  • Student Postmortem: Carnegie Mellon's Northrop Grumman Recruitment Game

    [06.21.07]
    - James Portnow

  •  What Went Right

    The Team

    I'd argue that the team matters more than the project. I'd also argue that we had (almost) the best possible team for this project.

    The team was Trey Davenport, taskmaster extraordinaire (producer), Giray Ozil, shader wizard and graphics god (lead programmer), the ever lovely Maria Barot, code mistress and sweet priestess of color (programmer), Ashutosh Mimani, my accidental brother in adversity and a man who will work himself into the ground to get it done (programmer), Samik Bhowal, wellspring of energy and control systems crafter (programmer), and myself, James Portnow, lead designer and ne're-do-well.

    Now for the part that's relevant to you the reader... As you can see the team was programming heavy. This allowed for rapid prototyping and quick iteration. The ability to make large changes quickly became key to crafting the experience as we were never stuck with a decision and we could let playtest be the final arbiter when a problem arose that we did not know how to solve.


    Moreover, as a designer, having an amazingly strong programming team pretty much let me blue sky. I remember asking if something was possible given the engine that we were using and getting the response "No. We'll have done by six." True to their word, six pm rolls around and the programming team has built major new components into the engine in order to do what I asked. You couldn't ask for more as a designer and, honestly, the product turned out ten times better because we were able to continuously improve the design.

    This programming strength also allowed us to have a dedicated designer and producer. Given the size of the team this is incredible but was paramount to the success of the project. Our team was fairly democratic, with the person who was most passionate about a subject usually getting the final say on the issue, but just having someone whose job it was to have the last word on design or scheduling streamlined the process greatly. Without having someone whose job it to make sure we were following the most efficient path towards our goal and someone else to define what the goal was I doubt we could have delivered a finished product in the limited time available.

    You probably also noticed one thing that this team is lacking... an artist. We had to contract out for our art and this hurt us greatly, but we'll get back to that later.

    The Client

    Our contact within Northrop Grumman was a man named Mark Conger. There are three factors that I believe set Mark apart from your standard corporate client:

    Previous experience in the games industry: Mark's industry experience gave him a better idea of the limitations of the project. It also allowed him to give valuable feedback regarding the design of the game. He was a great intersection point between the corporate world and world of video games. He often helped us meet the needs of the corporation without sacrificing too much of the gameplay.

    Boundless Enthusiasm: Our project was Mark's pet project. He honestly wanted it to succeed. It wasn't just "part of the job" for him. He flew out several times to meet us and even went so far as to storyboard out his thoughts on how to design one of the major sections of the game.

    Trust: Mark trusted us enough to give us a pretty free hand in the creation of the game. He understood that this was our field of expertise and that we wanted to make the best possible product for him.

    This was an unbelievable boon for us. I've heard tales of game makers having to drag their clients kicking and screaming to make a good game (or worse yet, not being able to). Not having to waste time or energy fighting to be allowed to make a good product was instrumental in, well... delivering a good product.


    5-Minute Experience

    Early in the project we decided that we were going to make an experience that lasted no more than five minutes. This allowed for high turnover at the recruiting booth and didn't take too much time away from the participants at the job fair. This also greatly limited what we could do with the project...

    But these limitations became some of our greatest strengths. With a team of six and three months to work we had no chance at rivaling any of the current gen flight sims, luckily we didn't have to, we only had to make our five minutes as good as any five minutes they had to offer.

    The five-minute experience also forced us to be realistic about what we could include in the game. Much of this project was about cutting features rather than adding them. Initially we had a detailed set of countermeasures that could be deployed from the plane but we but the entire countermeasures feature when we realized that it would take to much time to teach the player how to use them.

    Playtest

    Every week we'd find a nearby university, haul the entire experience out there and play test rigorously. We'd have the users fill out surveys after they had completed the experience then Trey, our producer, would compile the results into a series of charts and graphs for that we'd discuss at the next team meeting. The experience taught us a lot about test methodology.

    At one test we were testing out two different arena maps. The survey asked the users "which terrain did you like better, the first terrain or the second terrain you played". Every one of the users answered that they thought the second terrain was better. This baffled me as I thought the first one was significantly more fun, so I switched the order in which the users played the maps. Low and behold everyone still answered that they liked the second map better.

    By the time the players got to play the second map they had a better handle on the game in general and so enjoyed the play experience more. When we asked them about maps they naturally assumed that the change in map was responsible for their improved play experience. To avoid this in the future we showed any given group of play testers only one map to play on and asked them to rate its "entertainment value" on a 1-10 scale.

    The shear amount of play testing we did coupled with close examination of our own methodology was a key element in improving our game. Most of all it helped us determine what was intuitive to a player (as our game was to be played largely sans-instructions). Whatever we found ourselves telling players again and again during the play test were the things that we worked on making more intuitive.

    Lastly play testing was very important for dealing with our client. It was an easy way to resolve disagreements. Anywhere where the team's opinion and the client's opinion differed we'd simply conduct play testing and do whatever appealed most to the end user.

    Team Building

    Early in the year our producer jokingly suggested that we all actually (gasp) play video games together. We called it team building and that's just what it was. Surprisingly playing together had an amazing effect on the team. First it gave us a shared experience other than work, it gave us a way to hang out and something to talk about that wasn't work related, this brought us much closer as a group. Second, if you are cooped up in a room with the same six people for fourteen hours a day, spending a half an hour killing each other can be quite healthy. Third it gave us a way to recharge. No matter how dedicated you are, if you work continuously for twelve hours your work will start to flag. Lastly it gave us an incentive, I remember more than once saying phrases like "After we get the missile system let's play a game of UT".

Comments

comments powered by Disqus