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. In some cases, it was very obvious stuff that just wasn't tested. I wasn't innocent of this either and lots of behavioral bugs appeared in my modules. During this process I found lots of bugs in other teammates modules. 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.Īs the gameplay programmer, I ended up doing a ton of intergration work.
#THE SMASHOUT CODE#
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.
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). With him, we began intergrating sounds into the game before we even had placeholder art (bricks were non-textured). We were incredibly lucky with Smashout to get assigned an Art Director who was actually an audio specialist. An unexcepected bonus was that we were able to use old feedback to limit wasting time on flawed designs. With the game in the "public's" hands so early, we got tons of feedback that was worked into the game very quickly. Grant handled mass emailing several friends and family members who were willing to give us advice. 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.īy the time we finished our Proof-of-Concept, we already had a version of the game that put up for download. With the team focused on an overall complete experience, we skimped where we could on technology that would require heavy research and development. 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. When we set out to make Smashout, we knew that we did not want to pursue advanced tech, specifically graphically. 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. This was a crucial part of Smashout's development that lead to it being a success. It was at these meetings that we would also cut features to improve existing ones. Then we would go back through that list and prioritze what was important. From this point, we would make a list of all features that were not done or needed to get done. At these meetings we assesed fully where the game was and what was needed to hit the milestone. These tended to come up around 1-2 weeks before each milestone, when every day counted and could not afford to be wasted. We fell into a good habit of having these "prioritization" meetings. Now with that out of the way, lets do what I know most post mortems tend to do: What when right, What went wrong.
From here, I was able to take the tools that each team member created and work them into what would become Smashout. This put me in a great position to also do all of the gameplay programming, which binds all the modules that everyone created. 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. What this ultimately lead to was me being head of intergration. I held the title of Technology Lead which meant I was responsible for overseeing all code that was written. So first off I figured it would be wise to discuss my position. 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. Well I figured I should get this started.