Week 6, Still Better with Kinect!

So we got the prototype well underway.  It's pretty much FarmVille with Kinect, or at least that's what it seems like.  I've never played any of the Ville's because I didn't do my summer homework for this program.  Well, that's not entirely true, I had already played a large chunk of the games on requirement list and knew about their developers history and what not because that's just the kind of nerd I am.

Anyway, I have decided to amend my statement about Kinect's ease of use.  It's very easy to get something up and running quickly, but it's rather difficult to get it to work well.  Right now we have both Kinect and Mouse input, so we do most of the testing with the mouse, but the Kinect more or less works under fairly ideal conditions.  Whatever, it's a prototype, and the proof of concept is there.  This game is probably more entertaining than whatever physical therapy these guys were originally going to be doing.  I can guarantee you it is more fun than the physical therapy I was doing a couple weeks back for my shattered arm so we can quote me as a satisfied customer when we make up the box art for this thing.

All the non Kinect oriented development has been very straightforward, which is good, because Borderlands 2 came out a bit ago and there be phat lootz to find.  Honestly, there isn't all that much interesting to say about the prototyping process this week.

The engineering class is taking off however, we're learning how to cache align our custom classes this week by overriding the new and delete keywords.  I knew a bit about cache aligning before, but I had no idea you could override the new keyword in C++.  Hell, you can even globally override it for your entire application.  This freaking language seriously gives you too much power, no wonder game designers like it, but holy balls is it a catastrophe of a language.  At least Visual C++ seems a little more coherent.

Week 5 maybe? I dunno, Project 2 start!

So we get to use XNA for this next project, yay!  MOAI can go to hell and not come back until it's properly documented.  Anywho, we got to pick from several potential projects ranging from engineering edutainment to physical therapy with Kinect games.  Since edutainment games generally suck and since thermodynamics is probably the most boring of all the dynamics, we decided to go with the physical therapy game.  That and I really wanted to use my Kinect for something, its just been sitting on my tv not even plugged in for well over a year now.  Just watching me, wanting to be loved.

So early in the week I found some Kinect XNA tutorial blog and successfully got my Kinect to move around and display an image.  It was pretty exciting, you should have been there.  Yesterday though, I figured out how to display the depth stream and the skeletal tracking streams which are way cooler.  Turns out the way Kinect tracks skeletal movement is really simple to use.  Whatever it is doing is probably super complicated, but it just returns a collection of 20 joints to you.  Using the tutorial I was able to map a red circle to each joint and make a sort of marionette puppet that tracks a persons movement.  It ended up being substantially more entertaining than any game I've played on Kinect so far, so that's good.  After that I had pretty much exhausted all the tutorials on the blog I found, it started off so strong, but like most things on the internet, it was only maintained for a month before the author lost interest or whatever.

That's when I started reading the Kinect API and finding all sorts of fun things.  Most importantly which joint was mapped to the right hand... turns out it's called HandRight, solid variable naming on Microsoft's part if I do say so myself.  Once figuring that out and how to use it I was able to limit the red circles that were being drawn to only the one mapped to my right hand.  And thus the prototypes primary form of input was born!

Pretty much everything from here on out should just be straight XNA and collision detection with the cursor. Oh and I should probably make it work with the left hand too I guess.

It's better with Kinect!

Project 1 Post Mortem aka Bees Bitches!

So from the beginning our lovely Bee game was plagued with problems.  Mainly that we were forced to use a fairly new framework with horrible documentation and barely any community.  It was characterized unanimously as a very powerful framework that you should only use if you are not a beginner and have ample time to get over the steep learning curve.  Naturally we didn't have either of those, but like we always do, we went hard to the paint and learned that crap anyway.

Engineering
Once I did a few tutorials things started to come together fairly well, at least for me.  Nikhil spent a solid week and a half learning Lua and Moai, which was fairly aggravating, but once he actually started coding he was fast and produced quality code.  Chunran on the other hand was less helpful.  He did get the initial playable build up and running, but between the massive language barrier and his inexperience with any kind of version control it ended up being more trouble than it was worth to even use him.  When he did try to produce code it was usually buggy and based on old code.  Still, all of this probably could have been avoided if we had better leadership and direction, which brings me to my next point.

Production
So for production, none of us including our producer really knew what it was a producer was supposed to do.  This led to our producer being MIA most of the production cycle without anybody really caring.  We as engineers knew what had to get done and we did it, we didn't need a producer keeping us on track.  Once we got close to the end however, we realized it would probably have been better if we discussed everything with the producer on a more regular basis and kept ourselves on track that way.  This probably could have helped with Chunran being inadvertently cut out of the loop since our producer can speak Chinese among other things.  Ah well, after watching an entire prototype cycle I think we all have a better idea now what a producer can and should do so I’ll know what to expect next time.

Art
We didn't have an artist, so all our art is just jacked from the internet.  It looks pretty enough.  Luckily our producer is pretty good at Photoshop and I used to dabble quite a bit with Fireworks.  Between the two of us we created good enough art to make the prototype look somewhat presentable.  I’m very quickly learning the value of having a myriad of skills.

Conclusion
Overall, despite everything being somewhat problematic, I think it was a very strong learning experience and nobody is really to blame.  Nikhil and I ended up taking over the project and doing most of the work, but as I said above it was just as much our responsibility to speak up when something wasn’t working right as it was for the guys who weren’t working right.  I look forward to the next project with new members and a better understanding of how this stuff is supposed to go down.  Also, XNA, wooooo!

Week 4, MOAI threading, easedrivers and callbacks.

Well that was a fun week.  In my infinite wisdom I chose the same Wednesday our prototypes were due to be in charge of the Game Design lecture.  I was going to do this post on Wednesday morning, but decided I should wait and see how the pitches went.  Turns out all I was gonna write about our pitch will fall into the post mortem I'll probably do tomorrow, so lets talk about something else instead.

How about the last big problem I had to overcome with the prototype?  That sounds good to me.  Basically in our game, once the player collected two or more cheese of the same type in a row it triggered this lovely animation of a logo flying off the screen to the right while shrinking.  It was good stuff, but because MOAI objects don't do anything they say they will, if they say they'll do anything at all, when the animation was triggered the game pretty much shit itself and died.  I spent about 2 days tinkering with it trying to figure out what was wrong and pretty much came to the conclusion that spinlocking the thread the animation was running on was also locking the thread that spawned the animation, which was the main game loop.  That kind of defeats the entire reason to ever thread anything ever, but it's the best conclusion I could come up with after receiving a grand total of zero replies from the ever burgeoning and helpful MOAI community.

Anyways, I tried an alternative solution using MOAIeasedrivers, and ran into the lovely problem that the example code I was going off of was using a method whose name had since been changed, but not updated in any convenient and easy to read place, like perhaps the MOAI documentation.  Instead I found a brief blurb in a "Breaking Updates" article on the MOAI wiki page after a few hours of sporadic googling.  (In an effort to save random googlers the same trouble setLength is now setSpan).  To make a long story short, I spent 3 hours implementing a whole new way of doing the animation to achieve the exact same broken results.  Fantastic!

Finally, I reluctantly tried implementing the animation by daisy chaining callback methods together with an event handler.  The very method an official MOAI tutorial warned me against using due to unnecessary complexity that could be avoided with spinlocking threads and easedrivers.

It worked flawlessly and took less than five minutes to implement...  Thanks for the suggestion, Jon.

Week 3

We have finished week 3 and our first major deadline is approaching.  As of Wednesday our game was nowhere near complete, but it turns out the first 2 weeks progress was very slow compared to everything I was able to implement yesterday.  We now have an objective that is significantly deeper than just collecting cheese.  The cheese is now colored, and worth 10 points, for every consecutively collected cheese of the same color you get a 10 point bonus and you get a cool little animation slamming you in the face with the name of that cheese.  You can also lose now, all that is really left to do is make the enemies do stuff, which would be easy if Nik's last update actually worked.  :)

It's interesting how slow progress is at the start (especially with a new framework/language) and how the last 5 big features of your prototype can come together in a day.  I feel way more confident about where we are now than I was 2 days ago.  Now we just need some basic art and I think the game will actually look somewhat professional.

If you're reading this Kessler, I want an artist on my team for next prototype!!