Gaming Your Way

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

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 ).

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

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.

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:

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.

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.

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.

Squize.

I can't think of a more literal title for this post, it says pretty much everything I need to say. In all honesty I'm being a little bit cheeky as I did a google search for "Outpost 2" the other day and there was nothing about it, no screen shots, nothing. Lot's of sites are apparently hosting "Outpost 2 Jameson's Story" which is good to know, I should just play it there and save all this effort.

Anyway, if you do the Facebook thing you can check out the first three levels of O2 < That doesn't help our Google visibility either, here.

https://www.facebook.com/outpostGame/posts/348477208594020

Squize.

A couple of links today.

If you want to go to the Flash Gaming Summit and would like to save 15%, enter the code "Blog_gamingyourway" and hey presto, more money for beer ( Thanks to Ja'Nay for including us in that offer ).

Next up, Garret emailed us about develteam, a social networking site for indie devs. I'll be honest I've really not had time to register / check it properly out yet, but the concept of helping to form teams in a structured environment ( As opposed to just asking on NG, or even FlashKit games, remember when that was a thing ? ) is a very cool idea.
Speaking as a coder it's not easy setting up working with an artist who has the same vision for a game as you, this should hopefully make it easier, and is well worth checking out.

That's it, pimping all done.

Squize. 

Currently working on level 4 of Outpost 2 and I've found a game play issue. It's one of those "Do four things before you can proceed" levels that we used quite a bit in Haven, although this is the first time we've dropped this mechanic into O2.

The problem with these levels types is that we have to spread them out, there's no point having all four items ( In this case terminals ) too close together, which means walking into areas where we throw a lot of baddies at the player ( This level is a mixture of dark / scary and shooty, it's the first really action heavy one ).
That's all cool, but then you have the journey back, which is literally just walking back the way you've come. You've killed everything on the way in, so it's just a trek back to the next action bubble. That's not the most fun thing in the world, although it is nice to be able to admire Lux's graphics.

So yesterday I added some respawn code. You complete an objective and I trigger a load of new baddies behind you. Oh dear, that's cheating.

You'll play some FPS's, like COD or Battlefield 3 and it's almost like you triggered an invisible trip wire, stay where you are and nothing happens, take one step forward and all of a sudden the baddies are triggered. It's fucking awful game design, really lazy ( Compare it to the Halo games, who do it to some extent, but it's a lot more hidden due to the fantastic AI code they use ). I didn't want that feeling in O2.
Also I didn't want the whole "You've cleared that room of baddies, but when you walk back in they're all there again. Like magic" thing either, that's one old school game mechanic I'm glad has been mostly lost to time.

But how is what I've done cheating ? As a player you've done your task, you've cleared out the rooms and done the objective, it's not really fair that the game now shows you you've only done half the job, even though there was no way you could do it all.
It's a price we're having to pay though to keep the game interesting. I've tried to be subtle with it, well as much as I can, but what I think I may have to do is alter some background tiles to help justify it. If I add a hole to the floor which wasn't there when you came in it should help sell the fact that the baddies have found a way to you, rather than just being teleported in by the game play gods.

And that's what I'm working on right now. In terms of progress, half the layout of level 4 is in place, it's feeling good. The gyoscope is finally in and working how I want it to ( It's pretty cool pushing a crate into the room with it and watching it get bashed around the screen ). Still left to do is another baddie type, an underwater one which you can only shoot when it bursts out of the water, I've got to copy the walking in water code over from Swarm, so you move slower and splash around. Then we've got another bit planned for the end, a waiting for the lift sequence. That could be boring, but that's why we're going to give you a sentry gun to play with. Nice.

( Oh, and the art is done for level 5. For now I'm just going to say "Zero G" and leave it at that ).

Squize.

Something and nothing post really, but I'm still messing with the baddie AI, and I think I've managed to code stage fright.

They'll get that close to the player, but it's like they're too scared to move any closer, so they all hurdle up not wanting to make the first move.

( If I wanted to try and actually code that I wouldn't be able to in a million years ).

Hopefully some proper news soon. Oh, and the screen grab was taken in full screen mode in case you're wondering why it's so chunky.

Squize.

... or checking a track for errors

Let's start with a screen shot and jump right into the fun stuff, without messing much with the underlying game (where users can create their own tracks).

[a very simple user (read: me) created track]

As always the problem is with teaching that damn computer to see if this is a valid track before it can be played. So what makes a valid track?

• only one start tile is allowed
• it must be a closed loop
• the AI track must be valid and reach all tiles

Only one start tile is allowed

This is an easy one, loop over the map and count the number of start tiles. Another easy step to prevent 2 or more of these would be to disable the tile after it has been used one time.
I guess not.

What if you decide that the start you placed in the beginning might be better suited just before that bend you added a few minutes before, you could however just delete it, place it at the new location, then fill the gap ... yeah sure.

It must be a closed loop

Now that's a tough one and it took a few minutes to get the right idea. Basically it's using a node based pathfinder (again) and dungeon cells (stolen from Hellstrom.

A screenshot first.

[dungeon cells "applied"]

So each track gets a new property "exits", which is a four character string "0" (white) for a closed exit and "1" (orange) for an open one and as bonus "2" for start tile's start direction. A simple straight track becomes "0101" (N, E, S, W) a corner "0011".

Let's go over all the tiles connected, starting with the start tile ("0201") ... next one is a "0101" and a "0011" (which also change the direction to the next tile to "2" or "South"). While adding new cells to the map we also add a node for the pathfinder and connect it to the previous cell's center.

Blabla bla (new Screenshot)

[Cell'ed up and connected]

At last, we add another node to the start tile when we reach it (and we don't connect it to the first node), just run the pathfinder and see what happens (we should end up on the start tile ...).

We continue with the last check after this entertaining commercial about SEO scum that spams our mailbox with the promise to bring us into the top 5 positions on google - or, if you can't see the commercial, when I've written that check.

nGFX

So the refactoring has turned more into re-coding with regards the baddies.

Due to the collisions being a lot ( Lot ) more robust than in the previous two games, it's highlighted a large issue with the baddie AI. Basically it was cheating badly. Now it can no longer cheat the baddies are too dumb. Joy. So lets make those bad boys a bit smarter, with some pathfinding.

That's a section from level 2 ( It's pretty ugly designing levels ). Those brown circles are our nodes which we're going to use to path find. Luckily this is about as complex a layout as we're going to have in the game, so I won't be killing myself putting a million nodes down every where.

What we do at present is a line of sight check from the baddie to the player. If there is one then he'll head off towards the player as before. Every couple of frames I check to see if that line of sight is still present. If not, then the baddie has to find a different way to the player, and the path finding kicks in ( Before they'd just pick a random direction and walk off towards it ).

It works using a form of Dijkstra's algorithm. When the level is created all the nodes are stored away. Each node is then told about all the other ones and then calculates the distance from itself to the others. The idea is to pre-calculate everything as much as possible before hand, so the actual pathfinding runs as quickly as possible.

Every frame the game works out which node is closest to the player, and sorts an array based on that ( So array[0] is the closest ). I'm slightly concerned about the impact that will have on performance, but it's a pre-sorted list which doesn't change that much ( Relative to the game running at 35 fps ) and it's not showing up as taking that much time, so I can live with it ( Plus I imagine I could skip the check every 5 frames or so without it causing any harm ).

When the baddie needs to find a path it calculates which node it's closest to. I don't check all the possible nodes on a level as that's a waste, if it's more than 10 nodes to get the player then the baddie is more than likely well off screen and we can just pause it. Now we know the nearest node, and we know that the destination node is always closest to the player ( array[0] ) we just run a simple check to find out a path from the baddies node to the players based on the pre-stored distances. This is stored in a Vector of x,y coords for each node, and sent back to the baddie. It then walks from node to node until he gets to the end and then he'll start again.

As you can see there, node 0 is the one which was nearest to the baddie, he's already got there, and he's moving down the path.

Now it's not fool proof, he won't always find the shortest path, but to be honest I'm not worried. The baddies aren't meant to be super smart, and compared to how they were before they've had a hell of an IQ boost. In a perfect world when there are a couple of baddies following slightly different paths it'll feel like they're flanking you.

There's still more stuff to add to the baddie code, it's been a major upheaval, but hopefully it'll be finished in the next couple of days and then I can retro fit all these amends into all the other baddie types.

And that's how we do things at the start of Feb.

Squize.