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: Full Sail's Smashout

    - Grant Shonkwiler

  •  2. Documentation, pre-production and scheduling. These three words strike fear in the hearts of most students and programmers. But for us, documentation, pre-production, and scheduling went really smoothly.

    During the first two months of the project, these three things should be a developer's main focus. The rule of thumb I learned is that during this time, and until the game is fully planned, a developer may prototype, but shouldn't start writing engine code.

    Something that worked really well for us was splitting up the work and designating one documentation master to each document (pick people who enjoy this kind of work or they will seriously resent having to do it). We had to create three main documents for our project: a technical document, a production document, and a publishing document. Our technology lead took charge of the technical document, while I handled the publishing and production documents. From there, we both assigned modules of the documentation to each of our teammates, who then completed them and returned them to us to polish and compile.

    While we were writing the documentation, we also had to do pre-production work. We approached it as if we were doing research and planning for the project. One part of the pre-production phase that was extremely important and helpful to Smashout's development was doing a walkthrough of the game. Everyone on the team sat down and walked through the entire game (not including all the levels), mapping out everything that could happen, what we wanted the player to feel or see in each situation, and how the game should react. The walkthrough was extremely important to our design process because once we started production, we were able to look back at it whenever we needed to figure out how a menu, level, or feature was supposed to work.

    Here is where having only five team members really became useful. If one of us wanted something to go a certain way, we only had to convince four other people that it should be done. We also began researching all our core technology at this time, which enabled us to prototype early (discussed more below).

    Scheduling is quite possibly one of the hardest things to do for any project, but for us it went very smoothly because we constantly updated our schedule. We came up with all the main features of the game and tech early so we were able to write our schedule based on those features. Another core feature of our scheduling was to schedule breaks. We only scheduled 40 hours of work per week and took the weekends off. Giving the team time off is something that is hard to do on a five-month project, but I've learned that if developers (even students) don't take time off, they will not get as much done and they will not have happy teammates.

    3. Rapid prototyping and getting the games in the hands of the user. One thing that worked really well for us was prototyping our modules very early to see how they would work. The most important one we made was a small gameplay prototype. After extensive whiteboard prototypes, we decided to make an actual working version of our game.

    We made the prototype quickly (in about a week), and asked teachers and other students to play it. We came up with about six different control schemes and put these into the prototype and made it so the player had the ability to change the control scheme on the fly. We did this so we could begin gathering information on how the game would play and identifying problems that would occur while building the full game.

    After we came up with the prototype, we decided we wanted as many people as we could get to help test it. We set up a blog and an email address and began asking everyone we knew if they would help test our game. We had more than 100 testers, including some members of the GameCareerGuide forum (thank you), and their feedback was invaluable.

    Just having the testers was not what made them so invaluable. It was the method we used for getting builds to them and information from them -- Smashout Fridays. Every Friday, we would put out a new build of the game along with a list of questions that we specifically wanted answered by our testers: How are the controls? What do you think of this feedback effect?

    A database of all our testers was used to keep track of basic information about them as game players and their answers to the questions asked each Friday. This allowed us to quickly figure out how valuable their feedback was and weigh it. Since we were making a casual game that we wanted to be accessible to non-gamers, we always tried to focus on fixing the things that non-gamers complained about. Thanks to this testing method along with our early prototype, we designed a control scheme that works really well.


comments powered by Disqus