next »

[Lynx]

This shows route nodes.  Arrows indicate the next node a guard should go to after reaching a node.  If the level is on 'alert' then the guards will follow the red lines instead, if one exists for a route node.  This allows me to simulate guards being extra-careful in their rounds if an alert has been triggered.  Note that alerts may be triggered by story elements, i.e. if you just set off a bomb, all guards through the facility might be put on alert.

Nodes where guards will stop and look around are marked with a grey arc showing the extent of their "sweep", and there are white lines that animate, showing how fast their sweeps will proceed.

I had a think and I'm going to implement objects you can look at/interact with as placing icons on the map when you look at them.  Interaction range may be shorter if you have to be right next to them, and interacting with an object would be used as a trigger for story elements.

If you've played the WebGL demo, did you prefer the arrow controls, the mousewheel, or clicking a place on the map to go there?

[Lynx]

This guard is actually following the route waypoints and scanning now!  Next is implementing AI-type specific reactions: shooting at the player if seen, then heading to their location to scan around if the player manages to get away, before returning to patrol.

On the side I'm pondering what kind of story I want to use for a first campaign.

[Lynx]

Two steps forward, one step back.  I was going to work on the general AI behavior this weekend, but I got sidetracked on the realization that pathfinding was a bit busted in that it was occasionally generating routes that smacked into obstacles.

You can see some debug displays I added of the fixed version: each grid square is 8 units across, but movement is free, not per-tile, so you could be at the edge of a grid square and not see the block nearby.  I now have it return all blocks that could block your passage which are within 8 units.  This seems to work!

So in my next bit of 'moving back, Fixing Stuff Right', I'll be tackling vision cones and making them show where they cross cover obstacles.

[Lynx]

Voila: vision cones that properly illustrate when someone could be hiding behind that crate, but you can't see behind the crate.

And with vision cones being separated out into a separate module, now I can have the AI routine just check whether the player is in its vision cone, instead of having to figure out some line-of-sight algorithm that works against any part of the player, and respects cover and obstacles in the way...  Which was just repeating the work the vision cone logic was already doing.

[Lynx]

A guard expressing its surprise at seeing you.  As with the webgl prototype, the red part of the bar goes upward as the guard identifies you as a foe.  When it hits full red, the guard will open fire.  (not coded yet in the canvas version)

Then I got a yen to change the setting from a boring warehouse to a museum.  I may have to expand the layout to give more room to move, but here's a preliminary version, as an example of how dressing up a set of blueprints can add flavor.

[kamac]

Is this really your first game? 
Looks a bit too incredible.

[Lynx]

I used to work at Mplayer (computer game network, adding multiplayer gaming to games) and There (VR community competitor to Second Life).  These days I work at a $LARGE_COMPANY that does little if anything related to gaming.

I've been poking at various game engines and toolkits like Pyglet for a while, but found them generally unsatisfactory to reach my goal of as wide a distribution and as low a barrier to entry as possible.  I also poked at HTML5 game libraries, but after deciding they didn't meet my needs, I broke ground on 'dot sneak' as a standalone WebGL project in March this year.  Now I'm converting it to Canvas, and throwing in further improvements!

My key to getting further this time, rather than losing interest, has been building a level editor early and using a 'preview' mode in it so I could see results of changes immediately.  Also since it's HTML5 and Javascript, there's no recompile and pushing of code, all I have to do is edit the code, hit F5 to reload, and there my change is.

[Laitch]

A lot of impressive new features... keep going!

[Lynx]

This has been a two steps backward, one step forward sort of weekend!  I discovered earlier this week that the vision cone plotting algorithm I'd been using was severely slow.  Well, of course it was iterating square by square, which works okay for heavily blocked space where you can't see very far, but this was very sub-optimal when dealing with more open spaces where you'd wind up iterating over a lot of empty squares.

Here's the vision cone algorithm, mark 2.



This version has a separate 'edge building' step which only runs when the map changes in some way (doors open/close or the user edits the map via the editor), so all it needs to do in the vision cone building stage is to get all the edges that are close to the mob, then clip the user's view cone by the edges.

Surprisingly enough, it works very well, reducing overhead from 30-50% of CPU time to about 2%.  In addition, I was able to tighten vision around obstacles much better, eliminating the 2-pixel-wide 'dead space' that it had before.

It's annoying to have to spend time fixing something I figured was working, but on the other hand, it works Much, Much Better now.  So, net positive?

[Lynx]

Despite my previous statement, there were actually a few more lurking bugs in vision cone that took most of Sunday to figure out.

I then spent some time improving the pathfinder's ability to find a square close to the target if the target location couldn't itself be gotten to.  You can see this illustrated (with debug mode graphics) below:



"...  Metal Gear?!"

The color coded squares illustrate separate parts of the map.  Any unit within one square of a color group can get to any other square of the same color.  These squares are sized for the vastly oversized unit here; it excludes all the squares where the unit would collide with a wall or obstacle.

So the path works fine up to the last waypoint, then it'll collide with the column and statues in the way.

This ties into guard behavior if they see (and then lose track of) the player in an area they can't get to for some reason.  I want them to get as close as they can to that spot before beginning their 'look around' logic.

[eigenbom]

Saw this in the tig visual map and just played it then, holy moly, this is really quite awesome. I can only suggest that you make the guard movement a bit more human-like, but really this is so sweet for your 'first' game.

[Lynx]

Thanks, but could you go into a bit about how guards should move in a more 'human-like' fashion?

To my way of thinking, it's important that guards move in a reasonably predictable fashion for a stealth game.  You plan ahead, you can deliberately let yourself be seen to pull the guards out of their patrol, or (when I add in-game running creating noise) let yourself be heard, same principle.  Then you can make use of the resulting gap in their patrol route to get through to the next area.

Anyway, I'm not dead!  I've been playing Pandaria, got my druid to level 90, but now that that's done, I can make some time to push forward here.



Here's the first level of guards investigating where they thought they saw me.  This is the same as in the WebGL prototype: they go to where they saw you, then look around.

I haven't implemented level two, but the plan is that if the guards are confident they saw you (full red on their meter) then after they complete the initial scan, they'll patrol around the room before returning to their normal spot.

Due to how I implemented vision cones in the Canvas implementation, they're much better at spotting the player-- now instead of having to see the player's center, if they can see any part of the player, they'll come and check it out.

[eigenbom]

I didn't say that their movement has to be unpredictable. When i played it, the guards walked in a perfectly straight line to their next way-point, then turned a perfect 90degrees at a constant rotational velocity. Maybe a simple model of "intention" and "momentum" would help.

I think the really cool thing about these games is that even though the characters are abstracted to dots, their movement is what communicates that they are people/humanoids, rather than floating blips.

[Lynx]

I see!  Would it help if they paused a bit when making turns?

[eigenbom]

well it's a combination of modelling what the actor is trying to do (in his head), what he actually does (because of human flaws), and how the physical world restricts or acts on him.

you need to take pauses into account, but also little mistakes (like not reaching the exact waypoint before stopping and not turning exactly 90 degrees), and also a bit of stochasticity in the movement . Here's an interesting tutorial which may have some pointers.

[jakomocha]

The game is very interesting! I played and enjoyed the test level. It was way too slow for me while walking, so I mainly used running. Still, I could see how walking could help with sneaking in later version of the game. Also, you are planning on implementing sound- right? It would definitely help the game out. So far, I enjoy the game! Good luck!

[Lynx]

Thanks for the suggestions, eigenbom!  I implemented a slight pause for guards which are following multi-step routes so that they will stop a bit and turn to face the new direction, the pause increasing with the magnitude of the turn.  (this is in the Canvas version I'm working on, you won't see any changes to the webgl prototype)



I don't have a way to generate an animated gif of that at the moment, so instead, a picture of a mild tweak I made to route optimization to smooth it going backward as well as forward.  The debug view is showing the original route (from Pathfinding.js) in red, the white route is the 'optimized' route.

I'll have to think about your other suggestions.

I'm planning a very simple version of sound.  I don't want to mess with having walls block sound, so it will probably just be a handwaved 'walls and obstacles don't block sound', and I'll depict circles ('footsteps') radiating from your character as you run.  That's behind some other features to get done first, though.  So many little things that need to be done!

[eigenbom]

for sound have you considered the following method?

split your world into a grid and tag cell edges with "wall" or "empty"
create a simple sound source "kernel" (not sure what to call it), a 2d array of cells that you overlay over the sound source to get info about how the sound propagates
whenever you make a sound simply propagate the sound out according to the kernel, stopping at walls

codey...

Code:

struct KernelCell {
  int numTargets;
  ivec2 targets[8]; // each cell can propagate sound into up to 8 neighbour cells
};

struct Kernel {
  KernelCell cells[5][5];
};

// create the kernel, the center cell targets all 8 neighbours, the one to its right targets 3 outer ones, etc...
\|||/
\\|//
--*--
//|\\
/|||\

[Lynx]

I use similar grid-creation code for pathfinding and vision cones.  You might have noticed the 'reachable' cells marked on a development screenshot above, they were created by a similar logic.

There are a couple of factors I'm keeping in mind here:

1. Sometimes the player will want sound to travel through a wall, instead of being unheard through the wall.  For example, the player may want to pull the guard out of his route.

2. Having sound be simple radius-based makes it easy for players to see when guards will be alerted, without actually performing the action and seeing the 'sound envelope' that would be generated.

That said, I'll experiment and see what looks good, once I get the guards' investigation routine done!

[eigenbom]

oh yeh, i see, well good luck!