So this was a true post- postmortem. But due to the fact that I have been so busy with the move and the new job I just did not finish it until now. But check it out Postmortem
Thanks to Jill Duffy and GameCareerguide.com for featuring the article.
Tuesday, November 4, 2008
Sunday, July 13, 2008
Smashout 1.2
Hey folks!
So I know things have been quiet on the Smashout Front, but we've got a little update for ya. Smashout 1.2 fixes the following bugs:
So I know things have been quiet on the Smashout Front, but we've got a little update for ya. Smashout 1.2 fixes the following bugs:
- Hidden buttons on some menus that resulted in the game seemingly freezing have been fixed
- A small audio bug that occurred when over tilting on certain computers has been addressed. If the the game audio is still messed up after coming out of over-tilting, please email me at naveen.nattam@gmail.com
Wednesday, July 2, 2008
It's coming
I am going to write a postmortem like Naveen but I am currently taking a three week vacation with shoddy internets. So after I start work it should be up. :)
Friday, June 27, 2008
Thats a Wrap!
Casey (our Art Director) had made a promise to us that if we got Smashout onto the Full Sail Arcade Machine (a desktop pc that is in a special cabinet with joysticks/buttons) that he would buy us Pizza. He made good on his promise : check it.
Monday, June 23, 2008
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.
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.
Saturday, June 21, 2008
Thursday, June 19, 2008
Did we just Smashout?
I think so.
For those of you who are looking at this site for the first time after our presentation at Full Sail, then welcome! This blog serves as our main site for the time being. Its pretty simple and allows us to keep you informed about our progress. So thanks for coming to visit us! We hope you enjoyed the presentation as much as we enjoyed doing it.
Smashout has been one of the most exciting things to ever work on in my life. It was a joy to create and even greater joy to share. I hope I can keep getting this vibe for the rest of my career. The presentation was a thrill to do and to feel the crowd dig the hard work the team put in was simply one of the most amazing things ever.
So if you are just joining us, go ahead and download Smashout 1.1. This is the newest version of the game (even newer then what was at the presentation). Some bugs have been fixed (see previous post) and some minor adjustments been made. We hope you can enjoy it.
As always, please email us at whiteboardlogic@gmail.com with any of your thoughts!
For those of you who are looking at this site for the first time after our presentation at Full Sail, then welcome! This blog serves as our main site for the time being. Its pretty simple and allows us to keep you informed about our progress. So thanks for coming to visit us! We hope you enjoyed the presentation as much as we enjoyed doing it.
Smashout has been one of the most exciting things to ever work on in my life. It was a joy to create and even greater joy to share. I hope I can keep getting this vibe for the rest of my career. The presentation was a thrill to do and to feel the crowd dig the hard work the team put in was simply one of the most amazing things ever.
So if you are just joining us, go ahead and download Smashout 1.1. This is the newest version of the game (even newer then what was at the presentation). Some bugs have been fixed (see previous post) and some minor adjustments been made. We hope you can enjoy it.
As always, please email us at whiteboardlogic@gmail.com with any of your thoughts!
Subscribe to:
Posts (Atom)