Latest Posts

  • 4k Game Contest – Some useful tips

    4kOk so after the embarrassment of my first post on this subject, I wanted to present some findings that may help you out on your quest for smaller SWF sizes. More importantly, I know for a fact these all worked for me!

    For those who didn’t read the previous post: I’ve been working on my entry for the 4k Game Competition, and have found the following information during the course of my coding:

    Keep Event Listeners out of the constructor

    I have a whole bunch of init stuff in my constructor (creating game graphics, setting up variables, etc) and at the end I kicked off the game by starting up the main events (keyboard, mouse, etc). But by moving the event listeners to their own function, and calling that function from the constructor, it reduced the size of the SWF.

    If you know the size of something, use it! Avoid references where possible

    When creating a Rectangle I passed in the width and height of a bitmap by reference (bulletBitmap.width). By removing this and passing in the actual known width of the bitmap (6) it saved a massive 20 bytes from the ActionScript code.

    Before: bulletRect = new Rectangle(0, 0, bulletBitmap.width, bulletBitmap.height);

    After: bulletRect = new Rectangle(0, 0, 6, 6);

    Here’s another example where being explicit saves bytes:

    Before: fullRect = stage.getRect(stage);

    After: fullRect = new Rectangle(0, 0, 550, 400);

    This saved us 6 bytes.

    Make Bitmaps Transparent

    I create a bitmap the size of my Stage to hold the game background in. It looks like this:

    gridBitmap = new Bitmap(new BitmapData(550, 400, true, 0x0));

    Now I don’t need this bitmap to be transparent (the 3rd parameter) as it sits at the bottom of the display list. But by setting the transparent parameter to “false” it increased the size by 3 bytes.

    Even default values take-up space

    Object instantiation is expensive in AS3, so it’s best to pre-calc objects you need in your main loops at the start. However who would have thought that the following:

    zeroPoint = new Point(0, 0);

    takes up 1 extra byte than:

    zeroPoint = new Point();

    Even though 0,0 are the defaults for the Point object. Every byte counts!

    Avoid Array references in for loops

    I have a loop in the game that checks through a pool of baddies (standard Array containing a custom Object that extends a Sprite). I started out doing it like this:

    for (var a:int = 0; a < baddiePool.length; a++)

    and then …

    baddiePool[a].value = newValue;

    But by pulling out the array element first at the top of the loop, then referencing that, I saved a massive 33 bytes in total:

    ba = baddiePool[a];
    ba.value = newValue;

    Smaller than a ternary

    Thanks to Kevin Luck for this one :) If you need to run a standard if/else on a value where it could be equal to zero then it can be shortened to:

    x = lx || Math.random() * 550;

    In the code above, x = lx unless lx = 0, in which case set x to Math.random() * 550. This is 3 bytes smaller than using a ternary/if-else equivalent.

    Hopefully the above will help out those also entering the competition. Feel free to comment and add more tips!

  • 4k Game Contest – and a word about ternary operations in AS3

    4k Edit: Thanks to Kevin Luck for pointing out a flaw with the code in my original post (there was an extra assignment taking place, which caused the byte count to increase). Remove that and ternary will match if/else on a bytes-used basis. I’ll keep this post up here regardless, just ignore everything from this point on :)
    Read More

  • Clockwork Whistler

    click to zooom

  • My new game Kyobi released onto

    Kyobi Title Page (320px)

    Today I managed to get time to finish-off and release my new game, Kyobi, onto The game is best described as a cross between Columns, Tetris and a Match-3, but with a big fat dose of physics thrown in for good measure. As the blocks drop you can grab them with the mouse, and fling them around. Match 3 or more of the same colour and they all explode in a shower of particles.

    Throw them together with real force and you’ll shake the screen and score bigger points. Chain combos can be obtained by smashing lots of colours one after the other within a set time. There is something very feng shui about the game. Watching people play is fascinating; some will try to organise the blocks into different stacks of colour along the bottom. Others will just slam them around with gay abandon! Personally, I’m a “stacker” :)

    I am really pleased with how this game plays. I spent a lot of evenings working on tweaking the difficulty, so the first 20 levels guide you through the game. The pace ebbs and flows gracefully. After a really hectic level with 6 blocks falling every couple of seconds, the next level can often be far more sedate with a slow trickle to give you a breather. Basic game AI controls level progression there-after, ensuring the game doesn’t just get faster and faster (which would be no fun for anyone). The game uses my new PixelBlitz physics classes through-out.

    Kyobi In-game (320px)

    Kyobi In-game (320px)

    At the time of writing this Kyobi is up for bidding on If you have a Developer account there (or are one of my FGL friends) you can play it here. Everyone else I’m afraid you’ll have to wait until it goes public, sorry!

    Right now I’m waiting for to finish the music and sound effects for Kyobi, but hopefully that will be done soon – this will be the first time I’ve ever used them, but I’m sure they will do an excellent job, and I’m really looking forward to hearing what they come up with! In equally exciting news for me: The Game Creators will be bringing Kyobi to the iPhone this March. Can’t wait to see what they do with it too :)

  • Super Stario Land Video

    I worked on a few commercial games on the Atari ST back in the mid 1990s, one of them was Super Stario Land by Top Byte Software. This was a shameless port of a Nintendo game a few of you may have come across. The developer (Adrian Keylock) literally copied as much as he could from the NES original onto the ST, and I did the graphics.

    Today I saw someone had uploaded a video of it to YouTube. It made me smile, even if the graphics do now make me cringe. It was actually really hard work to draw because the developer enforced a strict number of bitplanes per sprite, which mean I had at most 3 colours to paint with (plus black). The graphics were shamelessly stolen from the NES original. But there were no “Sprite Rip Archives” back then! They were copied by hand from a TV screen onto graph paper. Then redrawn on the ST.

    Quite frankly if the ST hadn’t been on its last legs when this title hit, Nintendo probably would have sued our asses off. As it happens they didn’t, the game got good reviews and sold well. It even spawned a sequel.

    Interesting factoid #1 – the main character is based on Calvin from Calvin and Hobbes.

    Interesting factoid #2 – I was never sent a final copy of the game. The publisher was run by a guy called James Matthews. He was a nice enough chap, but the cheeky bastard never even saw fit to send me the game – let alone any payment for my work. I did finally get a boxed copy off ebay a few years ago.

More posts to tickle your grey matter ...