This week we finished and presented the results of our concept sprint for Carrier. All together the team produced a concept animation of the helicopter, a physics demo of projectiles and gravity, and a physics demo of the rope connected to the helicopter. We expected to have two other demos: a sample of movement controls and a looping background demo. While these two demos weren’t completed, our development isn’t really hindered because the concept sprint’s purpose was to help with brainstorming and weed out potential issues. Development begins with the next sprint.
Overall I’m very happy with what my team produced, and we plan to piece the demos together and add on to our current content to produce our first potentially ship-able product at the end of our first development sprint. Our first development sprint will focus on our primary mechanics, which are physics and movement. The goal is to produce a demo with buildings in the background, where the camera follows the helicopter, and the helicopter can accelerate towards a mouse click. Also, we hope to complete the mechanic of opening/closing the helicopter’s winch to pick up and fling objects around the environment using one of the concept sprint physics demos. The plan is to try to have everything near completion within one week so that we can spend the second week polishing up the demo for presentation. Personally, I’ll be coding some architecture in ActionScript 3 as a core for our programmers to collaborate their code within.
I’ve come to enjoy the Scrum method of development over the more traditional Waterfall system. The weekly or bi-monthly sprint system allows for much more design freedom, wiggle room for development roadblocks, and the ability to change decisions on the fly. On the other hand, planning the entire game’s development cycle ahead of time does solidify the plan for the game in each team member’s mind so that there isn’t any confusion during development, where I’ve found with Scrum not everyone is on the same page with the design of the game as a whole because we are so focused on each individual mechanic during each respective sprint. The issues will clear themselves up as development continues, and of course it’s my job as Project Owner to ensure that everyone is on the same page with the game design, so I need to reflect and learn from my mistakes in order to ensure that my team understands my intentions as a designer so that there’s no confusion while development is ongoing.
That’s all for this week, thanks for reading!