Final Weeks, Prototype Done, Success

The final two weeks for our third prototype have come and gone, so fast that I forgot to update last week. To answer the cliffhanger from two weeks ago: yes, the playtest was very successful. We could have done more of course. We playtested among our team and came up with a great number of things we liked and didn't, but we could have had some other teams come over and playtest as well. However, that may have given us too many things to do in that final week. We ended up with a number of changes anyway and those kept us busy through the final pitch.

What we discovered in our playtest is that our initial design didn't take into consideration the feedback given to the player and how that affected the dramatic dynamics of the game. If the alignments of the choices weren't made clear to the player after the choice was made, she couldn't understand why her robot was getting nicer or meaner. We ended up adding a lot of user interface elements to make sure the player knew what was happening and how to deal with it. With the encourage and discourage mechanic specifically, we discovered that we needed to display the alignments and push the time the player had to encourage or discourage the robot's actions. This created a really great dramatic tension that drove the gameplay. This worked so well that if we had the time, or were working on this more outside of class, we would seriously consider removing the player's ability to assume direct control of the robot at all. That gameplay loop of letting the robot guess and then encouraging or discouraging to program your robot was very engaging and entertaining, while just selecting answers for the robot was fairly mundane. It felt like just selecting answers would be okay if there was a high level of polish, but the core mechanic itself wasn't very exciting.

After the third week we came back with a dry run and a few things to fix before Wednesday. We ran into some ridiculous tech issues that prevented our gameplay demo from functioning in our dry run. All of the presentations went really long, excluding ours since the gameplay demo was our main attraction, so by the time we pitched again everyone was ready to leave class and we received very little feedback. This made me a bit nervous going into the actual pitch on Wednesday. For the rest of the day the class was taken over by other miscellaneous business regarding degrees and Ubisoft competitions and whatnot so we didn't get much done. On the next day, we figured out what tasks were needed to make sure we had everything perfect (as possible) for Wednesday's pitch. Luckily, even with the crazy schedule and our gameplay demo issues, we were able to get everything ready for the final pitch to the client without a hitch. As a producer I focus on having playable things done, even if the first week is just an avatar walking around, so that attitude helped a lot in regards to always having something to show, even if it's not the final build. Fortunately our final build worked great for the presentation. Speaking of our final presentation, here it is:

And since the gameplay demo is not present in the actual presentation, here is the gameplay demo/trailer (although if you click on the picture in the Gameplay Demo slide in the presentation you will discover it is a link to the below YouTube video, which was my backup backup plan)

The presentation itself went well (I'll find out more tomorrow night in class when we go over all of the presentations). However, I don't think the client was entirely impressed with our game. They were taken by another game that is very clever and interesting (and shall remain nameless). It was a great idea for a great game. For what it's worth, our team was entirely behind our idea. We feel this game excels in places some of the others falter. For instance, we have actual conversations with real facial expressions encompassed in real life situations where these might occur. I'm not entirely sure the other prototypes hit those marks, and my team is really proud of what we accomplished in that regard. I also think the robot AI is a pretty clever way of learning through teaching in a way that isn't just giving the player lessons to tell the robot. To be honest though, my team focused on the process of coming up with a design, using physical prototypes early, moving on to digital prototypes, and then finally iterating a ton. As a team, we did an excellent job following through with our goals for this prototype, and I think everyone on the team is better for it. So we may not have won the hearts and minds of our clients, but we're all better prepared for what's coming up next in our careers, both in class and outside of it.

Well that's a lot of text, so let's break that up even more with a picture. Here's the picture of our postmortem whiteboard:

This time the sticky notes don't make a great curve or anything, but the process was very helpful. I was surprised to hear that some of my teammates hadn't really done an in-depth postmortem in their other groups, so this was a little new to them. So what did we learn?

First off, scrum was kind of a bust. And I agree. It was organized, always available, and had plenty of tasks with estimates which were all color-coded for priority and type of task. And it was completely unnecessary, or at least that's what everyone was feeling. At this point, the scrum process is just too much unnecessary headache for four people. The process is great to follow so that way next semester we can organize having had some experience in agile development. But try as a I might, scrum is too much for these prototypes. For my next group, I'm planning on just using sticky notes and doing it all manually. At this point, instead of refining my Google spreadsheet, I would be better served to just use a scrum program designed for this stuff. But that would be way too much process for four people. So I'm actually scaling it back, and we'll see how that works.

After the issues with scrum though, everyone was really pleased with how it turned out. I chided myself for not having the conversations in on time, but most everything else were either really good things, or things that maybe weren't great but we know how we would fix them for next time. And that's what's important: learning from the postmortem process and figuring out what to do better next time.

The major concern everyone had, and as the prototype process has continued to be refined by everyone in the class this has come up a few places, was the lack of an actual design document. Previously my groups didn't ever need one. We communicated so well and the projects were so well scoped that everyone knew what was needed from them, especially with the scrum document to back it all up. During this prototype, we basically took notes and used pictures for our design document, combined with the scrum spreadsheet of course. However, the entire team, myself included, expressed a desire to use a design document next time. Combined with the idea that I'll be scaling back the scrum spreadsheet to sticky notes, this seems like the perfect time to start a design document for our next prototype. I have a couple of avenues I'm looking down in regards to how to set this up and what to actually use, but I haven't decided on one yet. Tomorrow I'll discuss with my new team what they think will fit them best, and we'll go from there.

See you next time.