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.

Kinect Gardening Conclusion...or is it?

This week capped off the second prototype for the class and a great four week run. To get things started, here's the gameplay video for Kinect Gardening:

The prototype turned out great, and we barely had to cut any features (really just calibrating, somewhat unnecessary for the prototype). In fact, we even had time to add an additional feature, the gopher, at the end. All in all, things went smoothly throughout. The one minor set back towards the end was having to create a trailer and a presentation without the final art. Unfortunately, it just got done a little late. It made it into the final prototype, but not the presentation. As an artist, I'm sure Alice really wanted people to see all of her work, and I feel pretty bad about the entire thing. Definitely something to keep in mind in the future. Working on something and not having it shown to people can be pretty rough.

On the other hand, I think the project went incredibly smoothly and everyone was pretty happy with the end results, the client included. It was difficult to come up with negative things for the postmortem, but there are always things that don't quite work out. Here is the postmortem timeline:

Fairly sparse on the bottom, but we had some good discussion. I once again championed pair programming and the use of scrum. As a producer, these two tools were immensely helpful. We'll see about that in future projects.

I also changed up the one-sheet format a little bit, and I'm pretty happy with the results. Check it out:

Overall, it's somewhat of a mishmash of the first one sheet I used, based off of some resources I found online, and the template that another producer, Brianne, came up with. I like that it still has a decent amount of information, but also has a nice design to it as well. We'll see Monday how everyone else liked it.

On an incredibly positive note, Stacy seemed very excited about the prototype, and immediately asked if we would be interested in continuing our work should funding be secured. Every time we make a prototype we're hoping to get some work with it, and this seems very promising. Stacy is going to show the physical therapist she works with the demo, and try to secure some funding from there. If we could swing some research assistantships out of the deal, that would be great. Of course, a simple pay-for-work deal would also be great. Hopefully we hear some more soon from her. I plan on staying in touch and keeping my finger on the pulse of this.

Now all that's left is next week's prototype...and then the next prototype..and then a thesis project...and then an internship, etc. Piece of cake right? I'm looking forward to next week.

Week 3/Fall Break and Everything's Fine!

So week 3 went by pretty quickly. We're getting our work done, and the scrum process is going well. Alice has been doing great work with the art assets, and she's really digging in to the scrum process. As long as she has work on there she'll do it, and the work has been turning out great.

I've been keeping busy with audio work. I haven't really messed with sound design too much previously, and I possess a rudimentary amount of knowledge of audio and music in general. However, given my constraints, I think the audio turned out decent. It's really there to just add another layer of sensory input (input to the player not for the game), and since this is a prototype, if the audio isn't top-notch that's okay. I think it comes down to the fact that it's just nice to hear something while playing the prototype, and never underestimate the amount of  feedback from sound effects and how important it is to the player. This may be something I'd like to look at in the future a little more in-depth. I have some technical skill, but I usually just get in the way of the engineers, and I have no traditional art skills to speak of. But I enjoy audio, and this seems like a way to contribute concretely (and not just process and management) that most of the other students here have little to no experience with either.

Speaking of engineers, the pair programming work of our two engineers is turning out great. They sit down, work together, and just get things done with very little time spent debugging simple errors. Honestly, it's blown me away a bit with how effective a technique it is. I'll be recommending this technique for future projects without a doubt. However, I'm sure there are a few things to keep in mind. These two engineers specifically asked about working together to pair program. This implies they were at least on friendly terms beforehand, and that both were looking to give this technique a shot. They also have personalities that don't clash. As a group, we only have two engineers, since we have an artist. If my future groups have 3 engineers, pair programming might just get in the way, or it may seem like we're playing favorites. So there are lots of constraints, but I'll still recommend it in the future for anyone who wants to give it a shot. A side effect of this in a small group is that code dependencies are pretty much nonexistent. Estimation was difficult, but we actually hit most of our estimates, or adjusted to make things work. For instance, we dropped calibration since we can fake it pretty well. Overall the game is intact, the motion is fun, and it displays the basic game loop.

Right now we're looking at one more day of work, a short gameplay video demo, and making a wrap kit. The dry run went well, and we ironed out a few kinks, like trying to run a live gameplay demo (which worked okay, but I agree with the feedback that a video might work just as well and is easier to show to others).

Project Two, Weeks 1 and 2 get!

Weeks one and two went by pretty quickly for our next project. So, getting down to business, our team is:

• Myself - producer
• Alice Owens - artist
• Jason Thummel - engineer
• Jason Kanagaratnam - engineer

We are part of the 3 groups that were chosen to work on the educational games (as opposed to the TreadPort physical therapy games). Oddly enough, we actually chose a physical therapy game to work on! Stacy Bamberg is a professor on campus working in the bioengineering department on a few projects involving physical therapy for stroke victims. Out of the two presented projects, my team and I decided on the Kinect game for arm range of movement therapy. Initially, we were going back and forth from this to the thermodynamics game presented by another professor, but we eventually decided on this due to the excitement of working with Kinect.

Quite honestly, I pushed fairly hard for the Kinect game as I recently had a close family member suffer through a stroke and the rehabilitation required afterwards. I just thought how great it would be do to something to help people through that process. Seeing it first hand really showed how difficult it is to stay motivated and to keep watch on the patient's progress. Progress is slow, and having a visual way to display to the patient/player the improvement he/she is making and an engaging method of encouraging therapy could be so important to the well-being of the patient. To be a little selfish, the family member who suffered a stroke has done so much for me growing up that I couldn't help but jump at the chance to give back to him in a meaningful way. On the other hand, I thought it would be interesting, and motivating, to be personally invested in a project like this.

The team went through myriad design ideas before we came to our current gardening concept. Since a somewhat simple game had already been developed for this, we at first thought of ways to basically skin the same concept with things like bingo, mazes, or word-finds. That just seemed too simple and too boring still. That's when we came up with the idea of some sort of consistent narrative arc, albeit simple, tying the separate levels together. For me, gardening immediately sprang to mind. There are many stages of gardening, from tilling the soil to harvesting your fruits, that we could design multiple stages easily. Combined with a sort of narrative (watching your garden grow) that keeps the player engaged from level to level, we hoped to engage the player with the outdoors aesthetic as well. Since most physical therapy is done indoors in sterile environments, we hope that this aesthetic allows the player to escape the sterile hallway if even just a little.

From there we hammered out some details, involving figuring out how to perform the actions with the Kinect, what levels to use, how to work in breaks, and how to bring players back to do more physical therapy. I made a short video of our initial pitch (unfortunately with no audio) that should give a basic understanding of our original concept.

From here we got to work immediately, scrumming out our project and deciding on what to prototype and what to leave out. Below is a thumbnail showing the basic layout of our task pane for our scrum. Click on the picture to actually check out the scrum, and be sure to check out the different tabs at the bottom!

As we moved past pre-production and entered into our first week of working on the game itself, things have been coming together quite nicely. The engineers have been working hard pair programming. At first I thought this would create some issues with scheduling tasks and estimating hours, but it has actually gone quite smoothly. They've been churning out excellent work, and since both of our engineers have been working together, there hasn't been any conflict regarding duplicate work or people waiting on prerequisite features to be completed. Our artist Alice has really embraced the scrum process and has been super productive. As for me, I've been scrambling to keep up with their work flow a bit, and trying to learn a little about audio so we can add sound effects and background music. This seems relatively simple to code in XNA, but my utter lack of sound design knowledge might hold me back a bit. I'm going to keep trying to get that done, and we may actually get to add some more features into our prototype given our rate of completion. Our estimates may have been too high. That's not a problem though (or should I say if you're going to have a problem, this is the best kind to have) as we'll just add some of the features we took out and use that time to polish the levels. Things are looking promising, and by next week we should have a mostly complete prototype.

Pitch and Postmortem (with video!)

We wrapped up this week with, what we felt, was a successful pitch. Monday's pitch felt a little flat, so we went and improved on a few of its deficits over the next couple days. In the end, our game showed much better in prototype then it did during the initial pitch, which is something I need to work on (more on that below). However, without further ado, here is the trailer I cut together for our game:

Afterwards we held a postmortem to ascertain where we ended up. Here's how our timeline ended up:

It takes a fairly obvious shape (almost a sine wave) when you think about it: hitting a few lows before achieving a decent number of highs. It also turns out I learned a few things talking about the project. Something I thought we did very well with (and the rest of the team agreed) was our design meetings. Design needs to be done quick in this format, but we all felt that we were able to be flexible, compromise, and combine our respective ideas in something that was tailored to the client. No one felt like they were slighted by design decisions or left out of the loop. Our Facebook group probably went a long way in helping communication, especially early on when we weren't sure who had texting or a chat client.

After the design highs we hit a few lows. Looking back, we all severely underestimated the difficulty of the project. Initially, we felt that, at tops, a week would be needed to get the basic prototype together. However, the engineers felt flustered by the lack of documentation for Moai, and it took a week just to get ducks in a row. Something to look at in the future would be to schedule smaller tasks the first week so as to allow the engineers to grow accustomed to the engine and learn some basics while churning out a few easier tasks. This might allow us to prioritize a little better as well. Tasks we thought would take a few hours ended up taking a couple days, so knowing what those are and tackling them early would save some stress later on. As a producer, I definitely need to attack issues with art outsourcing (or sound outsourcing) earlier. It seemed like I would have plenty of time to get some things done, but there were always unexpected road blocks. It turned out alright this time, but next time it might not, and having a few extra days to get things in order might make all the difference.

Towards the end, everything came together. We got things we needed done as the engineers worked with a better understanding of the engine, and art finally came together thanks to Sagar. I made an initial pitch that swung far too plain on the pendulum, but came back pretty well (with the help of the team) for the final pitch on Wednesday. We got a playable demo working, on both pc and iOS. Once we got a firm grasp on the project the last week, while hectic, was much better planned out. In the future, I'll be looking to get that mountain climbed a little earlier. Crunch time isn't fun for anyone.

The last thing I'll say is that I'm sorry to see the team break up. As a first experience, I don't think I could have asked for a better team than Sagar, Triston, and Yuntao. All of them are very capable engineers and good designers. At least now I'll have some engineers to ask for second opinions (and maybe snag some artwork from Sagar if I need to).

Week 3: Setbacks and Hitting Goals

We started week 3 off a little behind. Unfortunately, engineering hitting a couple snags over the long weekend and we didn't quite hit our projections. I went in and reworked the upcoming week's sprint, accounting for extra tasks and re-configuring estimates. We did have to drop a few things into the backlog, but they were all window dressing and not any core gameplay functionality.

As the week went a long, we picked up steam, knocking out tasks fairly quickly. The holiday threw us off a bit as well, but we made up for it by meeting on Tuesday and Thursday for the afternoon. At the end of the week, we had a working prototype that met or exceeded our expectations and didn't drop too much functionality.

Art has been somewhat of an issue. Originally we were looking to outsource to a friend of Triston, but after discussing the ramifications of that we decided to stay in-house. However, by the time I reached Mark to discuss in-house outsourcing, he was in China for a week or so with no internet access. I spoke with Roger, and he passed along an email to his undergrads. As of now, we may be able to grab a couple pieces of concept art from an undergrad I've been in talks with, but given the short notice, understandably, I'm not expecting him to be able to produce anything. We did manage to get a couple pieces of customer art together thanks to Sagar, and it seems that those will be plenty sufficient if all else fails.

With time running out, our team managed to keep cool, get the work done, and turn out a quality prototype in the face of a few setbacks. The team did great, and if everything goes according to plan, our work should reflect this. Pitches are this week, and we have a fair understanding of what's expected. Hopefully all goes well and we can actually produce a fully realized game.

Week Two, Going Strong

Week two is just about over, and the project is going well. A couple set backs with outsourcing, but we made a little headway. Thursday was our planned meeting day with Triston's friend regarding some outsourced sound, but due to the extreme nature of parking on campus during a football game, we had to reschedule. We also ran into some issues with getting sound into our game using Moai. According to the engineers, it requires a decent amount of legwork to get operational. Even if we don't get sound into the prototype, we could always show a video of the prototype and just add sound in video post-production. Another team is also working on sound, and we're hoping to combine our collective knowledge and maybe cobble something together.

In regards to outsourcing, I've found the Creative Commons license to be an excellent resource, especially for a prototype. The Creative Commons website is easy to use and gets the user a license in a few minutes. The license is easily configurable and allows for a decent amount of customization. We will be looking into some concept art outsourcing this week, but that will be through the University. Unfortunately, Labor Day is setting that back a bit, but our team is meeting Tuesday to do some work anyway, which will be a great opportunity to figure out the art outsourcing.

By Tuesday the team should have a pretty decent working prototype. It does look like programmer art and white boxes will be the de facto aesthetic for our prototype. We're okay with that though. It is a prototype, and we don't have an artist easily accessible. That should complete the first sprint in our scrum, which I created last week. The second sprint is mostly user interface, and if our estimates are correct, we should have a little extra time to tidy things up and maybe add a start screen (or work on sound).

To get started with the scrum process I used a spreadsheet in Google docs. Mostly it was creating user stories and sprints, and putting that information into a visually discernible format. It was also pretty easy to create a burndown chart. Although with a 2-3 week project a burndown chart feels a bit overkill. It was good for the practice though, and it can't hurt the project. Overall, I think the scrum documentation turned out well, and next week we will actually get into using it to assign work.

Going into the last full week of work (and being halfway done), I'm feeling good about the project. Everything is on schedule and the engineers are getting even better with Lua and the Moai engine.