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).
Saturday 26 November 2011
Friday 25 November 2011
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.
Thursday 24 November 2011
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).
Wednesday 23 November 2011
(originally posted 25 May 2011)
This is one of the earliest screenshots I have of the game. Unfortunately I did not keep many screenshots of early versions. I was mostly developing the engine which either worked or didn’t, while the art was very much placeholder art which I was not interested in capturing for posterity.
Monday 21 November 2011
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.
Sunday 20 November 2011
(originally posted 1st June 2011)
From the start I wanted a tower defense game in 3D. Not just one which is rendered in 3D, like Defense Grid, or an isometric view like Doomsday Defense, but one where the gameplay takes place in three dimensions.
Most tower defense games are linear, with enemies travelling along paths to an exit or goal. These games can be very well done, but the gameplay always comes down to overpowering a parade of enemies with upgrades, as any strategy without upgrades is quickly discovered.