Smashout Post Mortem : The Naveen Nattam Chronicles

Well I figured I should get this started. I'm going to try and bug everyone on the team to post a little something about their experience so that at least this blog (if left untouched) will be a final record of Project Smashout.

So first off I figured it would be wise to discuss my position. I held the title of Technology Lead which meant I was responsible for overseeing all code that was written. What this ultimately lead to was me being head of intergration. It was my job to make sure that all the modules were able to communicated and that when problems arose that were across multiple programmer's work, I was able to sort it all out. This put me in a great position to also do all of the gameplay programming, which binds all the modules that everyone created. From here, I was able to take the tools that each team member created and work them into what would become Smashout. Now with that out of the way, lets do what I know most post mortems tend to do: What when right, What went wrong.

What Went Right
1. Risk Assement and Planning
We fell into a good habit of having these "prioritization" meetings. These tended to come up around 1-2 weeks before each milestone, when every day counted and could not afford to be wasted. At these meetings we assesed fully where the game was and what was needed to hit the milestone. From this point, we would make a list of all features that were not done or needed to get done. Then we would go back through that list and prioritze what was important. It was at these meetings that we would also cut features to improve existing ones. This was a crucial part of Smashout's development that lead to it being a success. With an ample amout of time left, we were able to organize then push so that by the last day before the turn in, we still knew what to do.

2. Low Tech
This may need a bit of explaining. When we set out to make Smashout, we knew that we did not want to pursue advanced tech, specifically graphically. While our rendering lead was interested, he was also vary wary of how much time could be sunk into visual effects that would leave the game suffering overall. With the team focused on an overall complete experience, we skimped where we could on technology that would require heavy research and development. By being able to avoid this, we had more time to fix existing tech bugs that would appear then constantly putting in new tech by the end.

3. Getting it out early
By the time we finished our Proof-of-Concept, we already had a version of the game that put up for download. Grant handled mass emailing several friends and family members who were willing to give us advice. With the game in the "public's" hands so early, we got tons of feedback that was worked into the game very quickly. An unexcepected bonus was that we were able to use old feedback to limit wasting time on flawed designs.

4. Feedback
We were incredibly lucky with Smashout to get assigned an Art Director who was actually an audio specialist. With him, we began intergrating sounds into the game before we even had placeholder art (bricks were non-textured). This meant that we got to experiment with intergrating different audio effects early on and realized that Sound was ridiculously important to the game (which should be true for ALL games). A cool side benefit that I can speak of as the gameplay programmer was that I began to make holes in my code where I could insert sound effect calls early on, knewing fully well how important it would be. The ultimate effect of all of this lead to developing the Effects System that would allow us to so easily add content in the last 2 months of development.

What Went Wrong
1. Lack of Testing Protocol
As the gameplay programmer, I ended up doing a ton of intergration work. During this process I found lots of bugs in other teammates modules. I wasn't innocent of this either and lots of behavioral bugs appeared in my modules. In some cases, it was very obvious stuff that just wasn't tested. All around, there several occasions where if a proper testing method had been developed and be enforced, we would of saved a lot of time tracking down bugs amongst 10 modues versus 1-2. This also lead to a lot of "coincedental working" situations where modules appeared to work only to find out later it was because that module and other required modules had flaws in them and new modules were written to accomidate that flaw. Sometimes we would fix things only to find 10 new bugs appear.

2. Stress Testing
Several instances occured where tech would seem to operate just fine. As we would slowly push the game more and more, bugs would occur that just showed our tech sometimes wasn't up to the task. According to our schedule, we worked on all the tech in the first 2 months of development. It was during this time that would should of implemented hard stress tests on everything because finding out it the tech could not take so much in the last month means we have to scale the game back rather then improving the tech.

Conclusion
Smashout was simply a joy to work on. We've been told that very few Fullsail Final Project games have this much audio/visual feedback and as the gameplay programmer, nothing could make me prouder then to hear that.