override public function toString():String {
	return "[ClassName]";
}

… Sometimes adding properties to the returned String that give back information about the class, e.g.

override public function toString():String {
	return "[ImageClass, size=" + _size + "]";
}

But writing them rigid like that is a disadvantage when you decide later to refactor class names. Admittedly it’s also not a very elegant way so I got the idea to take the class name that is returned by getQualifiedClassName(). The only problem is that getQualifiedClassName not only provides the type name but also the whole package String of the class. Regular Expressions to the rescue! After twiddling around with them for a while (I’m by no means a RegExp expert) I got my toString method into the shape that I desired:

override public function toString():String {
	return "[" + getQualifiedClassName(this).match("[^:]*$")[0] + ", size=" + _size + "]";
}

This way it matches the String returned by getQualifiedClassName with the Regular Expression [^:]*$ which checks from the right end for an arbitrary text up to the first occurring colon, but without including the colon. Taking the first element of the Array returned by match() and you got what you need!

A nice way of using this is when writing abstract classes that contain the toString method and any subclass can use that toString method without the need to override it … that is of course unless you want ot add other output information.

In game development randomness is often necessary for certain tasks, be it the random distribution of graphic tiles, a random factor in NPC AI or random stats in a roleplaying game. Especially for the latter purpose the static Dice class provides a set of methods to roll dice as it is common in a Role-playing game, to be exact four-, six-, eight-, ten-, twelve-, twenty-sided and percentile dice.

The Dice class (and it’s supporting classes) are rather elaborated, using for example the Linear Congruential algorithm in the process of generating ‘true’ random numbers so it might not be the most speed-optimized method for calculating random numbers. For absolute performance the LCA and rounding routines can be removed to speed up calculations.

Using the Dice class is very simple! For example rolling two ten-sided dice can be done with the following call …

var result:int = Dice.tenSided(2);

… rolling the percentile die is even simpler as it does not need any arguments. It always returns a value between 1 and 100 …

var result:int = Dice.percentile();

… the class also provides the roll method with that any x-sided die could be rolled, 3 sixteen-sided dice for instance …

var result:int = Dice.roll(16, 3);

The following small Flex application uses the Dice class and can be used to test dice throw probability according to the bell curve (the more dice are used the lower the probability to roll boundary results).

(Please open the article to see the Flash content.)

Update: The Dice class is now part of the hexagonLib and can be found here.

What are the advantages over using a generic MovieClip? When writing games you might have several animated graphics (also called sprites, but not related to the AS3 Sprite class) that should run with a different framerate than the game’s global framerate. Let’s say your game runs with a global framerate of 99 and you put several animated sprites into your game that were created for playing back with a framerate of 24. With a MovieClip all those sprites would also play with a framerate of 99 which means they play way too fast. However with an AnimatedBitmap you can set every framerate individually. There are a couple of other advantages like that a Bitmap is more lightweight than a MovieClip and it has a isPlaying() method. Also it changes the way of how to embed assets. Instead of embedding many files for one animation only one image for a whole animation sequence is embedded which has positive effects on the file size. The ring sequence used in the demo has 21 frames that use 102Kb as single images but only 44Kb when they are combined to one image.

The following demonstration plays with a global framerate of 99 but all AnimatedBitmap instances play at a framerate of 24 …

(Please open the article to see the Flash content.)

You can download the class including demo source code and demo image here:

Update: The class is now part of the hexagonLib and can be found here. You want this version because it’s the one that is being maintained.

Changes in v1.1
The timer object used to time the frame animation has now been made external. For this purpose a custom FrameRateTimer class has been added. This has the advantage that AnimatedBitmap objects don’t use their own timer objects anymore. Instead you can use one timer for many animated objects if they use the same framerate. This saves memory and CPU cycles. However you are still able to use one FrameRateTimer for every animated object if it is desired.
An IAnimatedDisplayObject interface has been added so that future animated display object types can be integrated more easily.

Also included is a jsx script for Photoshop CS named HDRS- CreateImageSequence that can be used to easily create a ‘single-frames image’ with Photoshop. Simply run the script in Photoshop and choose the images in the file browser that appears. Photoshop will then generate a single image with all the frames laid out horizontally. All images should have the same size to get a correct animation sequence. Also sometimes you need to fine-tune the position of some frames, e.g. for the ring in the demo (which was rendered to single frame images from a 3D modeler) I had to adjust the horizontal alignment on some frames because otherwise the animation would glitch to left/right by some pixels.

The MultiMap is heavily based on Michael Baczynski’s HashTable class but I modified it to my requirements and added a couple of additional methods for luxury. At first I wrote an even more customized version that would decide automatically which hash function to use but as it turned out some of these changes weighted heavy on the performance, especially not using a strict equality operator (===) and having a HashEntry object with non-numeric keys. In fact Michael’s class is still a tad faster (he really squeezed out the last bit of performance there) but as long as the MultiMap isn’t too large/full there is only a minor difference of some milliseconds.
As a trade-off I added checking for existing keys (which can be omitted to improve performance when adding values) and of course there is the multiple values functionality which required a more complex implementation of some methods.

I’m sure there is still a lot of room for improvement so if you have any suggestions it would be cool to let us know!

package
{
	public class WaterproofSingleton {
		static private var _instance:Singleton;

		public function Singleton(singletonEnforcer:SingletonEnforcer) {
			if ((singletonEnforcer as SingletonEnforcer) == null) {
				throw (new Error("Direct instantiation of a Singleton is not allowed!"));
			}
		}

		public static function getInstance():Singleton {
			if (Singleton._instance == null) {
				Singleton._instance = new Singleton(new SingletonEnforcer());
			}
			return Singleton._instance;
		}
	}
}

class SingletonEnforcer {}

package
{
	import com.hexagonstar.util.debug.Debug;
	import flash.utils.getTimer;
	import flash.display.Sprite;

	public class PerformanceTest extends Sprite
	{
		private var aVeryVeryLongVariableNameaVeryVeryLongVariableName:Number;
		private var num:Number;

		public function PerformanceTest()
		{
			var startTime:Number = getTimer();
			for (var i:int = 0; i < 4000000; i++)
			{
				aVeryVeryLongVariableNameaVeryVeryLongVariableName = (i * Math.random()) * 100;
			}
			var timeTaken:String = getTimer() - startTime + " ms";
			Debug.trace("timeTaken (long): " + timeTaken);
		}
	}
}

I've ran this code ten times with the 50 characters long variable name and then ten times with a 3 characters long one, both in their own SWF's. The results ranged from 757ms to 820ms, more or less the same on both sides. The sum of the long variable version was 7924ms and the one of the three characters long one was 7903ms, not much of a difference.

The next test was similar but this time with a 50 characters long Method name and the other again with a 3 characters long one, the Methods returned a random Number for 4000000 times during this test. The results looked similar but the total sum of each test gave a 12044ms for the long name test and 15570ms for the short named one. A noticable difference of over 3 seconds. This might have been coincidence but I've ran the tests a couple more times and it turned out every time that the result were very close together. This is quite interesting because I was safely believing that short names would still have an advantage. It might be time to rethink this.