Skip to navigation

malevolent design weblog

This blog is now defunct, but you can find more stuff over at my personal site

Flash Games Finickiness

As well as spending much of the past few months immersed in Flash, I’ve played dozens of games (good and bad) and devised several more for pitches and future development.

So I’ve been thinking about the details that often make a big difference to Flash games and trying to address them myself. This is mostly me rambling on stating the obvious, but it’s also easy to overlook the obvious, right?

Basic physics
Even simple or abstract games, where realistic physics simulation isn’t relevant, still usually benefit from position/velocity curves instead of straight lines. Thinking of movement in terms of crudely-modelled acceleration, friction, elasticity, etc. gives more interesting results than sliding things around by the same number of pixels per frame (unless you want a more stilted effect, of course).
If you’re working on a commercial game then I strongly recommend setting aside a chunk of the budget to commission custom music. Choosing suitable stock material is fine, but hiring a talented musician has vastly improved every game for which I’ve been able to do that, so if you can find the right composer at the right price then go for it.
Sound effects
Chuck out that old CD-ROM of crap 8-bit sound effects you’ve had lying around for years. Instead, browse for and buy some decent sounds that go together (I tend to use but there are many others), then take the time to edit them before you put them into Flash (convert to mono, trim, maybe fade in/out if the start/end is too abrupt, and normalise to 100% volume).
Instructions are boring, and most people don’t read them properly, so try to work the most crucial details into the gameplay if possible, explaining controls and features in context. Sometimes this is too cumbersome or time-consuming, but if a player can jump straight in then it does make the game more accessible and compelling.
Pick an overall theme/‘feel’ for the game and try to stick to it, whether it’s retro pixellated nostalgia, hand-drawn characters wobbling about or slick 3D-rendered polygons. Many games that have quite shoddy graphics make a good impression because it all hangs together, the shoddiness is part of the overall charm.
Goals and rewards
Even if a game is open-ended, or doesn’t have a budget large enough to allow for multiple levels or a fantastic congratulatory end effect, you can still usually do something to reward the player for success. Maybe recycle and rearrange some graphics combined with text to tell a story at the end, or give them a daft certificate to print off, or a link to a daft hidden web page. And if the game doesn’t have a high score table you can keep track of the highest score achieved on each user’s machine via Local Shared Objects.
Freedom from bugs
What happens if the player completes a level on the same frame as losing their last life? Is it theoretically possible for the collision detection to result in something getting stuck? It might not be good for a developer’s peace of mind, but constantly fretting about obscure bugs and glitches is vital. It helps to have a few friends or colleagues who relish the challenge of testing games to destruction, and maybe consider offering a bounty (a Bounty?) for new bugs.


Comments are now closed for this entry.