Things to check out: There’s 3 directions that a green guy can throw, he is way more accurate whenever there’s danger (both when red guy is loaded and when a ball is already mid-air), he can catch balls every so often, and I use Grid-Collision Checking. Yes, this Grid-Collision checking became an obsession and it will benefit me.

Yup, efficiency took preference here again, mainly because for the sole reason that I was increasing in different collision checks, and it was really taking a toll on performance. So I implemented/modified Keith Peter’s Grid Collision method, which is great since it really cuts down on number of collisions.

Basically the concept here is that two objects far away shouldn’t be checked for collisions. You create a grid and plot every element in an area, so that you only check the grid spots around each element, and perform collision-checking on those. It’s a fairly interesting concept, I cut down the checks (the bottom left number was used for testing purposes - ignore it) and thus optimized the game. Grant Skinner also has a great article and full source code of his implementation that you should also check out.

COMING UP: This is part 1, I wanted to include some dodge-jumping tactics, onfloor danger detection/dodging, and more importantly, explosions.

I got this from Michael James Williams, I’m almost embarassed to mention this but, having any sort of Math.function call, especially Math.sqrt in my case, is extremely hazardous to your application. I simply applied his method. Its a bit of a face palm.

For determining distance, which is heavily used for collision detection, one traditionally finds the differences in x and y, and then squares them using Pythagora’s Theorem. The root value of those squared distances added together gives you the exact distance between two objects. So:

dx:Number = objA.x - objB.x;
dy:Number = objA.y - objB.y;

var dist:Number = Math.sqrt(dx*dx + dy*dy);
if(dist < 40){
//slow, but massive explosion
}

Compared to this:

var dist:Number = dx*dx + dy*dy;

if(dist < 40*40){
//quickly animated, but massive explosion
}

That’s all there is to it. A massive increase in speed was seen immediately, since I had a few of those slow Math.sqrt calls.

Alright so I was finally able to really cut down on memory leaks and now this runs fairly smoothly for 50 characters. This is about as many enemies as I'll put on a single level, frankly 50+ enemies sounds ridiculous. I fixed the mouse listening lag, although it wasn't even that, I had some ridiculous functions that were storing very large integers, and that was every frame of movement. Anyways here's the first level, frame-based animation:

Click here to view embedding options!

A few things I noticed to speed up my game:

• At the start I store an array containing a maximum of 150 footprints, that seemed to the be optimal amount. So whenever a new footprint is made, I usually take an existing footprint on the screen (one thats been on the screen the longest) and adjust its position. Since the whole screen gets filled up with footprints, its hardly noticable. I find that preloading some arrays would be better than creating new objects, and this goes for snowballs too.
• No more new objects are created. In addition to this, I tried to avoid alpha and prefered to switch the frame to an empty frame. In addition to this I used to create new objects for a Red Guy swap; its better to have a temp object available and then reuse that over and over.
• Within my MouseMove event, I had a power ticker...which meant it was incrementing an integer every frame. Not a big deal, but I tended to increment it each time THEN i would set a maximum. So now it only increments a certain number of times and then it no longer adds to it. Unnecessary math. I complained about MouseEvent's inefficiency, but I was wrong. Sorry Adobe.
• Created more constants (ie: stageWidth and stageHeight) and I tended to create temporary ints and numbers to avoid checking the same variables over and over (ie: within boundary checking, I would check the Red Guy's position for each border check...you just need to check the ONE position at 4 boundaries...not constantly pull the RedGuy.x and RedGuy.y position)

This seems to be the best working solution, again 50 guys is as much as I'll go, in fact, it would be more efficient to have 50 guys for the level, but they come in waves of 10....so that means ill have 10 guys and then reuses those 10 guys for the next 5 waves. Cool eh?