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.

The huge refactoring due to updating Nape is still on-going, but it's reaping benefits. I think it's fair to say that level 1 is a 100% complete now. Seeing how level 1 is just about a 3rd of the first level in Outpost:Haven that's not really that big a deal I know.

Continuing on from the previous post about the Nape update I'm going through all the objects a level at a time updating them. So for instance the desks with the PC's on now have a proper screen glow ( That was in the original, but far too subtle to notice ). This had the down side of meaning that if you shoot the desk so it burst into flames ( As desks do in real life ) the monitor screen was too bright, even with the glow effect turned off, so that meant creating an alternative image.

The attention to detail is reaching OCD levels now. I'm only being so self indulgent because I've had client gigs coming in to pay for this.

Most of today has been spent improving the NPC AI, as who knows, there may be some survivors in the game which have to be smarter than the usual aliens. It's collision detection is a lot more robust, no more half in / out of walls.
Also I was using a tile based line of sight algorithm so the NPC could find the player, but it wasn't really accurate. You can see it in Swarm when he sometimes gets confused and shoots at a wall thinking he's got a direct shot to a baddie. That's been replaced with raycasting now, and is much better for it. It's a lot harder to get him trapped behind walls now.

The default weapons have had some collision love too. Before I was having to move them a couple of pixels, test for a collision, move them some more etc. You could see where it broke in the original two games when you'd be shooting a baddie and the impact explosions would sometimes appear at the back of it rather than the front. Those have been fixed now, much more accurate and the code actually runs quicker.

Next up today is making the player collisions more robust. Kong has featured O:H in their Aliens game promotion which has meant I've been getting about 3-4 bug reports every day about the player getting stuck. I've never been able to replicate it, but it's obviously a major issue, so I'm going to tighten that up so I never have to read another "I'm stuck" bug report again. Ever.
It's going to mean quite a bit of moving code around to make it work like the NPC does, but it's so worth it as all these changes can go into making the baddies better when I update those too.

And that's it. Level 1 is done and we're aiming to have this whole game finished before GDC at the end of March and in beta with you guys well before then. Hmmm.

Squize.

Well check us out, both DN8:Pulse and Outpost:Haven were nominated in the shooter category over at Jay's site.

http://jayisgames.com/best-of/2012/shooter/

If you liked either game give them a little vote please, as we don't want to come last. You can vote every day, but don't bother as that's really just fucking mental and we still won't win.

Cheers,

Squize.

PS. Also check out "American Racing", "Hanna in a Choppa 2", "Super Villainy" and "Sushi Cat 2" all in the Action section and all by friends of ours. All excellent games and the links are right there to play them.

I originally posted this on my page at newgrounds, but seeing how it came up in the comments here, and the fact I'm too lazy to write something new today, I thought I'd reprint it here.

So many people ask about a multiplayer version of Outpost that I thought I should write up some thoughts about it.

Firstly, we'd love to do it. It'd rock.

Why don't we just do it then, so many people want it and we want it ourselves ?

Firstly it'd mean a total rewrite of the engine. We use the Nape physics engine for so much in the game, not just the obvious stuff like the crates, but all the walls, baddies, bullets etc. It handles all the collisions, so nearly all the code base we've got would need to be thrown away and we'd have to start from scratch.

Ok, that's not the end of the world, reusing an engine from game to game is quite a luxury anyway.

Next up, and this is the big one, the cost. To do it right I think it would take 4/6 months. That's a long time in development and I'd have to do client work during that to pay the bills, delaying it even more.

Lets pretend that's not an issue, say I win the lottery and still want to make it instead of killing myself with drugs and hookers, we still have to pay for the servers for it to run on.

That means at least one server running in the US, one in Europe and possibly one to cover Asia. That's every month, and good servers don't come cheap, it's not like hosting a website.

That monthly cost means one thing, in-app purchases. If we went the usual sponsor route we'd get a one off lump sum payment ( Hurray ) but that would slowly be eaten away as we pay the server costs. We'd actually lose money every month.

Ok, so we're now looking at making it f2p to fund it. That means we want your lovely money, and lots of it please. What's that ? You've spent money on it and you expect to connect to the server first time, every time ? You expect your details to be secure ? You don't want other players cheating 'cause you've spent your hard earned money and what a turd it would be if you're losing to some one who hasn't invested a penny but instead is just cheating ?

That all means we have to use an authoritative server approach, basically all the game logic runs on the server, the client ( ie the swf of the game you've just loaded on NG ) just passes keyboard / mouse clicks to it. More expense, and a longer development time.

Also a lot of portals really live by the "Free" games boast they put on their layout, which means they don't want in-app purchases in games, which means the game won't spread as much as a normal Flash game would. Poo.

Where are we ? A lot of cost, a long development time and we don't earn a penny until its launched, and depending on how we handle the transactions it could be up to a month after launch before all the lovely cash comes in. Now there's no way on earth that a multiplayer game is going to come out bug free and without balancing issues. It's quite possible that during that month after launch when we're still waiting to earn a single penny from it we'll be working on it just as hard as ever. Working for free isn't the greatest motivator in the world.

What are the alternatives to get it done ? Ad revenue isn't really an option, whilst NG and Kong give devs a share, other sites don't, so we just get the pre-roll ad. The value of that fluctuates, before Christmas ad rev is fantastic, in January it's barely worth bothering with, and yet the server costs are still there.

Maybe we could pitch the idea to a large portal who can handle the server costs, and maybe we could get some money on launch, but it would still need micro transactions as the portal needs to pay for the servers plus claw back any money they may have paid us. We may get a percentage of those, but it really wouldn't be the lions share, and we'd still need to provide support and fresh content.

To finish off ( Finally ), yes we'd love to do it, but it's scary as fuck. It's a huge risk and we don't have the safety net of that lottery win to fall back on. If we can come up with a way to do it ( And not Kickstarter, I'd rather bank on the lottery ) then we will.

The other day I wrote about the gyroscope / fan / blades of death thing. I wasn't too happy about it, I wanted it so if you pushed an object in there, say a crate, the blades would really hit it hard and send it flying.

After an hour or so of should I / shouldn't I, I opted to update the version of Nape I was using for all the physics in the game. That's come as quite a shock, as I'm using a really old version and even though I wrote a wrapper class to try and shield me from pain like this, in real life unless everything goes through the wrapper ( Which is slow ) it means a lot of re-writing.

The current version [ of Nape ] is really excellent, feels quicker and does a whole lot more much easier than before. For example the laser sight on your weapon works by ray casting. We fire a ray out until it hits something, then use some trig to calculate what the new length ( Technically the height ) of the line should be. Using the new version of Nape my 20+ lines of code is now about 3. Sexy.

New Nape also rotates objects around 0,0 rather than having to centre align everything, which means I no longer need to put objects into Sprites to centre align them, I can just add a bitmap to the stage. This means nice performance improvements.
Taking a crate as an example, I'd have a sprite with the actual crate image in it, the fire animation and then another sprite for it's shadow ( So the shadow would rotate correctly ). Now we just add the crate and shadow bitmaps to the screen directly. This meant that I now have to have the fire animation in it's own movieclip, which means updating it's x,y and rotation. A small overhead really, as the fire isn't always active.
The added bonus from this is that I can put the fire animation in a different layer, which is what I've done. It's now in a layer above the shadows, so if you shoot something until it catches fire you can then push that object into a dark corner and it'll light it up. It doesn't sound much I know, but it's right, and it opens up some game play possibilities ( Such as having a dark area where you have to set things a light to find your way through it ).

Ok, this has turned into a dry techy ramble. Long story short, the change has affected around 50 classes, which means going through each one fixing them then optimising them. Painfully boring, but it'll pay off.

Squize.