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.
Showing posts with label Kinect Gardening. Show all posts
Showing posts with label Kinect Gardening. Show all posts
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).
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.
