Gaming Your Way

May contain nuts.

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.


The world in words and pictures

My calendar icon tells me it's Monday  - and July already. This means I've not only missed the start of the summer, but also don't know what happened during the last six month.

All I know is that I started to work on a small scale semi top-down racing game that should be finished in "not more than 3 weeks solid work".


Anyway, the blog needs writing and images.

I've added a new car (see image), coded parts of the backend (for storing tracks "in the cloud" - just to use a buzzword) and a lot less bugs than on my last post. All tiles have been redone, as I needed to split the floor (road) and side (rails) colliders and even a few deco tiles have been added to the editor.

"Right away Michael."

"Look, it's a tree"

What I don't have is solid physics and a working AI. The first is a matter of bending the rules to my favour - which slightly collide with the rules the physics engine believes in. The latter results in parts on the first problem and my stupid idea to control the AI cars using the same principles as the player car, read instead of telling the car to "drive at speed Y" or "turn left X°" I simulate the controller as if a human would be playing. Of course I have a stupid (but perfectly valid) reason for that - playing back things.
Right now I'm brewing a nice mix of waypoint driving, raycasts and player data and it nearly works the way it should, well it works the way it should, but at times it fucks up due to "unforseen" events. 

I'd love to write some more, but just as the weather became fine, there are deadlines to meet ...



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.


Let's see if this works

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.


Spot the difference

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.


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.


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.


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.


Hot, hot, hot

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.


And with this I killed a perfectly working game.

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.


Why does it take so long to make each level ?

I'm glad you asked.

Ok, so each level is designed in the Flash IDE, and is stored in a movieclip ( And each of the elements which go into each layer is a mc too ).

Layer structure

Those are the layers which make up each one. I usually start with "Wall map" which is just a simple traditional tile based layout,

Tiles, tiles, tiles

These are just your typical 32x32 tiles. Obviously you can't make a whole level like that in one go, in real life it's doing a room or so at a time, then testing it.

Next up I like to add the actual wall images, like so ( So we're in the very bottom left of the map here )


Not the most fun image in the world I must admit. I like to then add a basic floor to the level, having the player just walk above blackness when testing is weird, so here we go... 


It's starting to come together, although the next part is my least favourite, the collisions.


Because we use Nape for the collisions I have to place those white rectangles over all the static ( i.e walls ) objects, so the bullets know to collide with them, the player can't walk through them etc.

By this stage we have enough to test a level, with no baddies or objectives or anything.

Let's quickly skip ahead and pretend the level is finished, and Lux is doing his polish pass, which usually involves the floor.

Quite a few layers

Luckily level 2's floor is quite a straight forward one ( Level 4 is hellish, which has prompted me to write this post just to try and justify why it's taking forever ). So all those layers go to create this:

That's better

All the debris, light glows etc. sit in the floor movieclip. Let's tackle the objects layer next.

As you can see, the Object layer contains all the physics objects, such as the desks, the baddies, effects like the fan shadow or sparks spitting out of a broken light etc. The orange circles you can see are the light probes used for the dynamic shadow effect, and the blue rectangles are various triggers ( Such as restarting the ambient SFX, which we have killed in the previous room as we wanted it to be quiet and dark in there, with just the sound of the fan and the level's background hum ).

To be honest I do think to myself quite often, "What the fuck am I doing, this is a Flash game".

I'm going to be a bit lazy and not go too much into the Nodes layer, as I did it to death here ( Basically it's for the baddies pathfinding ).

By now we're in the position to test the level ( Keeping in mind this whole process is really just done a room or two at a time, so we can test every little thing ).

What's left ? The Shadows / Lights layer. Because we're using the IDE we can also use the filters which come with it, so for the shadows I just duplicate the Wall Map mc we saw above and put a drop shadow on it. The lights do have to be placed by hand though, and sometimes we need additional shadows.


The highlights layer in the floor mc have to align with the lights. Also we use this layer to put all those "Wall edges" in which hide the join in the wall tiles.

Only 2 left to go, we're nearly there.

Floor map

This is the layer we use for the foot steps. The player detects which colour he's walking on and plays the correct sound based on that. We also use this a lot in the water levels, as it enables us to slow the player down by being able to detect when he's in water as well as playing the splish splosh SFX.

Bump map

Finally the bump map layer, which we use for the specular lighting effect. Thankfully that's quite straight forward and doesn't need much tinkering with, although it's not a straight copy of the floor mc just in a greyscale ( Which Flash's adjust colour setting does for us ) it's not a silly amount of extra work.

And that's it, that's what goes into making a typical Outpost level. That's not factoring in of course any special set pieces we need ( In level 2 for example, we have the part where you get your motion tracker triggered, the explosion, the running from the explosion sequence, the boss etc. ) and making sure the level is fun and makes sense in real life. We spend a lot of time, Lux more so than me, trying to justify the layout of levels. It can't just be a maze, it's meant to be a real living place. That's why for example in level 2 we have near the kitchen area lot's of little store rooms because you would store the food somewhere ( "What the fuck am I doing, this is a Flash game" ).

It's always a fine line between making a level fun and relatively easy to navigate and grounding it in some sort of realism.

Thanks for sticking with this post so far, it's been a bit of a monster.