Angry Missiles

Angry Missiles started out with some kind of intent to make an Angry Birds clone, but before I got there I realized I hadn’t touched ballistics (or, really, physics at all) in Phaser.io. It seemed a little ambitious (not really) to jump right into the wild world of Box2D. So, ballistics it was.

Before I get to gabbing about this, let’s get this link over with:
Play Angry Missiles
Or look at the code and stuff!
Instructions: Move the mouse to change the firing arc. Hit the targets. Win.
Credits: Graphics, sound, and music from OpenGameArt.org. Check the .md files accompanying the media on github for full credits!
Dev time: 9.5 hours, spread over 16 days.

This project involved a lot of hours of wrestling with performance. I had extreme stuttering, long load times (3+ seconds? Are we serious?), and a host of other annoying little issues. At the end of it, I decided to try switching back to Chrome for my testing. I do like both Firefox and Chrome for different parts of testing/debugging, but on the mac mini I’m currently using to develop these jammies, Firefox’s single-threadedness (as far as I can tell) just doesn’t yield quite as smooth an experience as Chrome. I expect to go back and forth on this, but for now I can’t afford the time wrestling with my browser.

I’ve also decided that my “Cut ALL the corners!” jam style isn’t, ahem, cutting it anymore. For the first several of these, I think I was well-served by not worrying about coherent/elegant designs. The jams have been more prototype than product, and that’s intentional. Going forward, I think it’s time to take measured steps toward elegance, particularly in the area of re-use.

The original plan of busting out tiny games in the AM before my actual work day had begun was appealing for many reasons, some silly and some reasonable. It aligned better with my notion of a “kata,” it reduced the “peril” of starting on any given new project, and it promised (once my velocity picked up) to raise my number of produced games (y’know, they do count, technically) to the double and then triple digits in fairly short order.

However, as a relentless intro-/retro-spectivist, I thought about what I had learned after each jam and found I wasn’t gaining the sort of things I think are most important.

Some benefits of microjams:

• Learn how to identify and implement the shortest path to functionality.
• Maybe a wider variety of games (due to volume).
• Quirks of the engine around those games’ functionality.

Some benefits of longer “jams”:

• Time to learn about clean architecture, performance, re-usability, good patterns, etc.
• Larger scope lets you implement features that are more fun. (Maybe just more fun for the developer. :P)
• Larger games tax the engine more thoroughly, uncovering even more quirks.
• More time means more polish; it’s harder to excuse minor glitches when you’ve put in 40+ hours on something relatively small.

If you’re considering doing something similar, I imagine you’ll find truth in this. It’s fun to bust out a game in a couple hours, but I think we gain more from longer projects that stretch our skills more deliberately.