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!
Tuesday, June 17, 2008
Smashout 1.1
Hello Smasherouties!
So we finally had Gold turn-in for class today at Full Sail. It went pretty well and right after a quick celebratory breakfast at the I of HOPS we started working on an Arcade Version of the game for these fancy Arcade Machine boxes that are in our lobbies at Full Sail. So while we were doing that we found a few bugs and went ahead and resolved those for a new release that we are presenting right now!
Smashout 1.1 is an installer like Smashout Gold but contains the following:
Changes
Enjoy y'all! We will probably have a newer version in the next few days. However, I should note that as school is winding down and most of the team is splitting up to different parts of the country, this may very well be the final days of Smashout. I'll make sure we post some nice final thoughts so we don't leave anyone in the dark.
So we finally had Gold turn-in for class today at Full Sail. It went pretty well and right after a quick celebratory breakfast at the I of HOPS we started working on an Arcade Version of the game for these fancy Arcade Machine boxes that are in our lobbies at Full Sail. So while we were doing that we found a few bugs and went ahead and resolved those for a new release that we are presenting right now!
Smashout 1.1 is an installer like Smashout Gold but contains the following:
Changes
- Levels P1, P2, and P3 have been removed. These were presentation levels and meant for School Purposes only.
- Instant win and Level Cylcing (via keyboard) have been removed. These were always intended to be debug keys.
- Bug with coming out of over tilting and pressing grandma mode would case game music to play at normal levels has been fixed
- Bug that caused Grandma Mode to stay on if activated right when ball dies has been fixed. Grandma Mode will now be disabled as soon as ball dies.
- Bug where points from last brick are not factored in high score that is actually saved has been fixed.
- Mouse input seemingly being stopped when mouse is all the way on the side of screen has been fixed. You can now keep moving the mouse even if the cursor is against the side and paddles will rotate accordingly.
Enjoy y'all! We will probably have a newer version in the next few days. However, I should note that as school is winding down and most of the team is splitting up to different parts of the country, this may very well be the final days of Smashout. I'll make sure we post some nice final thoughts so we don't leave anyone in the dark.
Saturday, June 14, 2008
Race to the Sun
The Smashout Team is hard at work gearing up for Final version of the game. Due to this, we decided not to post a release on Friday and instead wait till Monday night.
Thanks for your patience. Grant bets $1000 of his own money that it will. If it doesn't, you can send emails to him demanding the money.
Thanks for your patience. Grant bets $1000 of his own money that it will. If it doesn't, you can send emails to him demanding the money.
Friday, June 6, 2008
What is going on!?
Hey hey everyone.
I know its been a while (notice the space a while) since any of us have posted. I'd figured I'd take some time out this evening to give a well deserved update to you, the loyal followers of Smashout.
So first off you'll notice a new build is available over on the side there. Go ahead and download it. I triple dog dare you. There are some cool new features in this version. I think we have finally found a control scheme that will make most people happy. For those who are intrested, this one is called "Quadrant Spin." We have also ramped the SHAT out of what happens when you beat a level. Seriously, give it a whirl, I think you'll like it.
We have also added several new levels. So do yourself a robot rocking favor and get out there and download it!
Now, to continue:
Development has been going smoothly for the most part. The team has been putting in several hard hours and we have become absolutely focused on "the little things." This means that we include new features but they are designed only to accent and fix primary features. This usually includes more transitions or accompanying audio/visual assets.
What is kind of funny about the little things is that I've become very obsessed with them. When I started at Full Sail I was very much focused on tech but now I find myself spending all my time planning fade ins and fade outs for every little thing.
I know its been a while (notice the space a while) since any of us have posted. I'd figured I'd take some time out this evening to give a well deserved update to you, the loyal followers of Smashout.
So first off you'll notice a new build is available over on the side there. Go ahead and download it. I triple dog dare you. There are some cool new features in this version. I think we have finally found a control scheme that will make most people happy. For those who are intrested, this one is called "Quadrant Spin." We have also ramped the SHAT out of what happens when you beat a level. Seriously, give it a whirl, I think you'll like it.
We have also added several new levels. So do yourself a robot rocking favor and get out there and download it!
Now, to continue:
Development has been going smoothly for the most part. The team has been putting in several hard hours and we have become absolutely focused on "the little things." This means that we include new features but they are designed only to accent and fix primary features. This usually includes more transitions or accompanying audio/visual assets.
What is kind of funny about the little things is that I've become very obsessed with them. When I started at Full Sail I was very much focused on tech but now I find myself spending all my time planning fade ins and fade outs for every little thing.
Subscribe to:
Posts (Atom)