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

  •  4. Data-driven design (DDD) and how the art team used it. One thing that we emphasized early on while developing Smashout is that we wanted to make the game completely data-driven through XML files. For those of you who are not programmers, basically, DDD decreases the amount of time spent compiling the game and allows developers to easily adjust things on the fly.

    While working on the game, our policy was "no magic numbers," and, "If you suspect that something might need to be changed, put it in a file." These two rules pushed us to make almost everything in the game able to be changed quickly. Where this system was really powerful was in our effects system. The effects system was what controlled all the feedback effects that are seen in the game: text effect, particle effects, sound effects, and so forth. Within these files, we could define an effect as being a sound, or a sound and particle, or any combination of effects, and we could add time delays and things like that.

    The reason this was so powerful is early on we decided that we wanted our game to be very feedback-heavy; and effects are things that take a lot of tweaking, so we decided to implement a system that would allow us to adjust the effects fairly easily.

    At Full Sail, student developers are assigned to an art director at the beginning of the project. The art director usually helps the students with the visual and audio design and feel of the game. We were very lucky to get Casey Coffman, who specialized in audio, seeing as Smashout was to be very heavy on audio feedback.

    The really great thing that came our of art team, Casey and a 2D artist, was their willingness to learn and help with the game. At the beginning of the project, we asked the art director if he wouldn't mind learning the scripting system for the effects so he could put them into the game, and he gladly took up the challenge. As a result, we were able to send him builds constantly, and he was able to place new art into the game whenever he wanted, speeding up our art integration by days.

    5. Stand-up meetings.
    Throughout the project, we adopted some very basic Scrum methodologies for our meetings. At the beginning of each day of work, we held a quick stand-up meeting, where we stated what we were going to work on for the day and with whom we would need to interact. During these meetings, it was my job to compare what people said with their schedules; we also used this time to address any problems with the schedule.

    The daily meetings allowed us to stay on task, flexible, and able to help each other with tasks. At the end of the day we would do a quick recap and see how close people were to finishing their tasks, checking once again to see if anyone was having any specific problems.

    One of the best things that came out of the meetings was our ability to cut features and focus our time on the most important things. Before each milestone, we would meet and decide which priorities were highest for completing the milestone. We were able to cut things that were unnecessary and focus on what would make the game polished and fun.

    What Went Wrong

    1. Lack of testing protocol. While working on integration, we oftentimes had modules that would not even work or would not work at all how we intended them to. Had we set up some sort of module testing protocol, we could have avoided this problem and saved ourselves a lot of time.

    In some cases, it was very obvious that the module just hadn't been tested. Sometimes the modules would appear to work until the moment a bug popped up, which we would fix, and then 10 more would appear. Even though having a formalized testing protocol in the process would have saved us time, I'm not sure we would have had time to fully implement it properly.

    2. Personal issues.
    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.


comments powered by Disqus