String to ByteArray

In Bug Tunnel Defense all levels (called missions in-game) are stored as Strings. This includes the built in levels, levels stored on the user's machine that they've created, and levels stored online in GamerSafe's LevelVault and Kongregate's shared content system. Kongregate also uses Strings, so was very straightforward. But LevelVault requires data stored in a ByteArray, so I needed to convert Strings to ByteArray.

wonderfl

As I've used it in two posts I should mention what wonderfl is. It's simply one of the best resources available for Flash developers, in particular ActionScript programmers. It lets developers upload and run ActionScript, for testing or to demonstrate it. Code on the site can be modified, even if you did not write it, by creating a copy (or a 'fork') and working on that. Editing and testing all takes place in the browser, making it often much quicker than setting up a similar project in Adobe Flash CS or a similar environment.

A faster random

Although ActionScript has its own random number function, Math.random(), like most library calls it is not especially fast. But it is easy to replace, to provide a significant speed up, as well as make it easier to do other optimisations.


The basic idea is very simple: instead of calling Math.random()while the game is running call it a number of times at startup to populate a list, then at runtime pull values out of that list. This would not work in all games: it might produce predictable or repetitive outcomes in some cases. But in games where random numbers are used for effect or to provide some variability in a number of ways it is often indistinguishable from Math.random() (which is not truly random anyway).

My 2D Vector class - and why I no longer use it

For Bug Tunnel Defense I created a 2D vector class. The nearest thing built in to Flash is the Vector3D class, but that with four elements is twice as big as I needed, and also uses Number rather than int as I wanted. I wanted something to store 2D grid positions, for game logic, so I created my own class. Then barely used it.

My TextField class

This is a class I added to replace all instances of TextField in Bug Tunnel Defense, to eliminate half a dozen lines of near identical code after each call of new TextField();


The constructor for TextField for some reason takes no parameters, even though you pretty much have to set some properties for an instance you create in code. I added  parameters for the defaultTextFormat, x and y which I was always setting, as well as an optional Boolean to make it right aligned. For those text items that were fairly dynamic and so could change alignment I also added functions to set the alignment and position at the same time.

The Bitfield class

This is a simple class I made to handle bitfields in ActionScript. It's main purpose is to make it easy to save flags for preference and progress as integers, alongside other integers so simplifying the code for loading and saving which was tricky to debug.


It includes methods to access individual bits and the whole data as an integer for saving. I also added a function to sum the number of bits, to count the number of awards as they were stored in a Bitfield.

The JIT compiler and constructors

One of the biggest optimisations I did to Bug Tunnel Defense was also the easiest.

ActionScript 3 includes a number of improvements to the language, but perhaps more significantly includes a new runtime, AVM2, which incudes a just in time (JIT) compiler. This speeds up all code significantly but with one notable omission. It doesn't speed up constructors.

Distance check

Distance calculations are important in many games. One important example is checking distances to compare them to the range of a weapon or weapons; turrets placed by the player or AI enemies that need to decide when to fire. And because there can be many enemies or turrets in game these calculations may need to be done very often, perhaps many times a frame.

More on Colours

As  I noted two days ago I store all colours as integers, in particular as uint values. These are stored as static members in a class, 'Col', for easy access to them, and also in saved levels created in the level editor (it actually stores only four bits per channel, to match the way the editor works).

Header files

One of the things I had to unlearn when moving from C/C++ to ActionScript was about header files. In C and languages based on C it's common to create header files for constants and definitions used in the program, which are then included in any source file that needs them. Often some or all headers are included in all source files, alongside system headers. The only cost in doing this is compile time, though even this can be mitigated by precompiled headers and incremental compilation, or ignored with a fast enough compiler.

The Colourise class

This is my replacement for the ColorTransform class. My reason for creating it was as I store colours as RGB integers, such as 0xffffff, 0x000000, but ColorTransform works with separate floating point values. With this class I can easily use RGB colours whenever I need to use a ColorTransform (which is quite a lot).

Twips

Although the x and y of a DisplayObject in ActionScript are accessed as Numbers they are stored internally as twips. Twips are units of one twentieth of a display pixel, small enough to position a DisplayObject with sub-pixel accuracy. But they are not Numbers and so should not be treated as such.

In particular if the position of an object needs to be stored for later use it should be stored somewhere else. Storing it in the built in fields of a DisplayObject is slower and less accurate.

Be especially careful of doing calculations on values stored as twips which can amplify the error, such as subtracting the positions of two DisplayObjects to get their separation or the bearing of one from the other, or using two positions of a moving DisplayObject to calculate its velocity.