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!