Project 3 Post Mortem: Shoshone

This project got off to a pretty rocky start.  Our task was to create a game that helped teach Shoshone children their language and culture in an effort to prevent it from dying out.  The caveat however is the clients naturally wanted something fun, and language games ain't fun.  The initial idea was a collection of minigames on the facebooks tied together by some Ville style overworld.  The minigame collection idea persisted throughout the entire project, but the overworld went through some pretty dramatic changes.  Eventually we just settled on a large explorable area with various hidden things and minigames to discover.

Once we settled on an idea and our producer got over his fear of potentially offending the Shoshone people... well somewhat got over his fear, everything went pretty smoothly.  This is the first project I've ever worked on where I had very little communication with my fellow engineer about the actual coding process and it worked out fine.  He was in charge of making the overworld and I was in charge of developing two minigames.  He did his job, I sent him mine and he integrated them into the game.  Our artist was kind of MIA most of the development cycle, but he was very good about steering the game in a certain direction and getting art assets to us in time.  Well, in time is up for debate, but I felt we had enough time to get everything in there, after all, it all did get in there.

Because of the scope of this project, we actually had the ability to iterate on our prototypes, which was kind of neat.  I went through about four reasonably different versions of the hunting game before deciding on the final version we presented, and the overworld as I mentioned above, while only being prototyped once was overhauled multiple times.  The fighting game was more of a wash because programming fighting mechanics, much less enemy fighting AI was completely new territory for me.  It ended up being fun, but pretty mundane once you realize what you actually have to do to win.  It definitely still needs a little work.

Overall the project went smoothly, no real complaints.

Week 11

So we've changed up the hunting game even more now.  I'd document the whole process with pictures, but I'm lazy.  It changed pretty dramatically though, we went from a Galaga clone, to a weird off skewed to the left board where you had to aim your shots at static targets based on some under the hood trig functions I came up with (it was really just tangent).  Then we decided to let the enemies move, but you only get one shot at maximizing your score, that coupled with the new angle aiming mechanic meant your best bet was to just spam the buffalo over and over since he was worth the most points.  So now we have them run forever, made the buffalo a little faster and you only get 20 arrows.  It's pretty too, if you adjust your aiming angle far enough it almost looks like the archer snaps his spine.

We also changed up the overworld quite a bit, but most of that was all talk and no implementation.  We went from a CastleVille style world to some other stuff to finally just a simple world to tie the mini games together that is fun to explore.  I'm not sure how fun it is to really wander yet since we just barely got the final art, but it should be good.

The bear fight on the other had hasn't gotten very far in terms of iteration.  At first you could just attack if you go in range and then I added a jump that does little.  Ideally I'd like to make it so a jump attack does more damage and jumping is a way to dodge an attack.  Still though, its a very basic fighting game.  I'm not really sure how to do better AI right now and a few week prototype is not a great time to learn something complicated like that.  I might add a Hadouken style move if I have time, but I don't think I will.

Overall, I think it came together rather well.  With enough mini games and a big enough world it'd probably be a fun game to mess around with.

HTML5 on the other hand doesn't even remotely live up to the hype.  It's pretty cool for web design I suppose, but it doesn't seem that different than HTML4.  As far as game development goes though it seems incredibly hamfisted.  Like someone at W3 was just like, oh, if we do this we could probably make games that run in the browser.  Then everyone immediately dropped their jaws to the floor and figured out how to shitrig it all together.  There also seems to be a billion ways to build a game with it, every team appears to have picked a different framework or library.  Hell, I even experimented with more than one.  We ended up settling on just basic CSS and manipulation with JQuery.  It's gross and I hate it.  Also, it seems kinda slow, but for our purposes it does not matter.

Week 10, Iterate!

As I may have mentioned before, for this prototype we decided to focus more on iteration than presentation.  I'm not entirely sure what that is going to mean for our presentation and I feel bad for AJ who has to present what we've accomplished to the Shoshone guys, but whatever.  It's a prototyping class, not a sell your half baked and barely duct taped together, but shiny game idea class.

Since our game idea is really just a collection of mini games tied together by a fairly basic overworld, we figured we could pick a couple mini game ideas and iterate on them.  This week I built two fairly different versions of a hunting mini game using completely different toolsets.  One is a Galaga style shooting game where buffalo (aka neon green rectangles) rush across the screen.  I made it using a javascript library called Crafty that has some fantastic game building blocks and pretty much no instructions on how to use them.  This caused a fun little bug to occur since I had to shit rig the collision detection.  If you manage to graze the head of the buffalo your arrow continues onward potentially allowing you to get a second kill or even third kill.  I like to think of it as multiple headshots.  It's not a bug, its a feature!

For the second iteration we decided we'd make aiming a little more challenging and a tad more like a real bow.  Now not only can you aim side to side by walking, but you must adjust your angle for distance.  Since the adjustments take more time we decided to keep the animals static this time around.  I wrote this version of the game in just straight HTML5 and I can safely say I hate it.  I take that back, I used JQuery for all my javascript needs, but I don't take back the hate it part.  It seems like the standard way to draw objects to the screen in HTML5 is with CSS, which makes sense because its designed for displaying websites.  Seems really cumbersome when you are trying to change CSS attributes dozens of times a second to animate stuff on a screen though.  I wonder if Crafty was doing something similar and just abstracting that away from me.  I'll have to peruse the source code.

Which brings me to another topic.  You can't hide your source code in HTML5 at all because everything you write has to be parsed and rendered by the browser.  Seems to mean everything you make is open source whether you want it to be or not.

Anyway, next week we're gonna get started on the Bear fighting mini game, hurrah!

Week 9, Design stuff

I'm not sure why I'm so terrible counting up by 1, but I think I got my post titles sorted now.  Also, I should have written this last week, but whatever.

So this week we had to come up with our third game prototype idea.  We have to develop a game to help preserve the Shoshone language, which has caused quite the stir within the cohort.  First of all to start, everyone during our Design class this Wednesday simultaneously decided the way things were going weren't exactly how we wanted them to be.  To remedy this most of the groups are taking a more iterative approach to the prototype and less of a finished product to pitch type approach.  The way my group is doing that is by keeping the scope smaller so there is more time to iterate and possibly still make the game look decent for the pitch.

That said, our game underwent several major design changes before a line of code was ever written this week.  Everybody pitched a similar Zelda-esque adventure game idea that loosely teaches the Shoshone language and culture simultaneously, which is part of what caused the controversy.  Everyone is worried about potentially offending the Shoshone with the game, meanwhile Roger has been insistent we all artificially added the burden of teaching Shoshone culture.  All the client asks of us is a fun game that teaches Shoshone, be it robots fighting lizards in space or whatever.

Long story short, I think we all are sticking to our guns and including culture into the game.  Our game is going to be a series of mini games tied together by a top down semi open world environment that the player can explore to discover said mini games among other things.  Should be a good time and easy enough to implement that we can iterate.  We shall see.

Project 2 Post Mortem - Kinect Gardening

It's kind of hard to write a post-mortem when nothing really goes wrong on the project.  When we all filled out post-its and put them on the board, we all struggled to come up with anything negative.  The biggest hurdle we faced while developing this prototype was making the Kinect behave nicely.  I got the base functionality working rather quickly, but like I'm sure I said in an earlier post, it's very easy to get the Kinect working, but very difficult to get it to work well.  When we had a bit of time to spare, we spent several hours experimenting with and tweaking the Kinect controls.  In the end however, we decided we were only making it worse and figured we'd put some serious manpower behind it if it got picked up by the client.  It functioned well enough for a prototype, and we had mouse functionality built in as well.

The only other issue was some of the final art was delivered so late that it didn't make it into the final presentation.  It did however make it into the final prototype, so it was hardly a big deal.

I guess we should focus on the good then.  Imaginary Jason and I decided to use pair programming for almost the entirety of the prototype and I think it worked very well.  The basic structure of the design came together very quickly, because he was well-versed in XNA from a previous project and I had dabbled in it a bit before.  Our memories were both incomplete, but together we knew enough to bust out every feature quickly.  We also benefited greatly by being there to keep each other on task during class time.  Typically anytime someone would come up to me and start talking I'd lose all sense of workflow and progress would halt for awhile.  With both of us there, we tended to just ignore distractions.  I don't think pair programming is the best solution for most situations, but it definitely has its uses.

I'm sure Bob would agree, I remember your talk!

Anyway, like I said, all in all it was a very successful project and I enjoyed working with Jason, Alice and Mike.  We were way more focused than the last group while still remaining very laid back and casual.  Good stuff.

Week 8

Well this might be slightly late, but whatever.  The prototype was more or less working by this point in the process, so we just added a few extra features we thought we wouldn't have time for.  Mainly a little whack-a-mole mini game that ended up being quite easy to implement.  We also added in all the final art assets as Alice finished them up.  I don't even think I could come up with something interesting to say if I wanted to this week.  It was super straight forward and the presentation went well.  The client is supposedly going to get back to us about potentially making this into a real product, so that'll be cool.

Week 7, Fall Break!

Starts early for the engineers, we don't have none of that Thursday class nonsense.  Anyway, nothing terribly interesting to report this week.  We busted out most of the main features this week.  Still waiting on a bit of art and will probably try to implement a few extra features when we get back.  We spent all day yesterday trying to make the Kinect suck less, but to no avail.  We had a half decent solution, but realized it made it too easy to control and defeated the purpose of making the game for physical therapy purposes.  Also, we didn't have a good way to stop the cursor once it was put in motion.

We might mess with it a bit more later, but I would rather implement features to make the prototype more like a game.

Anyway, catch yah on the other side.

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!!

Week 2

After reading that last blog post I think I should consider proofreading before posting.  There's like 5 typos and I barely wrote two paragraphs.  Ah well, this isn't an English program.  ;)  Anyways, the bulk of my time spent this week was on prototyping our game.  It is coming along and I am becoming more familiar with Moai.  It's an odd framework though, I find its generally easier to do incredibly complicated things like set up 2D physics in Moai, but the simple things like drawing an invisible shape on the screen to use as a hit box is nigh impossible.  Also, the documentation is absolutely miserable so learning anything new is a bit of a crapshoot.  Regardless, progress is being made and the game should be playable in time.

My engineering class is still moving at a crawl.  We spent another 90 minutes just on SVN this week.  I'm pretty sure when I was introduced to version control for the first time we spent significantly less time.  The teacher seems to focus on the small stuff that we should be looking up on our own, because after SVN we spent maybe 20 minutes on preprocessor stuff (the only C++ we've discussed so far) and then for whatever reason we spent the rest of the time reviewing the IEEE standards for encoding primitive data types.  I'm still expecting this class to get difficult in a hurry, but with next Monday off for Labor day, we're going to be a quarter of the way through the semester before it has a chance to ramp up.  I'm guessing within the month my blog posts will turn to rants about how hard that class has gotten, but until then you get to hear me rant about how slow it is.

Finally, I'm still kind of in awe about the fact that Game Design 1 is pretty much us just discussing video games on myriad of levels and yet I'm getting graduate credit for it.  I've always been a big advocate of games as art (though I've given up on caring about whether the rest of society agrees), but I guess a part of society has rubbed off on me and I feel like I'm cheating the academic system.  Which is awesome.

Welp, this post unintentionally ended up exactly like last time.  Maybe next week I'll have an interesting catastrophe to talk about so that whoever is reading this actually wants to rather than has too.  No guarantees though, still not an English major.

EAE Start!

So after spending an entire week in grad school for game development I think I can safely say we have hit the ground running.  Game Project 1 requires us to rapidly prototype a game every four weeks using a different set of developer tools each time.  This week it's a framework called Moai that I'm pretty sure was chosen only because Tim Schafer endorses it.  Ironically, every single thing I have read about Moai suggests you only use their software if you are not a beginner to game development and if you have time to get over its steep learning.  Naturally, we are all beginners and have less than four weeks to learn and prototype a game, but whatever, this is how CS has always been.  Sink or swim, if we put in the hours we should have something reasonable come week four.

The other two classes seem a bit more manageable.  While I have no doubt Game Engineering 1 is about to get real, it is starting off quite slow, which is much appreciated.  The third class should be a lot of fun, seems like a lot of game design theory and stuff like that.

On another note, this is the first time, aside from on the internet, that I've been completely surrounded by people that know as much about video games as I do... if not more.  It should be a fun couple of years.