Before I get into discussing larger scale game design theory, I wanted to put up a quick post about some of the most common things Flash game developers forget to do. None of these will save a bad game, nor will they completely ruin a good game but forgetting them will definitely take a bit of the shine off an otherwise polished game.

  • Embed fonts used in dynamic text fields: If you forget to embed a font used by a dynamic textField, users who do not have this font installed on their machine will see an ugly system font in its place. When this happens it really stands out, even to the casual observer. If the kerning and size of the default font is dramatically different than the font you chose, you run the risk of your textField being too small to display the data being passed into it. Now your text is ugly and incomplete…d’oh! This one is very easy to overlook because fonts you won’t notice a missing font on your own computer (because it’s not missing for you). It’s always a good idea to check out your game on a friend’s computer.
  • Make dynamic textFields unselectable: Dynamic textFields are most commonly used to simply display information; scores, numbers of lives remaining, subtitles, etc. So 9 times out of 10 these textFields need to be seen but do not need to be interactive. Neglecting to make textFields like these unselectable will not cause any problems, but when the mouse hovers over a textField and the cursor changes to the i-bar (Text Selection Cursor) it not only looks unprofessional but it detracts from the flow of the game. This can be especially tragic in mouse-driven games if the user is clicking around to fire a weapon and their cursor is constantly changing each time a score pops up under their mouse. This one is also frequently missed because dynamic textFields are by default selectable, both via code and at author-time. The exceptions are web safe fonts, which I consider the fonts appearing first in the font-family lists (Ex: Helvetica does not come with a PC).
  • Use solid hit states for all buttons: This one seems like a no-brainer yet I still see a handful of games every day that forget this one. It’s most commonly a problem with buttons that are only text. Flash has gotten smarter over the years and will now use size of the textField as the hit state if you don’t define one. However if you decide later on that you want to break your text apart to save on file size, you’ll find yourself left with the dreaded flickering mouse cursor on rollover. Rule of thumb: give all your buttons a simple solid rectangular hit state as soon as you create them.
  • Pixel fonts belong on whole numbered coordinates: Pixel fonts look best when positioned on whole numbered X and Y coordinates. They’re designed to look sharp when positioned evenly on the pixels of your monitor. Since Flash allows you to position at the sub-pixel level (Ex: mc.x = 2.5) you can cause a sharp pixel font to become blurry by positioning it between pixels. Pixel fonts can also become blurry when scaled or set to sizes not intended for use by the designer (some general info on pixel fonts can be found here). If your pixel fonts don’t look sharp, check the coordinates, scale and size of your font. If your textField is nested in a movieClip, make sure that both the textField AND the parent clip is on even numbered coordinates.
  • Disable the default context (right-click) menu: By default your Flash games will, among other options, offer the user playback controls. Depending on how you’ve built your game, a user might be able to break your game by selecting “play”, “forward” or “back”, moving the playhead of the main timeline independently of your game logic. Besides providing an opportunity for users to accidentally break your game, the default context menu is bulky and well….default. Disabling the default settings reduces the number of items in the menu to a paltry 2, both of which are completely harmless. If you’re feeling saucy drop a credit to yourself or an easter egg in there. Whatever the case may be, take a few minutes to cleanup this potentially harmful and ugly default menu. Your flash developer peers will respect you for it :) [customizing context menu AS2 | AS3]

If you already take these things into consideration, fantastic! Stay tuned for some posts more your speed, though I run into these things frequently enough that they were worth covering. For you new Flash developers (or old ones with bad habits) please try to consider these simple adjustments for your future projects. You wouldn’t spend months detailing a car only to leave the last few inches of the hood unpainted, would you? One tiny missed spot might go unnoticed, but miss too many and you’ll end up with a bad paint-job that ruins your beautiful restoration. The same is true of your games. If you’ve spent months building a game, don’t let a few simple blemishes tarnish the experience. Every time the i-bar pops into view or a button roll-over misbehaves the user is yanked out of the game experience and reminded that they’re in an application. As a game designer you’re building a game, not a Flash game or a java applet. You should strive to help your users lose themselves in your game by keeping them away from anything that might remind them of reality. After all, that’s probably why they’re playing your game in the first place.