Post Playtesting

Although all of these post are about programming and design, I also do the project management and some of the leadership type roles for Spring It.  Now that our first major playtest session has completed I decided to write this post about both of these roles.  We received a lot of feedback from friends regarding the game.  We had most people fill out a google form and the results were compiled into an excel sheet for us to look at.  A few of our friends wrote out their experiences in paragraph form in the style of a play by play.  We had largely positive feedback with the major complaints being bugs, a desire to know performance at the end of a level, and more motivation to play each level. 

At this point, we took a step back to revamp our overall design.  Our GDD was desperately in need of an update because our design had changed so much from our original.  We knew we had a good grasp of how each level would play and where the fun was.  We needed to more effectively hone in on this fun as well as create the over aching system of how all the levels will progress and connect to each other.  We knew we needed a summary screen, and we needed each level to unlock the next.  We also needed each "block" of levels to unlock the next block.  But we had not really decided how the player could lose at our game.  Being a puzzle game, losing just means you have to try the puzzle again by restarting the puzzle, but levels already have a built in reset system.  The player places tools, starts the assembly line, and tweaks it as robots progress down the line, when they need to make major changes, the reset the scene and stop the robots.  After brainstorming many ideas, we settled on changing the system so one robot spawns at a time, and the player only receives a set number of robots before the entire level resets completely, this makes each robot worth more to the player and has them thinking about their placement before starting the assembly line.

Great, we have a way for players to lose.  Next we needed to determine how each "block" or levels is unlocked and how many levels a block contains.  We wanted the first block to introduce the core mechanics that we have in our playtest build.  We settled on allowing the player to choose from two new mechanic blocks, bumpers and magnets.  When they unlock one, the other one locks and then requires more "stars", or whatever we decide to use, than the original unlock.  After the player completes both mechanic's blocks,  a block combining the two new mechanics.  This structure would be our goal for the remainder of the game.

After hashing all of these details out, we finally had a clear scope for the remainder of the game.  up until now there had been a lot of changes to mechanics and even more  changes to the art style.  To spare us the wasted work, we wanted a unified agreement from everyone for the final art style.  Before we could start sprinting again, I needed to rewrite our entire product backlog from scratch.  To assist me in this task, I rewrote the GDD with all of our updates to give me a clear idea of everything we still needed..  Next, I set to writing the new product backlog.  Since I still have incomplete information about how long the art will take, I only filled in the art tasks I knew of and left  " Define New Art Style" as our highest priority item.  Previously, the backlog only had priority and task name, but because we finally gave ourselves a time limit for this game (End of the Year), I added a third column rating the time each task will take.  This means I can finally predict what we will have time for.  So with these changes, we restarted our sprinting last week.  As an added benefit our game is a more modular system which we can add new mechanics onto freely.

We will be watching how our new changes feel to the designer, the scope of our art style, and I will be pushing to plan for our next playtest. (Sorry for the lack of pictures so here is a screen shot of our newest sprint and product backlog)