Bacon and Games

Category: Game Design (page 9 of 9)

5 Things Flash Game Developers Often Forget

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.

The Difference Between Tetris and “tetris”

TetrisIt’s been over 25 years since Alexey Pazhitnov unleashed Tetris on the world. In that time, several million new games have been thrown into the mix. So why am I still playing Tetris? The obvious explanation: Tetris is a fantastic game. Well duh, but why? If you answered: ”the concept for Tetris is damn good” again I say duh, except that you’re only partially right. It takes a lot more than a good idea to make a great game.

To Illustrate this point I want you to think about all the Tetris clones you’ve ever played and how few of them, if any, are as much fun as the original. I think it’s safe to say that most of them don’t even come close and almost all of them feel at least a little bit off, even if it’s not obvious what’s missing or different. The rules of Tetris are simple, well known and it’s not terribly hard to get your hands on a copy. Over 30 million copies of Tetris were sold for the original Gameboy alone, which is to say nothing of the NES versions and arcade cabinets still in use today. So how can it be that a game so ubiquitous, so simple, so well known and already proven to be such a phenomenal hit be so difficult to copy? Simple. It takes a lot more than just a good idea to make a great game.

If you were asked to list the rules that govern the way Tetris behaves, you might come up with something like this:

  • There are 7 different blocks that fall randomly from the top of the screen into the play area, one at a time. You would of course have to somehow detail each of the 7 shapes and describe the play area.
  • The player tries to arrange these blocks into contiguous lines stretching the width of the play area. Upon doing so, this line is removed and the blocks above shift downward.
  • The user may rotate and move the blocks left or right as the block descends in order to position it as desired.
  • As the game progresses, blocks spawn and descend more quickly. As blocks drop, they drop in increments equal to the size of the squares that make up each block. i.e. the blocks are confined to a grid.
  • When the blocks pile up such that they extend above the play area the game is over. The goal is to last as long as possible.

In a nutshell, that’s the overarching concept behind Tetris. They are the rules that explain the way the game behaves, what the player does, what the goal is and how a game comes to an end. They are the rules we all know off the top of our head and could probably articulate if asked to. What makes the original stand out from its clones are the touches Pazhitnov applied to the game as he designed it. These are the things that you might have sensed were missing or different in the clones but just couldn’t put your finger on.

Here are some of the rules that fall just outside the general concept of the game. How many of these can you answer without going back to play the game?

  • Can a block be rotated when it’s up against the wall of the play area?
  • When a part of a block is removed and the remaining square is above a gap, does it fall until it hits another block? Does it fall by only the number of rows that were removed? Does it fall at all?
  • Does the block rotate when you pressed the button or when you released it?
  • After a row is removed, is there a pause before the blocks above drop into place? How long? Do the blocks above drop all the way down or do they drop one row at a time until they’ve moved as many rows as were removed?
  • Around what square of each block does the block rotate?
  • Does the music speed up as the game gets faster? Does the music change when the game ends? Are there sound effects when a block is rotated, dropped or spawned? Is the Tetris theme music playing in your head yet ;)
  • How many more points is a Tetris worth (clearing 4 rows at a time) compared to clearing 1 or 2 or 3? Is the difference linear or exponential?

It’s likely someone cloning Tetris would miss these points, because they’re not part of the core rules of the game. They’re the supporting cast yet they can make all the difference in the world. Regardless, if a programmer cloning Tetris did think to ask these questions, he or she could play the game and get a concrete answer to each. However, some of the most important details can’t be extracted just by playing the original:

  • How long after a block has touched down can it still be rotated or moved?
  • At what speed can you no longer slide a block horizontally into an opening?
  • By how much does the speed increase each level?
  • Are the blocks generated completely at random or are they chosen based on previous blocks chosen, a weighting system or even what the player might be waiting for? (how many times have you been dying for a straight piece and never gotten it?)

These lists are incomplete, but they ought to be enough to illustrate my point, which is not to say that Tetris cannot be copied. Of course it can, any game can if you’re willing to spend enough time testing and tuning. I’m also not interested in the reasons behind why so many Tetris clone programmers couldn’t make the grade; lazy, rushed, low budget, first time programmer, bad eye for detail, whatever…the reasons are of no consequence. What’s important to note is that Tetris is an extremely well known game with a simple set of rules that isn’t much of a technical challenge to program, yet so many of its clones just don’t cut it. Why do you think this is so?

The answer is simple. It takes a lot more than just a good idea to make a great game. Is it sinking in yet? When it comes to game design, the final product is very much the sum of its parts, which include but are not limited to concept AND art, sound design, interface, difficulty, originality, learning curve, proper tuning and those extra touches. Without getting too analogous, a game, like a house needs a solid foundation. But in order to be a great house it will also need sturdy walls, furniture, nice carpeting, hopefully a tv the size of a small country, maybe a snappy doorbell ring and with any luck a sexy wife with a penchant for cleaning in the nude…but I digress. The point is, even with a solid concept every game walks a fine line between flop and phenomenon. Most of the Tetris clones out there follow all of the concept’s rules but miss just enough from the other lists that they feel dull. You don’t have to stray very far from Tetris before it becomes “tetris”.

But it’s easy to compare a classic to its clones and see where one succeeded and the other failed. How do you identify these key elements before you send your game out into the world? Are there blanket rules that can be applied to all games in order to make them better? What kinds of questions can I ask about my games in order to identify the important details that will transform my good concept into a great game? How do I know when my concept is good or my game is great? Which of our contemporary games have gotten it right and why? These questions are just a very small sliver of the things I’d like to tackle here at Bacon and Games. Thank you for taking the time to read this.

I play games. I make games. I love games. And I really love bacon.

– Sean

P.S. Yes I know that versions of Tetris existed before Nintendo came along, but let’s not kid ourselves about who put the game on the map. For the purpose of this discussion it makes the most sense to treat the version the vast majority of the world is familiar with as the original.

Newerposts

Copyright © 2025 Bacon and Games

Theme by Anders NorenUp ↑