We're back, hurray!

Hope you all had a good Christmas and got lots of new things to play with ( Left 4 Dead was the best thing Santa gave me, it's the best marriage of "proper game" and multi-player I've ever ever seen. Everyone is going to copy that soon and just ditch the single player mode all together ).

I'm still in a holiday frame of mind, so the posts here may be sporadic as I alternate between working, and eating crap food / watching tv ( I think Olli's the same too ).

There's a new update to X. This is more of a "presentation" build, where I just can't be bothered to try and code anything clever.

The pause mode is in, which is always a nice thing to have done. To try and make it less drab, there's a bit of eye-candy in there, which is a Lorenz Attractor and was ported to as3 from the code at the always excellent Levitated ( I had played with this a couple of weeks ago using setPixel, and just wasn't happy with the results. Rather than let it go to waste I used the bubbles from the depth of field vector effect in 651 and a bit of blur and the add blendmode along with the old faithful infinite bob effect, and it looks ok-ish now. One thought that came to me was the code may be handy for running some types of baddies, could be quite a nice movement pattern and wouldn't require me to think of any more code ).
One thing is that I don't kill the animation during pause, so asteroids keep spinning, explosions keep exploding. This is because the use of movieclips is only a temporary measure, I'm going to wait til we've got final assets before ripping that code out and using tilesheets instead.

The other major chunk of work done is the stats / medals. The medals needs some images drawing for them, and then code to actually trigger them in-game, but all the internal guts is in there. The stats I think are done now, which is cool. Just don't get too attached to them, as every new build will reset them.
I've also added some stats to the level complete section ( I've been brainwashed waiting for things to load on the 360, where they display tips / stats to help you forget you're waiting ) which I'm really happy with.

Following on from a comment from Tonypa, the current level is now displayed, and a level progress bar. I've noticed a lot of casual games show the level progress ( Zuma, Luxor2 etc. ) and it's a simple nice thing to have. It's maybe not that useful now, but perhaps if the asteroids were to come in waves later in the game ( That's a clue btw ) ?

Squize.

Merry Christmas everyone!

At this time of year we'd just like to thank you, all our beautiful constant readers and our sexy newer visitors, for helping make this blog what it is. Without you we'd just be talking to ourselves, and I'm no doctor, but that's got to be a bit mental hasn't it ?

So thanks a lot for keeping us sane, it means a lot to us.

Turkey, tv, unwanted gifts, eating until your eyes bleed, visiting relatives when you just want to play on the xbox, something about the little baby Jesus, a big fat man breaking into your house in the middle of the night, paranoia that you can smell burning every time you turn the tree lights on, getting a card from someone at the 11th hour when there's just no way you can get one back to them on time, wrapping presents far too late and making a really bad job of it, having to spend Christmas with relatives and their weird not the way your family does it rules ( "We don't open the presents til after lunch" ), it's just all good isn't it.

Have a great one,

Squize & nGFX
x

(ps. edited by nGFX):
So Squize was done with posting a good deal earlier than me, so instead of having a second post I decided to add to this one...

If you're not quite so much into Christmas (like me, although, only the stress before it spoils it for me as early as November) here's my usual:

Happy Hogswatchday!

"ER...HO. HO. HO."
-- Death makes a career move (Terry Pratchett, Hogfather)

We're really really pleased and proud to present a guest post from our good friend Pany at the oh-so-talented UrbanSquall ( Developers of Battalion:Nemesis amongst other great games ) not to mention the words behind the always essential GamePoetry blog.

Enough of my introduction, on with the show:

---

Zombieland: Bonesnap Boulevard


Intro:

This is a really late post-mortem for Zombieland which was completed at the end of the first quarter 2007. Zombieland is an endless side scrolling shooter written in ActionScript 3.0. The game was written with the Flash IDE 9 Alpha, and was completed before Flash CS3's official release date. The game is still playable at http://www.newgrounds.com/portal/view/378688

Zombieland was essentially a critical flop. It didn't garner enough eyeballs to warrant a sequel, and despite some really creative ideas, and the flawlessly crafted graphics, people who played the game had a hard time coming to grips with the flawed weapon implementations, gameplay experience and jarring audio. It was a fun project that was executed in a very short time period, but a few missteps ultimately damaged the gameplay experience considerably.What Went Wrong:1. Audio. The music in the game is at too high of a volume, and the compression was set too high. The result is that long before you ever see anything approximating a mute button you are assaulted with an overwhelming blast of scratchy static-riddled music. I suspect many potential fans of the game were lost in the onslaught of those first few obnoxious seconds. The great sadness is that the music is actually pretty good. A few minutes could have fixed these problems very easily.

2. Questionable design choices. Random is not fun. The game uses a very basic algorithm for deciding what sort of enemies to spawn and at  that frequency. I think this only barely worked. Static levels would have taken longer to produce, but would have been inherently more interesting. Combined with other design blunders, like the constantly moving forward main character, the weak default weapon, and shoddy collision detection, Zombieland scared off most players long before they could come to appreciate some of the funner aspects of the game.
I'd say our rushed development schedule was partly to blame here, but it was also partly a lack of objective oversight.


3. Syncing gameplay and animations. In Zombieland, the majority of events are queued off animations. Firing, reloading, taking damage are three examples where I let the speed of the action be determined by animations. This could have been fine, except it clashed horribly with the fact that the character is supposed to be constantly moving forward meaning we had to do ugly tricks to maintain the illusion. The result is that most core actions in the game are very unresponsive which multiplied the negative effects of poor collision detection.
This was just a naïve misstep that was avoidable with a very simple design change.


What Went Right:

1. Graphics. Tim Wendorf, the artist for Zombieland, nailed the visual aesthetic. The 2x look, combined with the slick character designs really make the graphics the best thing about this game. There is a distinct possibility the game got away with its crappy core gameplay mechanics during development simply because of Tim's quality graphics.


2. Inventive zombie designs. Again, I have to credit Tim's warped sense of humor for coming up with some of the more memorable moments in the game, like going toe-to-toe with a wheel chair zombie, or having to face a stream of zombie porcupines tossed by an angry zombie cowboy. The Zamboni Wamboni was all mine, though.

3. Quick turn around. The game took less than 5 weeks of near full time development. We didn't hit any snafus along the way and we delivered the final build ahead of schedule, despite the fact that I was still coming to terms with a new programming language (ActionScript 3.0) and a new content pipeline (bitmap tilesheets). We shipped the game with gameplay flaws that only became clear after the dust had settled and it was too late to do anything about it.
Scheduling wise, though, Zombieland was about as good as they come in terms of everything just coming together right.


Conclusion:

The hindsight of almost two years since the game's release has given me some time to reflect on why Zombieland failed to achieve the success I thought it was due.
The most valuable lessons I can take away from Zombieland, at this time, is that I should avoid integrating slick graphics early in the development pipeline, and instead focus on prototyping and nailing the core mechanic and avoid getting seduced by a pretty presentation.
A part of this is getting more feedback on the gameplay mechanic, especially in those earlier stages, which can help identify issues with a poor random level generation algorithm, or crappy engine limitations, like bad collision detection and animation-based timing dependencies.
I'm hoping fate allows me another opportunity to revisit the Zombieland setting, as I think it was under served by a few key bad decisions that spoiled an otherwise solid game.

Panayoti Haritatos / UrbanSquall

Always a great milestone, when you can play a game, complete a level, die x number of times, read "Game Over" and start it all again.

This to me is when a game is a game, and X(++) has just reached that sexy milestone. Ok, it's not a great game yet, it needs a lot of balancing, and it needs some fun desperately, but it's a game.

Adding the asteroid to player collisions was pretty straight forward, just simple circle to circle checks. I wanted the player to be forced away from the impact, and it works quite nicely. Seeing how the code was written, I used the same bounce code again for when you're shooting an asteroid ( So your bullets actually push the asteroids away slightly ).
It's a little bit weird shooting an asteroid via the screen wrap, as you kind of suck it back towards you, but hopefully shouldn't be too much of a pain to fix.

Next up was making the energy bar decrease. Simple code. Looks nice. Just how code always should be. After that the next logical step was to blow the player up. It's a movieclip, it doesn't get any more straight forward.
That left me with the issue of what to do with the asteroids still on screen, and as I've done in what feels like far too many games, I've added a heat shimmer / wave to the explosion, which blows up all the rocks as it grows.

Another nice simple solution ( I'm not trying to get a rocket into space here ).

From there, it's not much more than

if(--lives<0){
    gameOver();
}

And we've got a game. Sweet.

I don't know how much work I've got in me before Christmas, a couple of days off eating like it's my last day on earth and sitting in front of the tv sounds just perfect right now. Even if I don't do anything tomorrow, we've got a really great guest article to post up, which we're really excited about.
It's nice and apt for this time of year too, I mean Zombies are good all year around aren't they ?

Squize.

Look at me using a term that'll be a hit with the search engines.

What's been happening in the world of X++ today then ? Very very little.

It's not for the want of trying, it's just been one of those days. Yesterday after posting I ran the game through the profiler as I wasn't happy with the performance, and I wanted to see what was being nasty.

It turned out it was the skybox. Lots and lots of calls to papervision classes, and they were taking the vast majority of the actual game's run time. I've had to remove the planet effect I really loved 'cause of performance, am I going to have to do the same with the skybox ?

Yes.

Annoying as hell, but I can't let the game suffer for the background. If I've made the game good enough you shouldn't even be checking the background anyway, so losing a little bit of love isn't the end of the world. So so annoying though, what the hell can we use 3D in-game for if a couple of spheres make it gag ?

Today was meant to be the asteroids > player collisions, with the plan that you'd lose energy and therefore lose a life, and eventually lead to a game over. Once that's in, the game is a complete game, until then it's just a demo.

First step on this road was designing an energy bar. Firstly I wanted a lcd style display around the lives, where each element would "power-down" as you take a hit. Tried it, and it look toilet. Next was a plan about having some sort of arc around the lives and use a mask to show the energy being reduced. I just couldn't even face starting to design that, as I just knew I didn't have much art in me today. Next up was a simple bar effect, inspired by Wipeout Pulse's speedometer.
Looked crap. All the blend mode effects I tried on the score / lives numbers also looked crap.

Some days you could make Angelina Jolie look bad.

In desperation I ripped the energy bar out of Orbs and tinted it. Looks great. There's nothing especially creative about stealing ideas from yourself, but that's the way it goes some days.

After that, the collisions and all that goodness weren't really going to happen, my spirit has been broken. So instead, it was time to sort out the backgrounds after removing the moving skybox.
Without any movement I figured the way to go was to try and make them look as good as possible, like each one is a bitmap done in an art package, and yet make them random every time ( "Procedurally generated backgrounds" makes a much better heading than "Random backgrounds", and to be fair, I think the backgrounds are slightly more than just random ).

The 3D planet is used from the other day, it's spun on it's axis' so you're always looking at a random part of the planet texture, it's z value is also randomised for scaling, and I move the light source around slightly for the phong shader. Also another smaller planet is created, although it's not always shown.
After that, the skybox is spun around too.

We then grab that skybox and plot it into a bitmap ( ie, draw() ), on top of that is another bitmap with our planet(s) in. Depending on the size of the planet we add a blurFilter, a glowFilter and we tint it.

I really don't know what the odds of having two identical backgrounds are, they must really be vast, and aside from the odd "not as good as I would like" looking levels, for the most part I'm really pleased with how they look.

And... I think that's it til Monday, have a good weekend everyone,

Squize.

The subject title is both the longest, and most perfect, variable I've ever written.

If I could do a whole game using vars like that, it would be like writing a book rather than a game. Bliss.

It seems build 4 was causing more people problems. I'm hoping it's 'cause I was a lazy boy and cut a few corners with the transition, which basically meant it was doing too much at once ( Although on all our test machines, not a single issue. Joy ).
Well that's been tidied up now so hopefully no more problems there.

The score is in, I think that was build 4 and I just forgot to mention it. It uses polling, so every x number of frames the game checks to see if the score actually needs updating.
The reason for this is that I'm using a dynamic text box for the score, which is really costly. Rather than update that more than is needed ( It's not the end of the world waiting a fraction of a second for your score to be updated ) I can just save up a couple of updates and then do them in one hit.
That's the theory, dunno if it makes any difference at all in real life ( ie, I don't know how often the score will increment when playing the game at the moment ).

Also today we've now got levels. Lazy, not tweaked at all levels, but you can complete level 1 and go to level 2 and that's good enough for me today.

One thing I've wanted since the start was a nice sexy rotating 3D planet in the background, that's partly why the skybox is there, so the planet has something to sit against.
Dropped it in today, and wow, it looks so cool. Slightly less cool was the massive hit on the fps. I'd added Gouraud shading because without it, it did look a bit of a pig, but the performance hit was too great.

Shit.

Lots and lots of messing around later, and I had to call it a day on that idea, and look for a compromise. That came in the form of still using papervision to create a 3D planet, but to grab that into a bitmap and then overlay that on the skybox.
It's not as good as true 3D, and it's still not quite there, but it's going in the right direction.

As always, all the builds live here.

Squize.

Time for a recap on X development stories.

I posted a 3rd build the other day, but didn't bother blogging about it, as, well it didn't seem worth while. The main thing added was the player movement ( Arrows or wasd ) and targeting ( Mouse ) and shooting ( Guess ).
The particles from Orbs were re-cycled to show the bullets expiring ( They have a certain range before they expire. This is 'cause in asteroids the bullets wrap around the screen, so in no time you'd be over run [ With your own bullets ]. Also with a limited range it means you've got to go in perhaps a bit closer than you'd like to shoot up an asteroid ).
The effect is no where near as pretty as when it's running in Orbs, and it took a fair bit of tweaking to get it is where it's at now, but I'm ok sticking with it for the time being. Unlike Orbs, I think in terms of eye-candy the particle effects are going to be well down the list, so I don't want to pour over them for too long. Yet.

The movement is not the usual asteroids control system, of rotate and thrust ( tehehe ) as our good friend Mark at Blastone released a great Geometry Wars meets Asteroids game a while back ( The very sexy Vectoroids ) and when getting feedback on FlashKit games I was the sole voice of "Rotate and thrust" ( Still quite funny, but I'm 36, I've got to stop finding vaguely rude words funny ).
Everyone else acted like I was slightly mental, that those controls wouldn't work in a million years.

I could get on my retro defending soap box, but the retro way isn't always right. There were a lot of shit design choices back in the day, we just didn't know it back then because everything was new, and because we didn't have good design to compare things to. So, instead of me bitching at the kids for not understanding that it's the way it should be played, screw it, let's make it actually handle better than the original. That's not a bad thing to be able to put in place.

( Also it's how Orbs plays, and I like it, and I like to be able to copy and paste ).

One last thing about build 3, our old friend Phil @ flashgamemaker.com has been a star and reported some issues with it, including a freeze during the transition and a pretty piss poor framerate. I'm hoping it's 'cause he's using FP9 on an old machine running the new IE beta, but I'm still going to have to look at it, the transition could be done better so a bit of re-coding there.
If anyone else is having similar issues, please pipe up and let me know. I remember the good old days of Flash, where it was only the Mac version that would play differently ( And no one really cared about Mac users back then ), everyone running Windows would get pretty much an identical experience. Now there seems to be a lot of "On my machine this happens..."

Build 4, this is more like it. The asteroids are in now. An asteroids AI isn't the most taxing thing to code ( A bit of atan2 and you're done basically ) so getting them in and moving didn't take long.
The current images are all greyscale, so a bit of colorTransform action is added to them to try and liven them up a little.

Three big asteroids moving around with a colour tint on them. Next up was to add the player bullet > asteroid collision checks. Again, Orbs was raided, and we've got distance based broadphase collisions in there ( Which is a perfect way to do the collisions in a game like this ).

Getting a trace saying "hit" is only so much fun, so next up was the ExplosionHandler class. Worked first time like a charm ( Tell me how rare that is ).
The large asteroids explode now after 5/6 hits, I should really add the medium asteroids. Tore through that too ( Almost the same code really, I'm not doing anything really clever here ) and finished it all off with adding the small asteroids.

After less than 4 whole ( ie, an 8 hour working day ) days working on this bad boy, we've got a ship you can fly around and asteroids to kill. That's pretty sweet, I'm more than happy with the way it's going.
The original X even to this day is one of my very favourite projects in terms of development, it took 2 weeks and I didn't plan a thing and yet it all fell into place. If I could turn this around in 2 weeks I'd be really pleased.

More whenever really, bye for now.

Squize.

So I guess a month or so has passed without a word from me, which either means I haven't got something to say or lost interest or something else.

Well, a bit of everything. This year has been a real let down in terms of games, Squize outnumbered me in terms of finished games by far, so what have I done at all?

First the official conversion I've been doing for gimme 5 still isn't really gold (still waiting for the level swapping stuff), which was or still is quite a letdown and has killed a good deal of the motivation I had put into a game of my own otherwise.

Then there were quite a lot flash based applications (not the stuff to write about here) and some .NET based backend stuff.

Oh and I've been doing a heavy "quick fix" session for Ubisoft (yes, that Ubisoft), which ment 3 weeks of 16h days to fix 3 flash games and write a menu in 3 languages (regular readers might find my post related to this) ... I still have to rewrite the third one, but that's another story.
We haven't been involved in the design, but it was quite a lesson for me to make them work at all (read: I got some half fininshed games and a very tight deadline).
If you're eager to take a look ... do it here: Handigo The Game - Ubisoft (first one on the right).

After all that I decided to have a quite long holiday now and start on a game that has been floating around my mind in varoius designs for quite a while now (I did mention that "unfinished" games like my CC port are big motivation killers?).

I doubt I'll do daily updates like Squize, so for now you just get the name (and static screenie of the menu):

(Oh, and did you notice the "Medals"? While writing on Calisto Eclipse I'm setting up something nice for us all ... more to come later :) )

Back to coding now (finally), nGFX

There's a very minor update of X on the X Dev page.

Aside from adding some credits ( I have no sense of priority do I ? Credits done before the game, what the hell is wrong with me ) and finally getting the in-game skybox pretty much how I want it ( Although using a placeholder, which I know I'll come to love and hate having to remove come the time ) quite a bit of time ( Read: Far too much ) was spent on the transition.

Keeping with the TV screen theme, which I think I may have done to death now, I wanted the transition to be a nice distortion / break up effect ( I've been heavily inspired by this After Effects plug-in ).
Part of that, aside from the more obvious static and ghosting / blurring, was splitting up the red / green / blue channels so I could offset them.

With that in mind, copyChannel() got some F1 treatment to see how it works. It's all pretty straight forward, to the point that I'm not going to repeat the syntax here.

What isn't straight forward, is how to overlay the images again to get the original image back. Perhaps it's just me, but I couldn't find one example of how to do that ( Well, I found something using papervision which overlaid planes for a similar sort of effect ).
3 bitmaps, 1 red channel, 1 green and 1 blue. I want to shove those all into a sprite on top of each other to get the same image that I started with. To be honest, I can't think of another reason to use copyChannel() off the top of my head, so I thought I'd be tripping over examples.

But no, one PV3D example like I said, and nothing more.

Cosmic.

The solution ? BlendMode.DIFFERENCE. By applying that to each of the 3 bitmaps it works a treat. Hopefully this will help someone out one day when faced with the same problem.
It amazes me at times how some things are still so tricky to find out about in actionscript.

Squize.

I'm starting a little experiment today. It could either prove to be something quite cool, or I'll really fall flat on my face with it. Lucky that I don't mind either way really.

Rather than doing a diary style collection of posts about a specific game's development, I'm going to post daily builds. Every day I work on it, even if it's just to tweak a sprites position quickly 'cause it's bugging me, I'll upload that new build.

Now this doesn't mean I'm going to be working on it every day. There aren't going to be a nice collection of sequential posts here until it's done. This is a personal project + Christmas is coming up, and life just isn't so smooth as to allow that.
If I get an urgent job come in then this is on the back burner straight away.

Also if you stick with this ( Never mind me sticking with it ) you're going to see versions which crash, versions which are buggy, versions with no preloader so you're looking at a blank screen for a while. It's a true game in development. I'm not going to fluff it up for you guys, or put some spin on it and work 8 days on it and then pretend that's just 1 day. It's going to be the same as that game you've got in development on your hd, with all the traces that say "Sprite collision failed, wtf?" and all the nasty things that you'd have to hide from the clients build.

That's the caveat out of the way. What are the good parts to this project after all the negative ? I guess that's down to you guys. If you find it interesting then the blog is doing it's job.

X. That's the game. It's an old asteroids clone that I did years ago ( It was my 2nd ever complete game, 2003 some time ? It was part of the "Majestic Trilogy" of games. I'll dig out a link for a future post ).
I've already done a reskin of it, X+, but for some reason that has never seen the light of day. I was looking at it recently and realised it's just a bit too dated now to use, it's as1 so publishing it for F8 so I can use the blendModes in there is really a lot of trouble, so it's either release something that's not as good as it should be, or re-writing it in as3. X++ it is then.

I'm weird when it comes to coding. I know a lot of developers just like to get in there and get the engine working, and then work back from that. I'm very linear, like a bad fps. I need to start from the beginning, the title screen. It's important to get that look & feel in place to set the tone for the rest of the game.
So that's what we've got, a title screen. There are buttons that rollOver, but don't lead anywhere. The background image is a place holder as we're going to have a flv running there instead ( I did have a flv to test in place, borrowed from here ( Click the video button ) but it bumped the file to 9meg, so it's been reduced to a static image until we get the final render done ).

Enough words, here's the front-page for the xtreme coding experiment

More soon, although I'm going to try avoid saying what's coming, 'cause it usually falls through and I go off and do something else.

Squize.

As a game studio, we find a percentage of job leads fall through. It's not 'cause we're bad, or too expensive, or just plain cocks. It's just the nature of the business.

Sometimes we turn work down ourselves because of numerous reasons. I don't think we're unique in any of the above, it just happens this way sometimes.

We were asked a couple of months ago if we wanted to work on one of the best IP's you could ever get to work with ( Roughly around the same time we were involved with some other great IP, the very definition of classic retro gaming, but that one fell through too ), but unfortunately for various reasons it wasn't to be.

Seems it's live ( Although I believe in beta ? ), and it goes by the name of PlaySega.

Is this a huge game company showing it's belief in Flash gaming as the long touted future of casual gaming, or is it the desperate thrashing around of a dying giant looking for cheap way to target it's brands ? Is it even both ?

Anyway Sega understands Flash exists for more than navigation, and there is an official Sonic game in Flash ( That's the one that got away... ), so it's all got to be positive. Right ?

Squize.

Our first project with Brandissimo is finally live, and sitting on the NFLRush site.

Just to caveat the excitement a little, the NFL site requires a sign up, and I'm sure it may be a subscription service ( Read: You've got to pay ) [ EDIT: Nope, its free, just needs a sign up. Sorry about that, and thanks to Andy for pointing that out ]

To compensate for this, I'm just going to post some screen shots, a couple from the intro movie, and one in-game one. Then in conjunction with the development posts ( For some joyous reason I can't look back at old posts and be logged in at the same time, which means I can't just simply give all the dev. posts a GMM category and then just refer you to the tag cloud. Cosmic. So instead, the development ran from the start of Sept '08, to the 1st Oct. Cutting edge blog technology in all it's glory ) you can use your imagination to play the game.
That's got to be better than actually playing it hasn't it ? I mean you can imagine any old mental things. For example, I'm imagining that I had the time to scroll the screen rather than just making it flick...

A really enjoyable project, some great assets to work with ( I'd never have opted for that art style in a million years ), some great people to work with at Brandissimo and quite a nice little game at the end of it. All good.

Squize.

December already, it really does fly.

I was chatting with our mate Jeff @ 8bitRocket the other week about function pointers / state machines and I thought it may be useful to quickly write something up about it here, as so much of my code relies on them and they do make life easier.

private var mainFunc:Function;

That's pretty much it.

I'm guessing all your routines have some sort of mainloop. Either you're old school and that's running on an enterFrame on each mc you're moving about or it's a public method in an object which you loop through and call every frame.

Let's take a space invaders mainloop as an example ( Psuedo-code ahead )

function mainloop():void{
  if(thisInvaderIsDeadFlag==true){
    return;
  }
  if(areWeDyingFlag==true){
    if(sprite.currentframe==endOfExplosionsFrame){
      thisInvaderIsDeadFlag=true;
    }
    return;
  }

  moveInvader();
  testForShootingAtPlayer();
  testForBeingHitByPlayersBullet();
}

That should hopefully be straight forward enough. In real life we wouldn't want to be testing for thisInvaderIsDeadFlag every time, we'd just remove this invader from our array of active ones, but this is just an example.

Now check this out,

mainFunc=mainloop_normal;

function mainloop():void{
    mainFunc();
}

function mainloop_normal():void{
    moveInvader();
    testForShootingAtPlayer();
    testForBeingHitByPlayersBullet();
}

Here we've set up our function pointer to point to mainloop_normal, and then we just call that one method in our mainloop() method. Cool so far ?

Now we're not checking to see if the invader is dead, or if it's exploding. That's good, because by default the vast majority of the time neither of those are going to be true, so it's a waste to check ( It's like waking up every morning and seeing if it's your birthday ).

At the moment it's more of a function pointer than a state machine as such, so next up is why doing it this way is so sexy...

function testForBeingHitByPlayersBullet():void{
    if(playerBullet.hitTest(thisInvaderSprite)){
       thisInvaderSprite.gotoAndPlay("firstExplodingFrame");
       mainFunc=mainloop_waitingToDie;
    }
}

Here's our testForBeingHitByPlayerBullet method from the main loop. Imagine that's just doing a hitTest, the invader to the player bullet. Bang, it's a collision, but instead of having to set our areWeDyingFlag from the original example, we just change the state machine.

function mainloop_waitingToDie():void{
  if(sprite.currentframe==endOfExplosionsFrame){
//Kill this invader totally, ie remove the mc
      mainFunc=null;
  }
}

In effect, no extra checks are needed every frame, we're only running what we need. We've got the advantage of a slight performance boost, but far more useful than that is the flexibility this gives us.

Say for example you want your invader to teleport in now, at the start instead of:

mainFunc=mainloop_normal;

we can now alter it to,

mainFunc=mainloop_waitingForInvaderToTeleportIn;

And run the code there waiting for your cool teleport effect to finish, and then just alter the mainFunc to carry on with our flow.

Running your code this way means you can chop and change states without having to have lots of extra conditionals in your code ( If the player is teleporting in, but that teleport tween isn't at frame 10 yet, then don't test for collisions with the player bullet etc. etc. ).

Any questions just hit that comment button,

Squize.