Educational Feature: Student Postmortem of Smashout

When five students at Full Sail teamed up to make their final game project, they intentionally chose to keep the game small and focused. Following their instructor’s mantra, ‘Make it fun and done’ may have been the best decision they made. Project lead and Full Sail alum Grant Shonkwiler (who is now employed in the game industry) has just published a postmortem of the game, Smashout, on Gamasutra's sister educational site GameCareerGuide.com. Smashout, a 3D Breakout-style game, is a lot like pinball with more complex features and scoring. The students who made the game were all in the undergraduate game development program at Full Sail. Shonkwiler writes: “[W]e really wanted to make a game that would be fun and easy to play. Thanks to the level editor we used, we were able to try out many different level schemes (and allow other people to break them), but we feel like the final ones used in the game are the most polished and the most engaging. By including just a few objectives in the completed game and a small number of levels, we were really able to focus on polishing the final product and making the gameplay fun and engaging.” This particular group of students seems to have been highly aware of, and therefore resilient against, most of the common hitches of student game development projects: feature creep, over-scoping, minimal preproduction, and lack of prototyping and testing. On the other hand, as one of the “What Went Wrong” sections of the postmortem illustrate, even students who are hyper conscious of their process sometimes encounter painfully common problems, such as communicating with one another to the extent that game developers do, as Shonkwiler reveals in this excerpt: “Throughout the project, a few team members faced a number of personal issues and family situations. One of our team members was going through a hard time with his girlfriend and was having some financial problems, which caused him to be stressed, which resulted in him not sleeping well, which affected his work and the way he treated the rest of the team. He would show up late for meetings and not let us know that he was going to be late and would also fall asleep while working. These kinds of issues caused delays, not to mention a little bit of bitterness, from the team. If we had had more open communication with each other when these issues were affecting someone’s work, this would not have been such a big issue. When working on a game development team, each person comes to rely on every other person. If someone’s work is slipping because they aren’t showing up on time or are falling asleep on the job, but the rest of the team doesn’t know that there is a serious personal or emotional problem behind it, the team is likely to interpret the person’s actions as them being lazy or not caring about the project -- in other words, ‘he is letting us down.’ Then resentment kicks in. On the other hand, when people explain a personal problem that is directly or indirectly affecting their work (or their attitude), then there can be more understanding of their behavior, and thus better efforts by other team members to support not only the individuals, but their work in relation to the project, until they can catch up again. While this was not something that we could have necessarily 'fixed,' we could have definitely handled it better.” You can read about all the other things that went right and wrong in the complete postmortem of Smashout, available now on Game Career Guide.