Bacon and Games

Tag: flash (page 5 of 5)

Calculating the Distance from a Point to a Line in AS3

I recently made a game for a client that involved a giant sweeping laser of doom (the game had the laser, not the client). Sounds cool, right? Not if the laser happened to touch you while you were busy blowing up robots. Sound even cooler now that you know there were robots? It was. But that’s not what I want to talk about today. What I’d like to cover is the slightly more exciting topic of how to calculate the distance between a point and a line.

I won’t go into the math behind it, not because it’s complicated but because it’s just not that interesting or important to understand. I’ll just give you the code and then talk a little bit about why it might be useful in a game. If you really want to know how the math works, leave a comment or email me and I’ll do a follow up. For now, here’s a simple visualization (download source here):

This movie requires Flash Player 9

Once again I’ve built on a handy function written by Keith Hair that finds the point of intersection between two lines. Using his lineIntersectLine() function and my getDistanceFromLine() function you can calculate the distance between a point and a line very easily.

Why is this useful? I wrote it so that I could determine if the doom laser had overtaken my hero. Since the laser was represented in my code by two points (a line) and I knew the location of the hero (a point) all I had to do was calculate the hero’s proximity to that line. When the hero’s proximity was less than a certain distance >> kill hero. And because this calculation was done mathematically rather than being tied to a hitTestObject() based on the laser’s movieClip1, adjusting the laser’s killzone was as simple as changing one variable.

Here’s another example of how this information might be useful in a game. Suppose your game has a laser cannon which fires in a straight line, as opposed to the sweeping radar motion in my prior example. If you know each enemy’s proximity to the laser you can apply varying damage and effects to each enemy based on that information.

There are plenty of ways you could use this in a game, but I’ll leave that up to your creativity. You can download the source files for the above demo here. Oh and as is often the case with art in or around my site, the bad-ass laser and art in the screen grab above was done by my partner in crime, Ajay Karat of The Devil’s Garage. He and I are working on some games (not for clients) so expect to see some stuff from us in 2010.

  1. When designing your games you’ll want to keep your visual assets separate from your calculations. Let your calculations dictate what needs to be displayed, not the other way around. Tying calculations to visual assets is usually, if not always, inefficient and inflexible.

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.

Newerposts

Copyright © 2024 Bacon and Games

Theme by Anders NorenUp ↑