Giving Vine a quick try out, as it may be handy for posting quick clips here.

If it's all gone to plan that should be the flamethrower in all it's too bright to capture well on an iPad glory.

Squize

Work's going really well on level 5, only started it this week and it's coming together already.

This is what you guys will see

This is what I see.

I've managed to speed up a lot of the plotting routines this past week or so ( I've moved over to ASC2.0 which is fantastic, it feels like it's not actually compiled any changes it's so quick and it reduces the file size a bit too ) which means I've been able to drop a parallax layer in level 5.
( Also after my previous post I looked at the level construction times. They've been speeded up like a billion percent. Where the larger levels could take up to 5-10 seconds to plot they now take under 2 ). 

Also we've got this nice lens flare effect which you can kinda see in the top grab. I guess you could call it a HDR effect and really alters the whole lighting of the level. Maybe I'll try and grab a clip of it as it really is one of those effects you need to see in action.

Ok that's it for today, someone's got to do a million white rectangle collision boxes for this level.

Squize.

Look at that for a SEO type subject title, I hate using them and would rather revert to something stupid / flippant, but this is meant to be an actual useful post, so I guess I shouldn't obscure it too much.

We've been having problems with FullScreenInteractive in Chrome since first adding the feature to Outpost 2, it just scaled up wrongly and was basically broken ( You can't even seen the accept / cancel requestor properly ). Damn you PepperPot player and your added weirdness. So here's a couple of gotcha's for you to hopefully save some pain.

Firstly stage.allowsFullScreenInteractive isn't what you'd think. My idea was I'd hit that value up and if it was false then don't bother displaying a full screen button as an option. That would be too simple. Apparently that only returns true if you're already in full screen interactive mode which makes it totally useless as far as I can see ( You could either read stage.displayState or just set a flag in your own code as you kinda know when you've gone full screen ).

Ok, that wasn't really the bug, just a crushing disappointment connected with the whole mechanic. Here's the actual money shot,

"The fullScreenSourceRect property can only be set when Flash Player or AIR is not in full-screen mode. To use this property correctly, set this property first, then set the displayState property to full-screen mode."

source: http://help.adobe.com/en_US/as3/dev/WS5b3ccc516d4fbf351e63e3d118a9b90204-7e31.html

When working in either full screen mode you really need to use the fullScreenSourceRect property to enable hardware acceleration. This is just a rect you set to the size of your normal stage, once done your content flies along ( O2 runs the same full screen as it does normally ).

Turns out this was the problem, when I removed the rect call it scaled up correctly in Chrome, but ran like a dog. Let's try adding the rect setting after going into full screen interactive, yeah we're ignoring Adobe's rules, fuck the man.

Hey presto, it all works. The requestor dialog isn't quite central, but it's the same on Safari and to be honest well down the list of things I care about, as I'm sure that's a Flash quirk that I can do nothing about.

There you go, hope that's some help,

Squize.

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.

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. 

Entered Ludum Dare for the first time this weekend. I've done 48 hour game jams before, years and years ago on FlashKit ( Actually won one ) and I just fancied the challenge, plus I actually wanted to just complete a game. It's been so long ( The downside to working on Outpost 2 ).

The Game:

The theme was "Minimalism", which when you've got to do your own art isn't a bad theme. I was awake when the theme was posted on Twitter, which was at silly o'clock UK time ( 4 am ? ) and I just went to sleep thinking about it.
What I came up with was a world that was going to be very clean and sterile in iso. Lots of cubes, cube particles, cube sprites. It was inspired partly by Marble Madness and an old Spectrum game ( Which my mate Bas mentioned when we were chatting about it, which was strange, as it's quite an obscure reference ) Quazatron.

Which in itself was an iso remake of Paradroid ( My favourite game ever ). The clean visual style I had in my head was of an unreleased official remake of Paradroid that just looked stunning.

So lots of clean white iso lines.
That was the look & feel sorted, next, the game play. I figured with the theme the player should be making the game area minimalistic, bringing some order to the chaos. Another one of my favourite games is WizBall, where you have to collect colour and paint a drab world.

So let's do the opposite of that, lets position the player as almost a baddie, turning a beautifully coloured world to a nasty plain drab one.

It just needed a name. R.G.B was an early thought ( I'm glad I didn't go with that, http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&q=rgb ) but felt a little obvious.
It was all about Colour, and keeping with the theme I stripped that right down so it was just C... ( Written in game as C [Dot][Dot][Dot] ).

What went right ?

Let's do this one first, save the nasty 'til last.

The look & feel turned out really well. I knew I couldn't spend too much time on the assets. I can do pixel art to a degree, but it takes me forever.
I lost a ton of time trying to get the colours plotted correctly. I had this vision of undulating hills with stunning shades of pastel colours all overlapping creating lots of different hues ( I was thinking of a pretty version of the Red Weed stuff from War of the Worlds ).
Instead what I got was this:

It took ages on the last day to actually mix the colours as I wanted, and even then I never really nailed the shades I wanted ( Remember, this is the stuff I thought went well ! ).

The level generation worked so much better than I could have ever hoped. I used Perlin Noise to generate the height map,

It took a couple of attempts to gauge the height of each tile sprite correctly so they appeared like a solid wall, but aside from that it went really smoothly, and once I could scroll over it it looked great, I'm so happy with that.

The colour bomb mechanic was a late addition. I realised that if I was going to have lots of baddies milling around I had to either make them slow, zombie like and you'd die just to their weight of numbers, or speed them up but give the player a weapon.
I couldn't have directional shooting, it would have been a massive pain to do with the different heights of the map ( There's no depth sorting going on ) so it had to be a smart bomb type weapon.
I couldn't just give the player three to start with and I didn't have the time to add collectables. But hang on, don't we technically collect the colour emitters ? ( Well we don't, we just destroy them, but it's just a game kids, I'm allowed to break the rules a little ). There's also a certain nice irony that the colour emitters can be turned on their defenders.

For the visual effect it was an obvious thing, let the whole level wobble like a giant water drop. I left the player's tile untouched, partly to keep that slow motion water drop effect and partly because it would have been a real ball ache to move it too.
I abused TweenLite a lot to create the effect and it came out pretty much how I pictured it in my head, which is a rare treat.

And that's all I can think of that went well. The particles the colour emitters ( And the sprites themselves ) look ok.

What went wrong ?

Less grabs this time, I don't want to draw too much attention to all the bad things.

The lack of sprite images. I'm kinda lucky with the theme that it's a slight way out, but I planned to have the player as a metal ball and show reflections in it to create a sense of movement ( I've written a similar routine for Outpost 2 just the other week so it was still fresh in my head ).
But then I realised that it may look weird the player being this detailed sprite in a world where he was trying to make everything drab, so I would need to give the baddies some love and... just out of time with it all, hence the baddies being the same sprite just tinted, which was a crap cop out.

Speaking of the baddies, the AI was the very last thing finished. I had massive issues with it, which I wasn't expecting, as they're ultra simple ( Is the player to the right of this baddie ? Yes, move right. That's it! ).
I had pre-calculated all the possible positions on the map and I was using a simple tweening code to move them, but they'd go mental after a little while. Turns out I was accidentally over-writing my coord values so their movement was getting more broken as the level went on.
By the time I'd discovered that ( On day 3 ) I'd ripped out my tween code assuming that was wrong and replaced it with TweenLite. Now TweenLite is fantastic, but you don't want it running in-game, it's for title screens and other transitions.
The performance is ok on my machine, but it's a beast when it comes to Flash for some reason, it's probably going to be dog shit on a lot of peoples machines.
I also wanted different baddie types. The one really clear image I had when I nodded off on Friday [ Saturday morning ] thinking about the game was having these sand worms type baddies. They'd burst out of tile with a shower of cube particles and arch there way across the screen. Picture Loch Ness style humps, like a snake where you'd see it's arches / humps. Even thinking about it now makes me want to do it.
 

The chunk scroll came back to haunt me. What looked so nice with just the static objects, looked fucking dreadful when I had moving baddies in there. A combination of them smooth moving whilst the player moved a tile at a time just didn't work. It's my least favourite part of the game and in hindsight I would have smooth scrolled the whole thing and added fogging to edge tiles to try and soften that out.

Lack of time / planning. I always just wing things. If I don't know how to do something I just put it on the back burner as there's always a million things to do when writing a game anyway, and then normally my brain just works it out for me in a bolt of inspiration.
You can't rely on that when pressed for time. Every little thing seemed to come back to haunt me, an added complication I wasn't expecting, and that's partly why I missed the comp deadline and it slipped into day 3 making it a jam submission. Which annoyed the shit out of me, I hate missing deadlines.

There are other things, I'm not overly loving the gameplay itself, it's very basic. Also the map was a late addition, then I realised you actually see the colour splat before the emitter shows up on it, so that was pretty pointless ( When I first did the map I did it with each emitter just being a pixel, turns out a pixel on a map is very very tiny and pointless ).
I'm not overly happy with the sounds, they were very last minute and pretty much the first things BFXR spat out at me. Outpost 2 has 212 sounds in it's library, I just couldn't face spending a ton of time on these ones. Again minimalism was a blessing.
One last thing, I decided to give Starling a try as I've been meaning to use it for ages and this seemed a good chance. Ripped it all out Sunday as I wasn't happy with the colour shading on the tiles, so that was a bit of a waste of time. 

Conclusion ( Or the bit you skipped to )

I really enjoyed doing the comp, the team spirit within the community is great. I can't express how annoyed I am with myself for missing the comp deadline, but overall the game's ok. Well rather, there's a good game in there somewhere, I just didn't manage to extract it.
At least it's a playable game and I've got a real taste for LD, hopefully I'll be entering future ones.

If you'd like to play the game / grab the source / vote / comment here's the link:

http://www.ludumdare.com/compo/ludum-dare-26/?action=preview&uid=15712

Squize.

Just a pretty minor thing to share really, but I'm really pleased with it.

With doing the inventory I can now unlock all the weapons, so I've been going through giving them a tweak here and there. The flamethrower in Outpost:Haven was always a bit crap. It didn't look good and ran really slowly, so I've been giving that some love today.

It's 90% more glowy and runs a lot smoother. With the original one we were actually firing out 3 "bullets" at a time and scaling them up, together with the ADD blendMode it was just a combination of ugly scaling and not bright enough. It just didn't look good to be honest, and caused a noticeable slow down.

With this update I've dropped it down to just one flame bullet coming out a time, reduced the amount it scales up by so no jaggy bitmaps on display. Then I've added a red glow bitmap, the one we use on fires now, and put that over the floor layer to create a real sense of light coming off that thing.
To finish it off I've re-used the red smoke effect we use on the flares ( Such as on level 3, and the outdoor levels in Outpost:Swarm ) so it has a slight blurry / smokey ambient feel to it.

If you spin around shooting it still doesn't look the best, as we're having to use bitmaps rather than a zillion particles to create the effect, but in a real game situation I doubt very much people will be doing that beyond their initial play with it when they've first bought it. Straight line shooting like in the grab above works really well.

Squize.

I was just looking through the story we planned out at the start of Outpost 2, way, way back, and it's interesting to see where we've stuck to things and where we've gone off on a tangent ( And also how things were different in my head to the reality ).
So here's the plan for the first three levels you'll have seen in the demo ( Via our Facebook page )

Intro:

20:32

Starts with computer screen. Telemetry data scrolls up, then the word “Warning” flashing in red ( Think old dos like screen. This is a screen on our ship powered by Haily, monitoring Lee’s shuttle ).

Voice over by Lee “The shuttle’s breaking up, I’m going down”. *static*

Fade to black

( This could even be before the title screen ).

Welcome to Haven:

18:14

Same as first level in Haven, just this time you control Jameson. Gets the player used to collecting different items, opening doors and movement.

Staff Canteen:

This needs to be in two distinct parts, the kitchen / storage area and then the eating halls.

The first area we will introduce the info cards / terminal. It’ll be a slow tutorial area, couple of “Tanks” and facehugger aliens. Also a small fire is burning which will push the player out of that area ( “That’s spreading to the gas line, we should really move” ).

From this we’ll go into the long corridor like eating areas, and it’s going to kick off. The sprinkler system goes off, the lights short out, and then I want all the tables / chairs to flip over as aliens burst through the floor ( Picture the library scene in Ghostbusters ).

Along with that the kitchen area will blow up, creating a wall of flame behind the player. Basically I want this to be a forced sprint to the end of the level.

We’ll reach a more secure area when Haily has to hack the door closed for you, so you have to hold them off whilst she does that ( Maybe the aliens attacking you can come out on fire ? ).

At the end of the level we run into one of the mini-bosses from the first game. At this stage the player won’t have the fire power to deal with it, so we’ll let them try for a little while, then a cut scene where something bigger ( Possibly unseen, I’m thinking spider like legs bursting through the floor ) will come crashing in and kill our big bug.

Planet side:

21:06

We’re back with Lee on the planet, debris strewn around, the red flares from Swarm etc.

Haily tells us she can’t collect you as the magnetic storm which caused the shuttle to crash stops her getting too close for an extraction, but that there’s a structure near by.

This is the “Maze” like planet level, simple A>B. I’d like to introduce different baddies on here.

Squize.

It's been a while hasn't it. Client work has been tripping me up so it's been tricky to have a good clear run at O2.

Ok, so where are we at ? Level 4 is finally nearly almost done. Finally. Nearly. Hopefully when you finally get to play it you'll see why it's been such a beast to do, there's a lot of stuff in there.

Because it's a sewer level we've added some new underwater baddie types. They swim towards you really quickly ( Where you can't shoot them ) then burst out of the water really close to you. They're really jumpy things, much more so than the "Red eyes".

Also some various tweaks have been done, the doors don't take as many shots to open if you've run out of keys, as that was just annoying. The pistols power has been doubled ( Hopefully that'll make up for the lack of attachments for it. I know a lot of people requested that, but it's meant to be a weapon of last resort, not something you upgrade ). Also the SMG bullets now move a lot quicker, and I've increased the power too. The armour now works more like it should, it was regenerating too quickly before, it should work more like Halo's, which it does now. Oh, nearly forgot, a skip button on the intro at last, as so many people asked for it via the Facebook page feedback.

Speaking of weapons, added these on Saturday. 

Those are the trip wires I've been wanting to add for ages. You shoot them at any target and they just stick, then shoot out those red laser lines you can see there. Any baddies passing through them die instantly, and then 3 seconds later the whole thing explodes. These are going to be really handy on the Swarm levels.
They're not quite finished yet as I want to be able to attach them to objects, they just work on walls right now, so you'll be able to attach a couple to say a desk, open a door into a room full of baddies in and push the desk in there.
Now I don't know if anyone will ever do that, but I think it's important to give the player as many ways as possible to play with the game mechanics, plus it'll be kinda cool.

As I finished the client work last week, and what with the time of year, I treated myself to adding a little Easter Egg to the game.

There's not going to be any streaming films this time, but you may find this old 1983 classic in there ( It's not really an actual clone of a game from 1983, just part of the mythology ).

It's actually from a prototype ( A failed one funnily enough ) that I did a while back that rather than just had it sit on my HD never seeing the light of day I thought I'd skin up and drop in the game.

There will be a challenge to beat that hi-score btw.

And that's it. I'm in two minds about posting the game with level 4 in via the Facebook page, we may hold off 'til level 5 is in there ( I've got to do UI things before adding level 5 though ) so we'll have to see how we feel about that.

It's all feeling really good, I'm really pleased with how it's coming together. Level 4 feels like the first "Proper" level with the first 3 being more tutorial like and introducing the flipping between points in time / characters. Level 4 is where we open things up and give you actual tasks to do with lots and lots of baddies.

Squize.

This post seems to be somewhat out of context, I fear - but if you follow my posts on google+ you know that I've been working on a racing game.

The problem is that this blog needs writing and updates, but it always seems to be an overkill to post the minor updates (mostly just a few lines)... sometimes these become longer post that would well fit in here - this is one of them and to make it more appealing using an rss reader I start with an image...

Where am I?

My last post on MTR dealt with the fact that I tinkered with the tiles, mainly allowing tiles that are larger than 1x1, which resulted in a shitload of new possibilities and problems.

Map formats: [,]

As always there's more than one way to fuck things up and I think it starts with the way you handle our map data. Lets start with the basic things a single tile needs to know: the tile to use and in this case the way it is facing (3d and all that).

The most obvious choice would be the 2d array [x,y], it is easy, clean and simple. Placing a tile is a nobrainer.

So we can use aMap[x,y] = Tile;

Any basic tilebased tutorial teaches you that. We need to store a direction in there to and as we're lazy right now the 2d array becomes a 3d array, using the 3rd dimension to store tile and direction.

aMap[x,y, 0] = Tile;
aMap[x,y, 1] = Dir.

Still easy enough. I'll skip the part where you use an object to store the data of a tile.

Now we're adding 2x2 tiles to this map and voila: instant fuckup.
You could just store the pivot of the tile and leave the other map slots empty (not good if you need to test if the place you want to store a new tile in is already used or not).
Or you could store a reference to the pivot - either as id (but then you have too look up where the pivot is) or as coords pointing at the pivot (but then you need to find a way to store the coords).

Map format [] and [,]

Another way to store the map is to just store the tiles as sequence and use a simple int[,] as index. The size of the tile doesn't matter that much this way (but it offers it's own range of trouble, again, I'll skip that part unless someone wants to know).

We'll use a simple struct for storing the data (tile, direction and some meta stuff):
aTiles[index] = new Tile(Tile, Dir [, coords]);

and store the index in the 2d map array:
aMap[x, y] = index;

Getting back the tile needs some more code, but it's still readable:
Tile = aTiles[aMap[x, y]];

The neat thing is, for a 2x2 tile I can now add a single tile to the aTiles array and do whatever pleases me to keep the map in sync. I settled with -(id + 1000), as -1 marks an empty space on the map. So a larger tile will be stored like this:

aTiles[10] = new Tile(1, 0, 10, 5); // meta shows a 2x2 tile ..., also storing coords in here
aMap[10, 5] = 10; // pivot
aMap[11, 5] = -1010; // this place is used, but it's not the pivot
aMap[10, 6] = -1010; // this place is used, but it's not the pivot
aMap[11, 6] = -1010; // this place is used, but it's not the pivot 

This way storing the map is also a bit easier as we just have to spit out aTiles as "[Tile, x, y]" (instead of dumping the whole map).

Of course ...

... the drawback of changing the map format is that the whole game stops working unless you have all the methods back in place and working again - and that's what I'll be doing after this commercial break.

And hopefully I'll rember to post the next dev log here .... otherwise you know where to find updates.

nGFX