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.

A new project, a new approach, a new outcome (?)

The first couple weeks have come and gone, and my new group has been hammering away. First off, my new teammates are:

• Sherly Yunita
• Cody Hansen
• Saurabh Pendse

The game idea pitched to us was that of a game to help autistic youths learn conversation patterns and social queues. A few ideas were tossed around, but we initially decided on a conversation game, such as Phoenix Wright or the conversation portions of Mass Effect. However, after some thought and deliberation, we brainstormed some more and came up with a rudimentary AI that the player would "program" through answering and correcting the AI's answers. Here is the initial pitch (this time with slideshare and not a YouTube video):

So why is this project different? Well, to start we used a physical prototype very early to figure out some of the more basic design issues. I cannot stress enough how helpful this process was. The group sat down in front of a white board, drew the game UI and we all walked through different game scenarios we were expecting to perform in the digital prototype. We did this during our second class as a group, and it helped to suss out so many issues we would have encountered very early into the digital prototype. Since we did this, we could get to the issue of "fun" in the prototype more quickly and more easily. Afterwards, we made up a scrum document (in google docs/drive again), and that can be seen here (click on the picture to check out the scrum doc):

The scrum didn't change a whole lot from the last group, but we did decide on a few things. First, we added a priority to each task. We also made tasks that were a little larger, so all of those one hour tasks that actually took 20 minutes would be weeded out. The biggest change was to make sprints for just two weeks, and to not actually create the second sprint until the first was over. This was mostly due to the plan of having and playing the digital prototype after our first week.

The entire idea of this new approach was to actually prototype multiple times and adjust the game until we hit on something that was fun. Most of us in this projects class, myself and my teams included, didn't actually get to prototype. We made cool, vertical slices of games that looked pretty and sold well to a potential client. And that was a good experience. But to be honest with myself, I love designing and I want to prototype. And I think a lot of other students have the same feeling. This time we're doing it differently. We made the plan to have a digital prototype done by the third Monday in the cycle, and we got it done. More on that playtest (and if it worked) next time.