I added death call outs to the green guys as they die. I came up with mostly movie quotes, I posted some examples here. In addition I tweaked some functionality.
When hovering over a guy, you can now select the base to drag around your character. This was annoying when moving/firing quickly, sometimes you would think you would have your character selected, and he/she wouldn't move. Ahhh...much better now.
Dodges and Throwbacks are more random instead of guaranteed. So these guys are less predictable. But still pretty easy to beat. Wait til you have health and 20 green enemies. Its impossible.
Call outs! A Green Guy's death is more comical. I'll probably add more quotes later, but these funny quotes were what I came up with first. That's the whole point of this, comedy. And fun.
Here is what I worked on tonight, the Green Guy had two different death sequences, so I made a new one where he spins and breathes his last. I should really convert these into PNGs sometime. Be sure to check out my website to play the game in HD!
Snowball shadows were way off. This has been fixed.
Hovering over the health section will turn transparent so you can see what's going on.
Only active (ie: outside the snowfort) characters will have their health displayed. I cannot tell you how annoying it was to get the health displaying properly, including when you removed characters one-by-one from No-Man's Land, the shifting of the health faces was tedious.
Nothing else has been updated. Although this was a lame update, it was a massive VICTORY for me. Be sure to check SnowFare.com to play the game as it was meant to be played, in beautiful widescreen jaw-dropping IMAX format.
This is the playable version of the last two posts. In addition, I have disabled the bomb throws from the greens, and removed regenerates, it just was too frustrating to have to replay basically the same formula. No more health updates either, once a green guy hits the snow, thats it, hes gone. Be sure to check out SnowFare.com to play this game as it was meant to be played, in beautiful HD!
Developed the SnowFort, which made sense since you simply cannot track three characters simultaneously, I can't anyway. So right now, the SnowFort blocks every shot, but I'll most definitely create a health counter for it as well, just to make you get out there. Also notice that you cannot attack from behind the fort, it just wouldn't be fair for the green guys. Have a look at the screenshot below:
And be sure to check out the game in beautiful HD at SnowFare.com!
I am updating the health system, that still needs further tweaking. It was too hard to follow percentages as health, and determining the difference between the characters via tiny icons was not user-friendly. I've updated it to look like the screenshot below, which is the traditional heart system, each hit taking a quarter of the heart. Last thing I'm going to add is that only those characters that are active (ie: behind the snowfort or not) will have their health displaying on the bottom left. Please be sure to check out the game in beautiful HD at SnowFare.com!
I've updated the code to include the two new additions to the team, so far this is just an update to include them. In addition to this, I added a health meter, although this will change eventually. I guess see how difficult it is, the idea is that you have a few lives per character and you only have a set few for the entire game. Don't forget to check www.snowfare.com to play the game in beautiful HD.
Okay guys, I've finally got around to creating the Red Team. I haven't named them yet, and I have to think about what separate abilities to give each one. I'll be implementing them with the new Health Class that I finally got around to making, and I have decided that its too difficult to track 3 guys simulataneously, so I will set the game so that you only control one player at a time, with some exceptions later.
I've created a separte page so that you can play this game in comfortable HD. Well, 900x500 screen, plenty of playing room. Right now I'm working on developing adding health to finally make this a *game*.
I started playing around with animations and created a much better explosion effect. So now you can see Green Guys tossing actual bombs with fuses, and I added a smoke trail too!
Finally got around to animating the Jump Dodges, so once you attack, watch out for the counter attack. Hopefully it looks smooth enough, I wanted to add some animation fixes (ie: the bomb throw), but I figured posting this would be better. In addition, I will add dodges on the ground, and *maybe* ill create the giant snowball. Stay tuned!
So after getting a copy of Pete Rigby’s TimeLineFX, I started to have a little fun with the particle generator. Then after exporting some explosions, I realized that I should be blitting my animations to ease the animation/drawing process, and in turn improve performance. Took quite a while to convert most of this via Blitting methods, and it turned out pretty good. Anyways, I have a few things left to incorporate for this level, so stay tuned.
COMING UP: Just a few things to improve the AI for fallen enemies. Mainly some more dodging techniques. I’m more or less pretty complete with the enemy AI…except for when I introduce items and what not.
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.
Thanks to those who are taking a look at what I put up, it means a lot! At the time of writing, most of the posts on posterous have achieved over 300 views, although I don't understand why the "website count" is just over 600, whereas the post views combined is a lot more. Maybe its one guy viewing my posts 300 times each. If so, thanks buddy, you're my number one fan!
I've been working heavily on level 8, I keep getting caught up in optimization, but sometimes I end up finding better ways to code to make future updates a lot more plausible. Expect a snowball to the face soon.
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.
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!
Well, yes the entire overhaul took quite a while, but I finally got this working really smooth with 50 enemies at such an intensive AI. You can test it for yourself, click and hold the Red Guy and just go nuts. Anyways onto level 6!
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:
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:
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?
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:
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: 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...
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.
I will maintain this blog, thanks to Posterous' Autoposting technique, but there's very little I can do to the theme of this site. Look how brutal it is, I hope I've salvaged something with the header image, and of course, the high quality flash gaming content I'll be posting from time to time.
Alright enjoy the game, remember this is your game too, so you have an idea, send it in!
Still going with the changes, I found so many errors with organization. I think I’ve managed to work it out, and I have it running pretty smoothly, I included 20 enemies for you to attack, and it doesn’t seem laggy.
COMING UP: Level 7 in progress, have guys completely resurrect, as well as dodge whilst on the floor. I think I’m going to start distribution a lot better, as in not just attack the closest guy. This isn't even the tough part yet...Snowforts, items, and bosses are going to be ridiculous!
Hello, you've reached my game blog! Here is where I'm going to post updates and changes to the flash game I'm making, Snowfare! I hope you will send me some suggestions to make the game better!
You can find me on my Tumblr blog, where you can get links to my Twitter, tumblr and posterous blogs.
And be sure to check out the game in beautiful HD at 
Last thing I'm going to add is that only those characters that are active (ie: behind the snowfort or not) will have their health displaying on the bottom left. Please be sure to check out the game in beautiful HD at 
