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.

Knocked it out of the park!

Lost Outpost is up on FGL,

Something tells me the reviewers heart just isn't into it.

( This may come across as slightly bitter, but it's really not, I predicted straight 8's with a 9 for sound, same as Outpost:Haven got, so I wasn't too far out. It's just the pointless nature of the FGL reviewing beast which I wanted to share. A year in development and we fucked up the mute button up, I hope you can forgive us ).

Squize.

Lost Outpost on Greenlight

Just to emphasise the point, just in case the title wasn't enough

Hang on, are you looking to charge us for a free game you've been banging on about for a year ?

No, no we're not. It was always the plan, it's just how could we mention it sooner with the game not being ready ? With it being all but done now it's kinda time to try and push things forward.
What this means is Lost Outpost will still be coming to a portal near you as soon as we can sell it, nothings changed there. What we're aiming to get onto Steam is Lost Outpost: The Directors Cut. That's Haven, Swarm and Lost Outpost in one sexy package. It'll be the definitive version of the game, as it should have been all along.

Let's recap. Lost Outpost is coming out to your favourite portal as soon as possible. Nothing has changed there at all, there won't be any charges, any in-app purchases, nothing.

In terms of the Greenlight page, we'd really like a favour. If you could vote for us and tweet about it it would help us out so much. It doesn't matter if you've only got a handful of followers, if you vote and just one of your friends vote that's two votes we wouldn't have got. It all adds up.

Our page is here: http://steamcommunity.com/sharedfiles/filedetails/?id=177695239

Thanks. Oh, and don't worry, the blog isn't going to turn into a constant "Vote for us", that would bore me silly.

Squize.

Lost Outpost Trailer

So we've got some good news. Let's start with the trailer should we ?

In other good news, the game is now content complete. Thank fuck. We've got another couple of weeks of bug fixing, tweaks and polish ( Plus I've got some copy to write, I've not done the info-cards yet ) but we're nearly there.

Squize.

It's been forever hasn't it

We've been crunching for weeks now, hence my disappearance from here ( It was nothing you said ).

And in saying that, this is only going to be the shortest of short updates.

We posted a new demo to our Facebook page the other day, and have had some great and really useful feedback, so that was well worth the effort of getting a vertical slice in place.
Level design / build is on-going, just to prove it, here's some level 6 action:

I've literally just finished that level off, hence me having 5 mins to post here.

So we're looking at 3 more levels, all of which are already in some state of development, and the Swarm levels, and that should be nearly it game content wise.

We're getting closer...

Squize.

This isn't going to end well

Thought I'd show a quick grab of Swarm mode now it's back in. I don't think Jameson is going to survive this somehow.

Just in case you were wondering, that highlighted area is a "Hardpoint", earn double cash for every kill you get in there.

Squize.

The size of this thing

I'm well overdue posting here aren't I, and in saying that this is only going to be a very brief post.

Currently I'm restructuring the bullet code in the game, which has a knock on effect that I have to update the baddies, and what we call "Noninteractive baddies". These are objects we treat as a kind of baddie so one set of code can handle both, so for example they're triggers for playing music stabs, enabling the flies, the large fan shadows etc. Basically everything which isn't a physics object, like a crate or a desk, or a baddie.

I've just done a quick count up whilst going through them, and there are currently 96 of these objects. That's a hell of a lot of unique things in a game. Also on the subject of numbers, there are 232 sounds in the game, and I can see that rising to at least 250.

This is a beast of a game.

Back to it for me, this soul destroying updating won't do itself. Maybe next time we can talk about Swarm mode seeing how that's back in the game now.

Squize.

The middle of June, so soon ?

I didn't realise I've been neglecting the blog like a prisoner trapped in my basement dungeon for so long ( Best you forget all about that basement dungeon thing ).

So what's new pussy cat ? I've finally added the sentry gun, so all the weapons are complete now.

 

You can see the area it covers ( Still only placeholder art for now ), and it just rotates between those two points unleashing hell on anything which comes into it's line of fire.

I was concerned it was going to be over powered, but it doesn't seem to be. The real test will be in Swarm mode, so hopefully next week ( I've got some client work which needs killing off, which is partly to explain the lack of updates here ) I'll finally get to add a Swarm level in there which will be good for testing.

We got some great feedback recently, and one of the things which came up was the aliens were seen as being a little too fool hardy, so I've tweaked their AI slightly ( Again Swarm mode would be the best place to test this ), so for the larger "Tank" aliens instead of just moving randomly when they are first triggered [ Off screen ] they start path finding towards the player. Not exactly what was meant by the feedback, but it won't make the game any worse for doing it.

The past week, between html games, I've been working on the new terminal.

Lux has done a great job in redesigning how it works. We've stripped out a lot of the filler from the original one ( No Plan 9 From Outer Space this time ) and it's a lot tighter and easier to use because of that.

Obviously coding it has been a complete bitch, but it's getting there. All the weapons are done, so just the supplies left and a large chunk of in-game UI will be ticked off my list.

Installed the new Flash CC yesterday. It's really good so far, it's like what Flash should be. One of the reasons I've been itching to get hold of it, aside from it making the level design much less painful ( On complicated levels, like the planet based level 3, Flash doesn't work in real time. You move up 10px you get the spinning wheel. Hopefully Flash CC will remove that ) is the LZMA compression it offers.
I had a quick play with using Flash CC to build the game using that, as opposed to Flash Builder, and the release build file size went from 12.3meg to 11.7meg, which is a really good saving.

In terms of a rough road map, I think I'm going to be working on the terminal the rest of this week and then hopefully next week I'll be able to add one Swarm level into the game, which is perfect for testing a lot of things. We've also got loads of exciting news that's just around the corner, in fact it's been just around the corner for weeks now, which is maddening. But we're getting closer, and I can't wait to share. It's pretty fucking cool.

Squize.

Big restructuring time. Again. *sigh*

Way back in the days of Outpost:Swarm I wrote how we did the Wingman AI ( Here if you're interested ). Well, that's had to change.

The past day or two I've been re-working it so it uses the same pathfinding routines as the baddies. The reason for this ? Hang on, let's liven this post up with a picture of the new C4 weapon first otherwise it's going to be really dull.

It means I don't have to maintain two pathfinding type approaches, one just for the wingman and another for the baddies, which is a bit mental. Plus we're going to be adding human baddies on level 8 ( The one in the grab above ) so "fixing" the wingman AI is a good template for that.

This hasn't been too painful, but a knock on effect from this is needing to update all the bullet classes. Quite a lot of people mentioned in the feedback to Swarm that they'd like it if the wingman changed weapon, so we're going to add that. The game engine was never really designed for that, hence my big re-write of the code for it today. So the wingman will have access to the assault rifle as before, as well as the pulse rifle, the shotgun, the SMG and the flamethrower ( 'Cause it looks so sexy not to let him use it ).

The bigger plus side to all this is that the baddie humans on level 8 will also have access to all these weapon types. Aliens and humans fighting each other, and you and your wingman, all using different weapons. I can't wait.

Squize.

Level plotting hang

We've got an issue with Outpost 2 with the level construction ( We call it "Loading" in-game but we all know that's a lie, we're just plotting things rather than streaming data ).

On the larger levels it takes forever, and on slower machines it could throw up a script taking too long error. I've always assumed it was creating all the objects in Nape, but I thought I should be good and run a little test. Glad I did.

plotFootMap - Elapsed time: 27
plotWallsIntoMap - Elapsed time: 1
plotPath - Elapsed time: 0
plotBackground - Elapsed time: 4621
plotBumpMap - Elapsed time: 1079
getCollisions - Elapsed time: 63
plotShadows - Elapsed time: 2623
plotBatTriggerMap - Elapsed time: 0
getObjects - Elapsed time: 30
getNodes - Elapsed time: 13

I really wasn't expecting that. Without going into it too much, with the plotBackground method we basically use the draw() command to copy 640x640 parts of a movieclip into bitmaps for the entire level.

Bit of a nothingy post I'm afraid, just thought it'd be interesting to share that you can't really make assumptions about code bottle necks ( The two calls which deal with Nape, getCollisions and getObjects are blindingly fast considering how many objects they have to create ).

Now we've identified the problem properly it's just a case of fixing it. The simple part.

[Update]

So I've split the plotting routines up, and speeded them up slightly, so now the times taken are:

plotFootMap - Elapsed time: 11
plotWallsIntoMap - Elapsed time: 1
plotPath - Elapsed time: 0
plotBackground - Elapsed time: 792
plotBackground - Elapsed time: 748
plotBackground - Elapsed time: 761
plotBackground - Elapsed time: 748
plotBackground - Elapsed time: 774
plotBackground - Elapsed time: 477
plotBumpMap - Elapsed time: 1015
getCollisions - Elapsed time: 60
plotShadows - Elapsed time: 235
plotShadows - Elapsed time: 230
plotShadows - Elapsed time: 449
plotShadows - Elapsed time: 443
plotShadows - Elapsed time: 417
plotShadows - Elapsed time: 275
plotBatTriggerMap - Elapsed time: 1
getObjects - Elapsed time: 35
getNodes - Elapsed time: 14

By splitting them up like that it spreads the load on the CPU so we can drop a simple progress bar in there. Nothing major I know, but it's important to show some sort of feedback instead of letting the player think the game has crashed.

Squize.