Gaming Your Way

May contain nuts.

Everyone's loving those 4096 bytes

The 4K comp is gathering pace which is great ( Actually finished my game last night / this morning. I had some ideas the other night on how to improve it and it was quite nasty going from being "well" under the limit at around 4070 bytes and then going over with the new code. I was on 4099 bytes for quite a while last night until I cracked it. 4093 bytes and done, which is cool. I was going to be a clever sod and round that up to 4096 exactly, then realised that someone will do something in 2.5k that'll crap on my game and I'll just look silly for having used the max available and making something which isn't as good )

Rich over at photonStorm has posted some great tips for those of you giving the comp a bash in as3.

I opted for F8 / as2, although it's written like as1 with datatyping ( No Delegate or classes here ). Publishing as F7 would have saved a few bytes, but I wanted some of the filter effects.
I'm not sure what I can pass on that may be some use, but here goes ( Remember it applies to F8 / as2, the rules could be totally different for say F5 / as1, the size report is your friend with this comp ).

Chaining vars is actually longer, eg

score=level=d=cnt=0;

is a bit bigger than

score=0;
level=0;
d=0;
cnt=0;

Loops seem shorter this way,

while(--i)

Although to be honest I didn't try for loops ( I always use while, just habit )

It's common knowledge that pre-as3 var names have an effect on  size and speed in terms of their length ( i is "better" then myTempLoopCounterVar ) but linkage names have an impact too, so "bb" is smaller than "baddieBullet". Common sense I know, but if you're not used to thinking it terms of making code as tight as possible it's easy to miss ( It was for me anyway ).

More general things I did was to re-use values as much as I could, for example when the player dies I have to move it out of the way so the collision checks don't get triggered again, so I set player._x=2000; because I use a setInterval afterwards to wait for the gameOver ( id=setInterval(gameOver,player._x); )

Another thing, which is so dirty, was to drop an enterFrame on to everything. Originally I did the usual looping through an array calling the objects mainloop, but by adding the code to the sprite itself you remove all the loop overhead and make each sprite self sufficient.

It's weird tearing up the rule book for this comp, it's like going back to as1 and doing all those nasty things we used to do just to get things working.
If you've not done anything yet I can really recommend giving it a bash. The deadline is ages away yet, it should only take you a couple of hours for a couple of evenings and it's really good fun, it gets you back in touch with coding again rather than just dropping huge bitmaps into your fla and using a tweening package.

Squize.

Comments (4) -

  • S

    2/18/2009 1:42:02 PM |

    Also I found out that not putting var in front of variable declarations makes the file bigger.

    var a = 5;

    makes the file smaller than if you use

    a = 5;

    whether you use a:number or just a makes no difference.

  • Squize

    2/18/2009 8:25:56 PM |

    Oops yeah I forgot to mention that, cheers for flagging that up S :)

  • tonypa

    2/19/2009 8:05:30 AM |

    "For" and "While" loops are compiled into same bytecode.

  • Squize

    2/19/2009 8:59:52 PM |

    I don't think that was always the case mate, I'm sure I had a bust up with someone on FK.games about that, to the point I did some tests in Flasm just to prove the point just to myself.

    In saying that... you're right it has changed in later compilers, so it may be something really obscure like publishing for as1 and FP5 that it's still different. Just a habit now, like 31 fps.

Comments are closed