Gaming Your Way

May contain nuts.

Node based pathfinding

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.

Progress. Slow, but still progress

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.

Multiplayer and Outpost

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.

Squize.

Refactoring... Joy

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. 

See, told you we're back on it

Quick update about O2, I'm going to try and post more about it as we've been a bit too secretive as not to spoil anything plus we don't like showing things with placeholder art.

Here's an image with placeholder art. 

Since I started back up on it I've been working on level 4, which is the 2nd Lee level in the game ( You get to play as both characters this time ).

It's a sewer based one, like the one ( Or was it two ? ) we had in Outpost:Swarm, although I've refined how we handle the water this time so it runs much quicker.

That big red thing ( I've called it a gyroscope in the code, I'm not sure it's the correct word though ) is spinning around at a high speed blocking your exit, almost as if someone has sabotaged it to block your way...
Anyway hacking the 4 terminals on the level will reduce the speed enabling you to pass.

The level is taking ages to put together, like they all do, as there are more one off effects in this one and the gyroscope itself was a mare to get running, as it has to use the Nape physics engine for the collisions. In fact it's still not done, we're not having check points in this one like in O:H as I made a real mess of them, so you'll get the temporary forcefield like in O:S. But this thing will kill you outright on contact, and we can't have you regenerating in the room with it, as you'll either be able to sneak past it when the forcefield is up, or you'll just lose all your lives to it, either way is bad.

So my options are:
a) Put an invisible wall in the way to stop you going in there until it's safe to do so.
b) Letting you go in there, but if it kills you, you start at pretty much the location that you're at in the screenshot.

Nothing is easy. I think I'll go for b) as I have to detect if it kills you as it'll still be running slowly even when all the terminals are hacked. It could be nice if when it hits you you just splat. I think we're going to have more blood in this one than the first, if we're going to be classed as adult in content anyway then we should take advantage of that, so it leaving a big circular smear of blood could work well.

And this is what we've been doing every day we've worked on the game basically. Coming up with a cool idea we want in the game, then realising how much that screws things up and becomes a special case, then coding that special case.

More words soon.

Squize. 

Specular lighting

Progress with O2 is still going well, there's just a silly amount to do.

I've spent the past few days swearing at getting bump mapping in the game, creating a specular lighting effect. I think it was worth the pain.

The level without the lighting effect

With specular lighting

I'm really pleased with the effect. I did originally have both diffuse and specular, with the thinking that the outside level floors would look great with the diffuse mapping, but in reality the CPU cost wasn't worth it for the effect, it just didn't look as good as I wanted, so some perfectly good code was killed off today ( But I'm sure it'll make a return, in maybe an iso dungeon crawler, just a wild shot in the dark ).

Squize.

Outpost 2 title animation

Isn't it great when you can just be lazy and link to someone else's blog ?

Construction of the title animation.

Lux has done a great write up of all the steps which go into making the Outpost title screens just so insanely lovely. Maybe one for the artists out there rather than the coders, but getting an insight into good design is always important for everyone.

Squize.

Bye bye Swarm, hello side quests

We have been thinking what we could do with Swarm mode in Outpost 2. I really like the mode, it's just a nice switch off your brain bit of shooting fun, and I think it holds up well on it's own ( Outpost:Swarm turned out much better than I could have hoped ). But, I don't think we integrated it well enough in Outpost:Haven, the idea was to add a little extra to go back to after finishing the story, to give the whole game more value. It does, but it's a little bit disconnected ( To the point that it actually works as a stand alone game with very little story context attached ).

Our thinking with Swarm in O2 was to make them optional "Side quests", kinda. The plan is that even during the game itself you'll be able to select a side quest from the mission select screen and go and have a bit of fun there before coming back to the story mode. Going down that path meant what do we reward the player with for doing a side quest ? They'll get extra XP which of course helps with unlocking items, but is that enough ? We want to encourage people to play the mode, there's no point adding value if only a small percentage of players are taking advantage of it, so we're going to add unlockable perks as your reward which should make a very real difference to the story mode.

So that's the current plan, anything to make this game even more complicated and hellish to code.

Squize.

PS. Should we release Swarm:Facebook this week ? I can't see why not, so we'll do a soft launch some time this week I guess.

First design faux pas*

If you've played Outpost:Haven you'll know on the first level it's a bit of a mini-tutorial where we have both characters, Lee and Jameson.

Very early on we split them up, Jameson goes and takes a lift and goes off to have all the adventures in Outpost 2. For continuity we're keeping that sequence in O2, except obviously this time you play as Jameson.

So yesterday I started adding the path finding code to the main player class, you hit the invisible trigger, the text comes up "Lee, do your thing here, Jameson get on the lift and have your own adventures" ( Paraphrasing slightly there ) and the pathfinder kicks in and moves you to the lift ready for level 2.

No, sweet baby Jesus, no! In the cold light of day I see how wrong that all was. Was I really going to take control away from the player during the opening minute of the game ? What was I thinking. That was truly awful game design, to take the player out of the game before it's even started. So today I'm ripping out all that badness and doing it properly, and writing a blog post to shame myself so I never do anything that bad again, and to hopefully show how what may seem an ok design choice always needs thinking about.

Squize.

*In Outpost2 that is, there have been dozens and dozens of other design fuck ups over the years.

Dynamic shadows in Outpost 2

This is a freshly added feature, so it may yet be ripped out due to performance concerns, but I thought I'd share anyway.

Sexy big shadows

So we've now got dynamic shadows on the player sprites in the game. We can't do anything with the static wall shadows as that would be just too costly, which is a pity, but I'm hoping we can run it on the larger baddie sprites without the game grinding to a halt ( Since O2 has been basically in pre-production for a week and a half now I've been refactoring a lot of the code, such as the particles, to gain performance which should hopefully enable us to add even more eye candy than in the original ).

Let's get our hands dirty with some theory of how it works.

Ah, light probes

On the map we add some "Light probes", which are our light sources ( The actual light images you see in the game / map are just that, bitmap images, so we had to add specific ones. It does have the advantage of giving us more control though ).

When we plot our level we loop through all the light probes and store their x,y and alpha. Then we do a distance test to the player and sort the array where we store all the light probes based on that, so the very first one closest to our player at the start of the level is at the front of our array.

From there we just check every time the player moves their distance to the light probe. Based on that we can set the length and darkness of their shadow ( So it's a little bit of atan2, and some scaleY / alpha code wise ).

The tricky bit is moving from one probe to another. Originally I just checked the next and previous light probe in the list ( Hence pre-sorting them at the start ), but when there were a few together ( Like in the example above ) that could break, which wasn't part of the plan. So I've just altered it that on even frames we check the 5 probes "behind" the current one in the array, and then odd frames we look 5 in front ( The check is just a simple distance check, if the probe we're testing is closer to the player than the current one, then make that the current one ). That seems to have fixed things, although it needs testing on a complex level, which is why it may still yet be ripped out.

The first approach wasn't a dead loss, it's much quicker than the current one as we're only checking against 2 probes, so I've kept that code for the npc and it'll be what I use for the baddies, as I think we should be able to get away with it.

As a final touch the shadow is animated, it's actually a walk cycle from our Knight's Quest game, but with scaling / blurring and alpha you couldn't ever tell. Speaking of alpha, the reason we store each light probes alpha property is because that sets the intensity of the light source, with full 100% alpha being the brightest possible light sources. I'm toying with adding colour information to them too ( It'd be so easy if we could just add a tint and read that, but unfortunately not ), as it would be cool if for example when you're approaching a console the screen would not only let the player cast a shadow but light him up too ( It would make them similar to their Unity Light Probe namesakes ).

There are limitations to this, we're only ever running one shadow sprite as opposed to 4, so in the in-game grab above the sprites should be casting shadows from the other 2 light sources too, but this is just meant to be a bit of subtle eye-candy so there's only so much cpu cost we can spend on them. I'm sure someone on Kongregate will let us know about it anyway.

And that's basically it, hopefully it'll make the cut as it does look cool.

Squize.