Gaming Your Way

May contain nuts.

Is it cheating ?

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.

All kinds of bugs

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.

Mack The Knife is back in town ...

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

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. 

Is it survival horror ?

Every now and again I like to check in on the games on NG, to see if we've got any new comments as I think it's important to maintain a relationship with our players ( I wish I could say the same about Kong, but it usually just makes me angry. Sorry, but it's true ).

Anyway a recent comment really got under my skin, I don't know why, somethings just do don't they.

"It isn't scary. A rather glaring flaw in a Survival Horror game, isn't it?"

Ok, possibly a valid point, so I decided to look into scary games to see what we were doing wrong in comparison. I've finally bought Dead Space, after reading every other comment telling us that Outpost:Haven is so similar ( Oh you crazy kids, we stole everything from Alien Breed, not Dead Space. We're old ), so my survival horror playing is quite limited, the old Resident Evil games and that, so I'm sure there are other examples which will disprove my theories, let it be.

The core themes in survival horror gameplay seem to be:

- Restricted movement. You're always kind of sluggish which creates a feeling of vulnerability, which increases the fear. Knowing your avatar can't parkour up the wall to safety means you're always going to be drawn into a confrontation. They normally add a run button for those between the action bubble times, as you don't want to be plodding between scary rooms, but when you're in actual combat the run is usually pretty ineffective.

- Restricted view. RE and Dead Space use that over the shoulder 3rd person view for a reason. Your own avatar creates tension as it blocks a lot of your view, forcing you to rotate around to see that blind spot. It's the gaming equivalent of opening the big fridge door when you know the beast with the teeth and claws is going to be there when you close it again for a shock reveal.

- Monster closets. A jump is the easiest way to get a shock, the toaster makes me jump every time when it pops, and I know it's going to because I put the bread in there. A lot of games in this genre rely on that, the monster jumping out of nowhere to make you fill your pants. Which leads nicely onto...

-QTE. Tap the hell out of (A) to get away from the thing with the razor teeth, otherwise it's going to eat your face. The only way you can really have monster closets is to allow the player to break free ( And almost turn it into a mini-game ). Basically it's a fix for broken gameplay. If you played a platformer and a baddie appeared out of nowhere and killed you, you wouldn't play that game again as it's not fair. Monster closets aren't fair, so there needs to be a fix for that unfairness so they can keep the easy scares, and QTE's are just that.

- Limited Resources. In the DN8 games I tried to always make you, our sexy player, the most powerful thing on screen. You should always feel like you can kick arse, and it's just the sheer weight of numbers of the baddies which make it a challenge.
In a survival horror game it's the opposite. It goes back to that word again, vulnerability. You're always trying to get more ammo and health, and usually you have to sacrifice something cool out of your inventory to make room. You're traditionally the weakest thing in the game, it's an uphill struggle, good vs evil, Davis vs Goliath. Like most horror stories the end evil is always more powerful than the protagonists, and it depends on a mixture of their inherent goodness and cunning to beat the unbeatable. Survival horror games have just taken that and ran with it.

- Sights and sounds. A lot of games both visually and sonically play on our fears. It's an inbuilt impulse to dislike certain things, a rotting corpse is nasty because it's in our DNA to think it's nasty, it's to stop us eating it and getting ill. Animals that scurry and slither scare us on a deep biological level as we know they're a potential threat ( Even cats and dogs don't like shit like that, that's why they always spin around a couple of times before sitting down, to make sure there's nothing nasty beneath them to sink it's venom dripping fangs into them ). There's a reason bees are yellow and black, we have all these inbuilt hangups that are just part of us ( And for anyone reading thinking "I'm not scared of spiders though, and they scurry" well you're wrong. So very fucking wrong ).
There are quite a lot of key things like this, and a lot of survival horror games play on them, that's why you'll see a lot of baby type monsters in a game, we're designed to protect the young ( That's why kittens and puppies are so cute, big eyes, cute noses, they are things that we respond to and want to protect. Animals aren't silly ) so having the young turn against us and transform into something horrible jars us. Likewise things bursting out of bodies plays on our sexual hangups in a very deep way. These are cliches, but they work as they're built into is. How many games have you played with a creepy child's laughter, or a woman's scream ? These are on buttons for us.

So where does that leave us with the Outpost games ? Pretty much screwed. We're a top down game which doesn't restrict the players view, as that would be cheating. We can't impair your field of view too much as then that becomes a mechanic [ Creating a forced sense of vulnerability ] which overrides the actual gameplay. Sure we can put you in a room and kill the lights, but we have to turn the lights back on before anything crawls out of the dark, otherwise it wouldn't be fair.
Likewise, we can't really use a Quick Time Event when you're under attack as, well, it's not really playing a game is it ? Mashing a key over and over to be released is a crude fix for a bigger problem. So many games which use that approach will have sequences when there are baddies lined up, and if you get it wrong you're button mashing one baddie and as soon as you break free the next one gets you. It's not enjoyable, it's just a sense of relief when it's over, as it means the frustrating part has ended. It's the gaming equivalent of scratching an itch. As we can't ( Or rather won't ) use QTE's, we can't have monster closets as such. Yes we have spawn holes, but they're always pretty well sign posted and they never trigger so close to you that you can't react.
One thing we did do was restrict movement to a certain degree. Your avatar moves pretty slowly, and even slower when shooting / collecting items / bumping into tables and chairs. This was slated so much that in a dot release of Outpost:Haven I speeded up the movement, and in both Swarm and O2 the movement is faster by default. Not a great success there then.

What other tropes can we take away and use in a top down 2D Flash survival horror ? We sort of limit your resources, but not to any huge degree because we can't use a lot of the above we have to depend on that old chestnut, weight of numbers, to create a sense of terror ( Look at any non-Resident Evil zombie game in the past forever, they're dumb and slow for the most part, but there's just so fucking many of them ), and in Outpost:Swarm we take that to the nth degree, that is basically the whole game.

One thing I didn't mention above was the narrative, as that's common in most games ( Even Donkey Kong has some bullshit story attached to it ). If we do that right, and ground it in realistic terms you can relate to, it can help give us some horror for "Free".
The whole Owlmen theme improved the Outpost games a lot, it hopefully stopped it being a battle between various sprites and became a unravelling mystery. There's a reason Stephen King mostly grounds his stories in realistic environments, it makes it easier for us the reader to believe it, and when the shit goes down it could be us there facing off with a clown with silver eyes. That's why we have papers scattered on the floor in Haven, you know by the time we have big mining ships in space like that paper won't be a thing anymore, we'll all have Google Glasses as contact lenses, or drilled straight into our brain. But to try and ground it in something relatable we use paper as a simple short hand for disarray. We've all unfortunately seen the after math of explosions in office buildings, and dozens of stray sheets of paper is one of the images you take away from that. It doesn't fit the time we're trying to portray, but it fits the theme we're aiming for.

Lastly, we can't compete visually with 3D survival horror games, we're restricted by the format we chose, but sound can make a large difference. I was really proud of the sound we had in O:H, it was so much work but well worth it. With O2 we're adding a lot more, I've just the other day added an "Ambient Sound Manager" which plays additional random noises in the background, which really adds to the experience.

Ok, we're at the end, well done for making it this far. The question was "Is it survival horror", and after looking at the genre, it's still hard to say. Cop out answer I know. We don't adhere to all the usual cliches, but I think it's more than a spooky version of Gauntlet. All I know is that one small comment, in what was really a great review by a Newgrounds member, has inspired me a lot. Both to look into the genre as a whole, and to try and make sure you mess your pants whilst playing O2.

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.