Bacon and Games: Together at Last

Page 19 of 19

User Interface Design Tips for Your Game

A good UI doesn’t require the user to think about how to access or interpret the information and features of your game. What the user needs should be readily available and interacting with it should be intuitive. Every user is different and most of them will not interact with the game exactly as you intended. Making your UI as simple and flexible as possible will allow the UI to fade into the background and help draw the user into the game’s experience. Here are a few things to consider when designing the UI for your game.

Give Users Input Options
Some people are on laptops with small arrow keys. Some people are right handed and some evil people are left handed. Some have a trackpad but no mouse or a keyboard with only one shift key. Giving your users options helps them find a configuration that best suits them. The simplest example is using the arrow keys to move versus using the WADS keys. This is especially true if your game requires simultaneous mouse and keyboard use.

In addition to basic physical comfort, it’s nice to let users decide which actions their dominant hand will be responsible for and which actions will be relegated to that other hand *shudder*. If your game is a simple run/jump platformer, consider letting the user choose between the [arrow keys + Z] -OR- the [WADS keys + L]. You can often get away with leaving both configurations active and not even have to ask the user to select one. This is sometimes the best option because most people will intuitively try the WADS or arrow keys when a game begins and you can safely assume they’ll try their preference first. There’s nothing more comforting than guessing at a game’s controls and finding they’re exactly what you expected them to be.

Give Users Audio Control
There’s no question that audio plays a crucial role in great game design. Anyone who has ever played Left 4 Dead and had their heart jump into their throat when the dreaded tank music kicked in would probably agree [well fuck, I better find some health] . But sometimes sound just isn’t an option for your user (I know I hope people are playing my games while they should be working) and it’s better to have them play the game without sound than to not play it at all. It’s also nice to give users the option of muting just the background music or just the sound effects. Sometimes all I want to hear is Hall & Oates but still want to hear zombies exploding because I’m crazy like that. Same as everything else regarding your UI, don’t make toggling sound a chore. If the game doesn’t use the mouse, don’t make the user click something to toggle the sound and vice-versa for a game that doesn’t use the keyboard. The best approach: allow the user to toggle sound with keystrokes OR a mouse click.

Make Binary Keyboard-Driven Selection as Clear as Possible
Whew, that was a mouthful. Let me ‘splain. No, there is too much. Let me sum up. Early DVD menus that offered wide or fullscreen options on startup were guilty of this. If you have 2 options and are using the keyboard to choose between them, make sure it’s painfully clear which option is selected and which is not. Consider the following scenarios (you will have to click on the Flash object in order for it to receive keyboard input…ironic, I know)

Ambiguous

This movie requires Flash Player 9

Clear

This movie requires Flash Player 9

You don’t ever want your user to wonder which option is currently selected, especially if the options are “continue” and “start over”.

Here are a few remaining thoughts:

If you absolutely must have an instruction screen, let your user start your game from there. Do not force them to go back to your main menu just to start the game
Programmers love to type dummy text into dynamic text fields at author-time to see how many characters their field will hold. Remember to remove these fillers before you finalize your game. When your game starts showing a score of “00000000000” and then jumps to “5” it’s a jarring transition that doesn’t deserve the user’s attention but will likely grab it.
You probably want your games to be so addictive that they evoke that just-one-more-game-I-know-I-can-hurl-that-cat-past-the-barbed-wire replay mentality. So when you create a game that achieves this, make sure you let the user restart as easily and quickly as possible. If it’s a keyboard game, don’t force them to grab the mouse and click. It’s usually best to give them the option to click or press space to restart. If you’ve got their attention, keep them drooling and mashing the keyboard for more :P
When designing audio for your game, don’t use headphones. Turn your speakers on and play some music at a reasonable volume. Then design your game’s audio volume within a reasonable range of that. How many times have you opened up a Flash game and been blown away by the game’s music, or conversely been blown away by your own music after quitting the game and resuming iTunes?
When displaying large numbers, use commas. 15,389,023 is a lot easier to read than 15389023. I’ve provided a function below that will format a number with commas. I wish I knew who the author is so I could credit him/her. I’ve had it so long (this is converted from AS1) that I don’t recall where I picked it up. Sorry noble mystery coder :(

// adds commas to a number, returns a string for display
public static function addCommas(number:Number):String{
    var numString:String = number.toString();
    var result:String = '';	
    while (numString.length > 3){
        var chunk:String = numString.substr(-3);
        numString = numString.substr(0, numString.length - 3);
        result = ',' + chunk + result;
    }	
if (numString.length > 0) result = numString + result;	      
return result;
}

As I said in 5 Things Flash Game Developers Often Forget, none of these things will make or break a game. But the more little things you get right, the better your game’s overall experience will be.

Intersection of an Ellipse and a Line in AS3

22.02.2010 / Sean James McKenzie / 17 Comments

A few months back I was working on a game for which I needed to be able to calculate the points of intersection between a line and an ellipse. I wanted enemies and the hero to be able to collide with and avoid an elliptical obstruction in the middle of the game. I also wanted to be able to calculate whether enemies had a line-of-sight to their targets, given this elliptical obstruction. I did some searching to see if anyone had written a class to handle this. Keith Hair wrote a very nice class that does this with a circle. Aaron Clinger and Mike Creighton wrote a a very nice Ellipse class, but it didn’t deal with ellipse-line intersections, only ellipse-point intersection and general ellipse calculations such as area and circumference. Both of these are great finds, but neither of them did what I was looking for.

Since I couldn’t find what I was looking for I decided I would write it myself and since Aaron and Mike’s Ellipse class had so many useful features I though I’d have my class extend theirs. Here is a demo of my EllipseExt class which has all the bells and whistles of Aaron and Mikes Ellipse class plus some intersection calculation methods added:

This movie requires Flash Player 9

You will notice that by dragging one of the nodes inside the ellipse you lose a point of intersection. However if you switch on the “extend line indefinitely” option the nodes will no longer act as start->end points but rather 2 points that define an infinite line. This is a feature I found helpful for game programming, so I decided to build it in as an optional argument of the getIntersections() method. There is another optional argument that came out thinking about game logic; the sort option. With sort set to true, the getIntersections() method will sort the points by proximity to the first node used to define the line (i.e. the first required argument). This can be very helpful if one of the line’s nodes is a hero or enemy approaching the ellipse and you need to know which of the returned points represents the potential point of impact.

Examples:

// generic form
public function getIntersections(p1:Point,p2:Point,extend:Boolean=false,sort:Boolean=false):Array
 
// define points that make up our line
var A = new Point(mouseX,mouseY);
var B = new Point(0,0);
// create an ellipse 200x100 at (50,50)
var ellipse:EllipseExt(50,50,200,100);
 
// Example 1:
// find intersections of line AB and ellipse BETWEEN points A and B
var ar:Array = ellipse.getIntersections(A,B);
 
// Example 2:
// find intersections of line AB and ellipse DEFINED BY points A and B
var ar:Array = ellipse.getIntersections(A,B,true);
 
// Example 3:
// find intersections of line AB and ellipse BETWEEN points A and B
// ar[0] will contain the point of intersection that is closest to point A
var ar:Array = ellipse.getIntersections(A,B,false,true);

There are a few other available methods, which I’ll refer to as shortcut methods because each of these can be achieved through the getIntersections method. However, these 4 methods either handle some of the logic you’d otherwise need to build around the getIntersections() method OR they’re acceptably lighter options depending on what you need to know about the line and the ellipse interaction. These are commented further in the EllipseExt class itself, but here’s a preview:

// simply determines if there is an intersection point at all (line-of-sight)
checkForIntersection(p1:Point,p2:Point):Boolean
// returns the point of intersection between the center of the ellipse and pt
getPointCenterIntersection(pt:Point):Point
// returns points of intersection on the ellipse at the given y coordinate
getInersectionsFromY(y:Number):Array
// returns points of intersection on the ellipse at the given x coordinate
getInersectionsFromX(x:Number):Array

The classes and source code for the above demo can be downloaded here.

I’d like to add some additional methods to this class, specifically for calculating tangent lines/points, which would be useful for pathfinding routes around an ellipse. But I figured that this was far along enough that it was worth sharing. If you have questions or find a bug, please feel free to contact me and I’ll be happy to do what I can to help. I hope you’ll find this useful. Enjoy!

Additional stuff on ellipses for those who need to brush up:
Ellipse Equation Visualizer
Ellipse-Line Intersection
Quadratic Equation

5 Things Flash Game Developers Often Forget

17.02.2010 / Sean James McKenzie / 1 Comment

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 () 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”

13.02.2010 / Sean James McKenzie / 3 Comments

It’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.

Bacon and Games

Page 19 of 19

User Interface Design Tips for Your Game

Intersection of an Ellipse and a Line in AS3

The Difference Between Tetris and “tetris”

Sean James McKenzie

Categories

The Usual Footer Stuff