Post-mortem: Flappy Monster

Posted by
August 28th, 2015 1:55 pm

Flappy Monster is a nod to helicopter-in-a-cave style flight games, and turns them sideways. More popularly known as “Flappy Bird” games, the thrust/gravity/navigation mechanic has been around for a while. In my twist, I gave the monster ineffectual wings. Flapping makes him angry (because he can’t fly) so he runs, runs faster, through buildings and forts of humans civilization who desperately lay down sharp pikes to stop him.

WHAT WENT WRONG

Idea waffling

I start each game jam by walking the dog and talking to myself like a weirdo. I run through the possible interpretations of the theme, what I think others might do, and how I might distinguish myself. When I get back, I have a drink (this time it was Remy cognac), sit on the porch, smoke a cigar and brainstorm. Normally by the end of the evening I have several ideas fleshed out and I’ve at least picked one, with the core mechanics designed. But this time, I was flustered, and was waffling between two ideas until 4AM.

The first idea was an homage to The Thing where you were accused of being the monster (but not actually). It was somewhat a logic game, where you knew little facts about the other people that clued you into who was the monster. Anyone left alone with the monster could become infected, and then you had two monsters. You assigned characters to do tasks which revealed more clues about who’s the monster. Characters would have trust levels with each other, making this task harder, and ultimately putting suspicion upon you, perhaps leading you to becoming infected yourself. I loved the idea, but I spent hours researching logic puzzle design and failed to nail down precise core mechanics.

The other idea was a chasing game. People thought you were a monster and chased you, and you responded nonviolently. If they grabbed you, they held you in place until you shrugged them off. If you stayed held long enough (perhaps because several people grabbed you), your health would begin to drop. The twist was when your health reached a lower threshold, you’d explode with rage, killing everyone on the map. So ultimately you are the monster (albeit provoked), and your goal is to survive long enough. I eventually settled on this idea, but I was still analyzing mechanics in the morning, trying to figure out how to make the chase exciting. Ultimately when it got to noon, I acknowledged that this design had too many issues and no time to work on them.

I came up with the Flappy Monster idea as an alternative, as something I thought I could build with the time remaining.

Poor prep

I generally code Haxe using the Sublime 3 text editor. It’s not an IDE. It has support for templates but I don’t use them. It has support for completion, code style, and shortcuts using the Clemos Haxe Bundle but I had trouble getting it working properly and stopped using it a while ago.

Under the hood, Flaxen uses Ash-Haxe as an entity-component system. The benefits of this system are only realized if you actually use systems and components to address states and behaviors in your game. These things require some boilerplate code. Not a lot, but when I’m coding under the gun, the extra minute it takes to set up this boilerplate and locate the file in the appropriate location seems like forever.

So instead I start hacking. The code base gets ugly, cluttered, and hard to extend very quickly, and by the end of the 48 hours I’m fighting kode krud in my desperate attempt to cram in one more feature. Next time I’ll put together some templates and macros to make this process quicker, and keep me leveraging the ECS.

Also, I had little practice with Spriter. While I love the ability to do custom animations in it, it’s a buggy and very quirky app. Between Spriter and TexturePacker, I was trying to discover an efficient art pipeline that wouldn’t drive me nuts. In the end, I barely escaped a Lovecraftian descent into insanity. Seriously Spriter, I have to enter my custom rect every time? You can’t save that shit in the scml file? Jerk.

Ran out of time

This “what went wrong” is always on my post-mortem list. And every time it’s my fault. Because I know I have 48 hours and only 48 hours to make a game, yet I “blow the time budget” at various points. I have to be more ruthless in my time management. Unknowns are a killer and a time sink, so prepare as much as possible, and if the design is not coming together quickly – ditch it!

As one gets to the end of the deadline, things stop dropping off your to-do list in favor of more critical priorities. In my case music and more special effects never happened. And the game would have benefited immensely from another hour of playtesting and tweaking. But that’s alway the case!

Users complained that the pikes were hard to see, the difficulty was brutal, the RNG was unfair, and the monster took too long to slow down. All true, my friends, all true.

WHAT WENT RIGHT

Knowing when to scrap a bad plan

I’m glad I switched ideas.

The chase game was still stuck in design, and I’ve been bitten before jumping into development without thoroughly understood gameplay. The idea I came up with was a twist on Flappy Bird, placing it on its side. Instead of flapping for height, you flapped for running speed. Instead of the “height” of a hurdle to get over, buildings of different sizes required a minimum speed to run through (or you get knocked back and your game ends). And to simulate a “roof” to duck under, I added pikes in the ground that you could only tiptoe through; if you ran too fast, you’d trip and get impaled.

It’s a decent twist. It doesn’t quite provide the same depth of experience as a flying game. For example, when flying you may have to fall half way down the screen, but in Flappy Monster (where the running speed correlates to flying height) there are no pikes that require a max of “half” speed. All pikes require you to go pretty slowly, so as a result pikes right before buildings can be quite punishing.

Completed!

Out of 9 Ludum Dares, I’ve completed 6. That’s a terrible stat that shows I have persistent issues with time management. In some cases I’ve hit the deadline very close to a playable game, which I consider a minimum requirement for submitting. (Some people don’t.) Despite my fumbles, I (eventually) leveraged my ability to recognize when plans needed to change, I identified and shifted priorities, and most importantly, I placed utmost priority and focus on the goal completion. Without that, no game!

Working on a Post-Compo version

When the compo ended, the game had only JUST become truly playable, and I was entering a groove where adding features and juice was eminently satisfying. So why stop there? I branched my code and kept working on a post-compo version, albeit at a more-relaxed pace. I added scrolling grass, shaded the monster, cleaned up and animated the pikes, added a demolition rumble effect, smoothed monster movement, tweaked the RNG to be less cruel, and gave the monster an increasing deceleration for faster and more dramatic slow downs. It’s more playable. And I’m still adding things to it. It gives interested players a change to look at something closer to “what I was going for,” and rewards them with a better experience as appreciation for looking. And I get to put in those missing elements that make me happy. :)

Tags: , , , , ,


Leave a Reply

You must be logged in to post a comment.

[cache: storing page]