First off, the most important thing that we decided on during this week was that we were going to drop Thievery. We brought the idea to our class and we quickly learned through feedback just how out of scope Thievery was.
The idea of the game was a competitive stealth game in which the players tried to steal more than the other players while trying to alert the guards of each others' position through things like Smoke Bombs, Tripwires, and other distractions. The main problem that came up was that it is hard to have a stealth game where the players interact meaningfully and often with each other. From a design standpoint, this left the idea of the game in a state where it was very, very, very hit or miss. And we felt that the these problems plus the scope from both an environmental art standpoint and AI programming standpoint made this game undesirable in terms of viability within scope.
Then we made a further mistake.
So, we decided part way through that we were dropping Thievery. But, the tasks and story of it were already in our Sprint. We were far too afraid of two looming words - "Sprint Fail." Because of that, we worked on a Thievery prototype despite the fact that we were going to drop it when we could have instead replaced that prototype with something that would have likely been more useful.
This did frustrate me in particular because I had decided to take on this prototype, and I felt like I was creating something that was pretty pointless. But, rather than stay frustrated, I tried to figure out what we could do with the prototype to make it useful. And so, I ended up making it so that the different abilities and items the player had had multiple functions. For example, I made it so that the tripwire costed treasure (the points within the game) to make it so that the treasure had multiple purposes: adding up to your final points or possibly causing another player to lose points. I also made it so that the Smoke Bomb made it so guards couldn't walk through it, however guards would still be attracted to the smoke bomb, making it so that you could use it defensively for yourself or on opponents to attract guards to their location. I did this to get some feedback on items with multiple uses, which could be useful in both of our other game ideas. For the game where you take the remains of robots and attach them to yourself to augment yourself, some of the items the player picks up could have multiple uses. For the game where monsters fuse together upon death, the player can have abilities with multiple uses rather than just the usual combat system.
Of course, though, by the end of the Sprint we realized we shouldn't have been as afraid of Sprint Fail. We learned that while 100% finishing the Sprint may be the goal, not doing so isn't truly a failure. Plans change throughout a Sprint. That's the whole point of Agile Scrum Development and these Sprints and Milestones.
Comments