Week 3: Technical Difficulties

This week, we encountered some unexpected difficulties that threw off our progress.  First, our original second idea, Mage-Man, or whatever temporary title we were using at the time, was met with a deservedly negative response.  While we may have created a fascinating context, the actual game was derivative in its structure and mechanics, playing out like some bizarre combination of Mega Man and Castle Crashers.  That's not what a capstone project should be about.  Our efforts should be focused first and foremost on making something interesting to play, something that is mechanically fun.

We tossed around some ideas during our meetings.  I suggested an old concept I prototyped three years ago, a two-person "dungeon crawler" action game, the twist being that the two players share a single controller.  We explored this for a while, but the resulting ideas were not particularly cohesive.  So until the end of the week, we drifted, working on Nuclear Armageddon while not having a clear backup plan.

At the end of the week, I brought up an old idea of mine, one in which the player uses the corpses of their past lives as puzzle solving tools.  The player might jump into a spike pit, die, then use that corpse as a platform to get across the spike pit.  The circumstances of their death in one life affect the properties of their corpse in their next life.  If the player lights themselves on fire, their corpse might give off a pillar of smoke, which the player might use a lift to get onto higher platforms.  What keeps this from being a single-screen, Flash-level puzzle platformer is the focus on exploration.  This mechanic take place in the larger context of environment navigation, puzzle solving, and occasional combat.

The team was surprisingly enthusiastic about this idea, and we discussed all sorts of concepts for it during our end-of-sprint meeting/dinner.  This idea is a much more likely candidate for a capstone game; it's interesting from a mechanical standpoint first.  The macabre main mechanic can be used to extrapolate all sorts of interesting contexts and stories, something for which John Cotto, one of the designers, and I share a passion, but first and foremost, it has an interesting gameplay concept.  I look forward to finally getting feedback on this idea.

I mentioned we encountered some unexpected difficulties.  The second difficulty was discovered while trying to prototype Nuclear Armageddon in Adobe AIR.  I realized while programming some of the logic that my particular setup in BeauSWFMobile was meant for much simpler games than what we're making.  Not only that, but the workflow is actually less convenient than I remember.  While we still intend to use MonoGame in the future, we have decided to switch back to Unity for prototyping.  I'm honestly not really sure why I thought AIR would be a better platform for prototyping in the first place.  While I've technically worked with Adobe AIR for longer than I've worked with Unity, Unity is much fresher in my mind and has a workflow closer to our target workflow for MonoGame.

With that in mind, I switched back over to Unity, which set us back a bit in terms of getting a playable prototype.  This has been a great lesson for me in not finalizing my plans before I begin programming.  Had I not solidly declared our intent to use Adobe AIR last week, I could have saved myself a lot of embarrassment.  I suppose now is the time to figure out what doesn't work, though; it's better to have switched now than six weeks down the road.