Gaming Your Way

May contain nuts.

Using Scout to optimise Lost Outpost

This is going to be a bit of a techy post, so if that's not your thing please feel free to move along. Oh, one sec, before you do, here's some Lost Outpost coverage we've had:

http://truepcgaming.com/2013/09/27/given-a-lot-of-love-lost-outpost-interview/

http://www.twitch.tv/coopheroes/b/467397568 ( Interview with Lux plus play through )

Right, let's talk optimisations.

I finally figured out ScoutCC, I looked at it ages ago and was just overwhelmed and not overly interested ( Unless you really need it for a live project it's hard to care ). It's awesome, just so good.

It helped me spot something major with my new sexy ultra quick particle routines. Yes they were sexy, but they weren't ultra quick, the opposite in fact. What I'd done is create look up tables for all the things like movement, alpha speed, scale speed etc. This was to avoid using Math.random() and was much quicker.
The downside being I was creating the look-up tables in the constructor which was causing a really bad performance spike. I thought it would be fine as all the particles are pooled, so it would only be a one shot hit, but where I wasn't pre-pooling enough of each particle that hit was really adding up.

I went a "Factory" route ( I believe that's the correct term, I don't really hold with proper terms. I'm the same with street names, I can tell you where a place is in relation to pubs, but not the actual street name ). I have one class which creates all the look up tables I use and trigger that right at the start of the game so it's pre-populated with random goodness, then each particle just grabs a reference to the data it needs to do it's thing.

Next up Scout was showing that the Movieclips were causing a really large hit. We all know Sprites are quicker than Movieclips, but the difference is really quite startling.
Level 4 was playing up really badly, the water level. It's turns out I'd forgot to call gotoAndStop on all the water clips I make. I have one water object, and it's as simple as simple can be. I create instances of my different sized animation clips ( 13 in total I think ), but without calling gotoAndStop on them all when you first make an instance of them, the timeline runs. So that's 13 clips running on every water object in the whole level ( I can't even estimate how many there are, got to be over 60, there's a lot of water in that level ). Simple fix and it stopped the huge performance spikes.

Right so Movieclips are very costly, and nearly everything is a Movieclip. Hmmm. I went back to my factory method, and created a couple of classes for all the animation for things like the particles ( Explosions being a good example of an animated MovieClip we used a lot ), and the baddies.
These factory classes are basically just a list of public vars pointing to bitmapData, nothing more.

Let's take a baddie as a straight forward example. Rather than having it as MC, I changed it to a Sprite and put a bitmap in it, centre aligned. I then grab a reference to all it's frames ( As bitmapData ) from the factory and to animate it change the bitmaps bitmapData reference ( Ha, what a God awful way to explain that ).

ourBitmap.bitmapData=ourAnimationFrameReferencePulledFromTheFactory;

Hopefully that's a little clearer. Now all the baddies and animated particles ( Debris as well as explosions, etc. ) use this Sprite / Bitmap combo and performance has improved a hell of a lot. We use the "Ghostbusters" sequence in the canteen in level 2 for testing, as we're throwing lots of explosions in there with baddies, it's a really full on set piece, and after these changes it always comes in on time, whereas before it would lag at times.

And that's our little story.

Squize.

PS. I know I promised not to do it too often, but we're still after some Greenlight loving, http://steamcommunity.com/sharedfiles/filedetails/?id=177695239 cheers.

Comments are closed