Games are kinda pointless, by their very definition sometimes, but they're also culturally substantial. So I'm going to ramble on about designing, creating, and playing them.
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.
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).
