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.

Alright I got around to updating level 7, I feel like I optimize this game more and more, and I have yet to do anything spectacular.

Anyways, some things to notice, I included a regeneration effect, so that green guys can go back to full health. Also they have stronger snowballs, just watch them destroy red balls. Notice green balls that hit the ground, they have a "skipping stones" effect, I'm enjoying this quite a bit actually.

In addition to this I made some smarter AI changes, like escaping downwards (instead of up) and a more accurate "in danger" detector.

Click here for embed options!

COMING UP: I wrote down these things to work on next: triple throw, alternate direction of throw, dodging whilst on the ground, and ball catching. I think I want to do an even more sophisticated danger detector, primarily checking danger when balls are in motion -- but that could be memory intensive. We will see.

Yes, I've finally gotten level 6 to work quite smoothly, and you can see that I've included post-death options for the green guy. You can also notice a variety of "yells" that the green guy shouts as you miss. As the development goes on, you will probably get more frustrated as the green guy will be better at dodging and moving faster. I haven't moved onto items yet, but have some patience, it's a goal I will get to.

I'm happy to say that I'm back to where I was a month ago...but I'm staying positive. This is a win for me!

Click here for embed options!

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?

UPDATE #1: Looks like the serious lag issues occur when you hovered over the character...click and hold the guy, wait for it to slow down and then move off the screen with the button still held down. I'm getting closer to solving this...

UPDATE #2: Okay I just posted this, and its ridiculously slow. I have no idea why, it works blazing fast on my local machine, and the filesize is still around 80K. Give me a bit to figure out what's going on.

So after about two weeks of basically restarting this whole process, and optimizing and making my code more efficient, I came to realize that this was probably a dumb idea.

What I should have done in reality is worked on adding to the game, but I became increasingly annoyed when I had about 30 enemies and yo ucould noticeable tell there was a significant lag. And the worst is, its still not complete, I'm having trouble with Mouse Listeners, specifically when you control and hold a main character.

Here's a look at the game so far, and you can see that it lags significantly when you just click and hold a red guy, but then when you release, the game smooths out again:

So you can see that it works great, and its because of a few things I smoothed out in my code:

• I removed almost ALL timers. I had timers for any particular event, for walking, waiting, throwing, loading, getting hit (actually this one still remains), the animation for when a snowball hits the floor, you name it, it was most likely timed. But I did remove them and stop them appropriately, but I have a feeling the "new" keyword was really killing my efficiency...which leads me to....
• Creating too many new objects almost every frame. I don't know why I ignored this, but I had new snowballs being created for every throw, this was a big no-no; I even had a new object being created everytime for when you hovered. Not to mention the footprints about every 20 pixels. So a new footprint X 54 guys X 54 new timers being created (since I faded them out after about 3 seconds, then destroyed them) really puts a damper on your game smoothness.
• Too many checks of unnecessary collisions. I definitely had some objects being checked twice, ie: I had a giant array for all snowballs, and I had to do a check each time so that a green snowball wouldn't react to another green snowball. Brutal. I ended up separating the arrays and really doing a check with green snowballs vs. 3 red guys.
• Overuse of Math functions. I'm talking about the Math (dot) notation. I used it almost every throw for Math.sin, Math.PI, the worst was that every guy had their own independant listener, and that EACH frame would do a Math.abs to determine if they reached a target point. Check this site to optimize some basic math notation! Also I replaced Math.PI with a global variable set to 3.14159.
• Vectors instead of Arrays. I haven't actually implemented this yet, since I'm a little lazy, but I will try it out. I hear this really helps out. And avoid using array.push and DON'T USE SPLICE OR DELETE!!! Try to reuse these objects, but if not, I would suggest setting removing them from the DisplayList (via removeChild(object:MovieClip)) and nulling the array index. Then always avoid checking null indices.
• Reuse objects you already have on the screen. I now only create brand new snowballs if all current snowballs are either in the air, or none have been created yet. So basically as soon as a snowball hits the ground, I set that alpha to 0 and save it for later.
• Use Sprites. I haven't done this either, but creating Sprite sets (or Tile Sheets) and using pure Sprites (which are one-frame movieclips with basically all the event functions) really can help for efficiency.

I have to still update the other levels, currently I'm really stuck on Mouse Listeners. It just seems that when you click down on a character, and hes ready to throw, the gameplay eventually gets really, r e a l l y, r   e   a    l   l    y, SLLLLLOoOoOOOW. But then let go and see the gameplay resume to normal.

I went a little overboard with AS3 Timers. I was working on more level 6 fixes when I came across a massive lag issue, turns out when I have about 30 guys, it starts to slow down (try it, have them follow you around and start moving your red guy a lot) and the smoothness is gone. I wouldn't complain so much, because 30 guys is ridiculous in itself, but I want to obviously add a lot more than just the basic game formula, so it will require more memory. SO I have to go back and see if I can improve it.

As a developer-in-training I've noticed some improvements when I switch some time-based to frame-based animation. So I'm going to convert this to purely frame-based. I was reading this article by Keith Peters, talks about Timers and their efficiency. You should check out his book if you want to get into AS3.

Click here to see the original post for embed options!

I encountered some serious problems on level 6, mainly indexing (you should see how everything is beautifully indexed, I fixed the base too!), and when killing a guy it ruined the organization of the enemies. What a disaster it was too.

COMING UP: Level 7 in the works, I’ll be starting it tonight, should include distributed attacking, and a full recovery for guys who aren’t completely dead. I want to start working on Snowforts however.

See the original post for embed options here