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).