Laserbrain Studios

Games Forum Blog Contact

Blog Posts

A* pathfinding with weighted tiles

0 Comments June 30th, 2014 by Christian Knudsen

Until now, NPCs in Hidden Asset didn’t care whether they walked on the road or sidewalk. When finding a path from one spot to another, they’d always choose the shortest path. But having NPCs walking in the middle of the road without a care in the world is pretty immersion-breaking. So I had to implement some kind of way of having NPCs prefer walking on the sidewalk. This turned out to be much simpler than I had anticipated.

A* pathfinding works by checking potential paths between nodes until the destination is reached. For each node, you store how far you’ve traveled to reach that node. When the destination is reached, you just backtrack through the nodes with the smallest ‘distance traveled’ value. This gives you the shortest path to the destination. For my purposes, each tile is a node.

The distance traveled can just be 1 for each tile. So if you move through 4 tiles to reach the destination, the distance traveled will of course be 4. But because the pathfinding will choose the shortest path, changing this 1 to some other value for specific tiles or situations can have huge effects on the final path found.

One example of this is that I don’t give the same value when moving diagonally as when moving straight. While moving straight results in the ‘distance traveled’ to be increased by 1, moving diagonally increases it by 1.4. This is quite simply because you’re moving further when moving diagonally across a tile that’s a rectangle than when you’re moving straight across it.

A Pascal code example:

IF MovingDirection IN Diagonal
THEN Tile[NextLayer, NextX, NextY].G := Tile[ThisLayer, ThisX, ThisY].G + 14
ELSE Tile[NextLayer, NextX, NextY].G := Tile[ThisLayer, ThisX, ThisY].G + 10;

This code snippet takes the ‘distance traveled’ value (G) of the current tile and applies it to the next tile while increasing it with either 14 or 10 depending on whether or not it’s a diagonal movement (I use 14 and 10 instead of 1.4 and 1 in order to stick to integers — the individual values don’t matter, they’re only important in relation to each other).

However, I can also say that moving across a road tile will increase the ‘distance traveled’ value by an additional 10. The result of this is that an NPC will only choose to move across a road tile if sticking to the sidewalk means that he’ll have to walk at least an extra 10 tiles. Furthermore, I can tell the pathfinding that if there’s a pedestrian crossing on the road tile, don’t add the road ‘penalty’ to the pathfinding.

So I add a function call to the above code. This function returns the ‘penalty value’ for a given tile.

IF MovingDirection IN Diagonal
THEN Tile[NextLayer, NextX, NextY].G := Tile[ThisLayer, ThisX, ThisY].G + 14
ELSE Tile[NextLayer, NextX, NextY].G := Tile[ThisLayer, ThisX, ThisY].G + 10;

IF WeightTiles THEN Tile[NextLayer, NextX, NextY].G := Tile[NextLayer, NextX, NextY].G + TilePathingWeight(NextLayer, NextX, NextY, MovingDirection IN Diagonal);

Note that I only add these tile ‘penalties’ if the pathfinding function was called with WeightTiles defined as TRUE. I don’t add this tile weighting when pathfinding for the player character, for example, as it should be up to the player to decide whether or not to use the sidewalk and pedestrian crossings.

The result of all this is that characters will stick to sidewalks and pedestrian crossings, but if they really need to cross the road and they’re far from a pedestrian crossing, they’ll still choose to cross the road instead of taking a long detour. Here’s my NPCs demonstrating safe traffic behavior (though they don’t care about red lights):

Click to enlarge

Another use for this would be to have characters walk around corpses instead of over them. If there’s a corpse on a tile, just add 100 (or some other large value) to that tile’s penalty.

New name, same game

0 Comments June 23rd, 2014 by Christian Knudsen

This is something I’ve been considering doing for more than a year, and now I’ve finally decided to pull the trigger (pun intended). I’m changing the name of Hostile Takeover to Hidden Asset.

Hidden Asset logo

There are two primary reasons for this name change:

There’s a lot of stuff out there already called “Hostile Takeover”. The Syndicate co-op, a board game, sci-fi books, movies, etc. It’s a name that’s used for a lot of entertainment products, and as such it’s just too generic.

The name also poorly describes the actual game I’m making. I’ve had people think that it’s either a corporate strategy/RTS game or an all-out action game. It’s neither. It’s a stealth game with a focus on puzzle-like level design. Having a name that suggests a different game than the one I’m actually making probably isn’t a good idea.

The name Hidden Asset is a much better fit. It still suggests a game that has something to do with corporations and businesses, but instead of making you think of an action game, it makes you think of secrets and stealth… and conspiracies, which the game will have its fair share of.

The corporate assassins in-game are also referred to as hidden assets, so the name makes sense from that perspective as well. Finally, I’ve been able to find practically no other entertainment products with this name, so that’s definitely also a plus!

So there you have it. Hope you like the new name as much as I do!

New melee combat and weapons

0 Comments June 16th, 2014 by Christian Knudsen

One of the big issues with the previous releases was melee combat. It just wasn’t very intuitive. The way it worked was that you could hold down the right mouse button to block at any time, but if you held it down for too long, you’d start building up ‘melee fatigue’ and wouldn’t be able to neither block nor attack until the fatigue had expired.

This system was meant to keep the player from holding down the right mouse button to block continuously, but it just wasn’t very intuitive. Why, for example, would you build up melee fatigue just by holding up your arms to block a potential attack? It didn’t make much sense. So I’ve completely scrapped the idea of melee fatigue, and instead implemented a more classic system where you can only block when an actual attack is incoming. So now it’s much more a matter of being able to react quickly when your opponent makes a move. I also added Arkham Asylum-styled indicators above an opponent’s head to indicate when an attacking is imminent and you can block.

It also wasn’t clear when you could attack an opponent without risking your attack being blocked and you being stunned for a while. The way it worked was that your opponent would be stunned for a while after you’d blocked his attack, and you could freely attack him while he’s stunned without fearing him blocking your attack. It still works like this, but now I’ve added animation frames to show when a character is stunned and open to an attack.

Here’s a low-quality gif animation to show the new system:

And now I just noticed that the attack indicators should probably be red when you’re stunned… Adding that to my to-do list. :)

Melee combat is pretty simple and that’s on purpose, since combat really isn’t the main focus of the game. It’ll be a lot more about puzzling out situations and using your equipment to avoid combat. But there still needs to be a combat system for when your stealthing fails and there’s no other way out.

One way I’ll be adding a bit of depth to the melee combat system is through weapons. Different weapons can work differently and have different effects. For example, in the above gif, I’m using a knife. This weapon’s special characteristic is that it still does damage (to the opponent’s arms instead of head) when the attack is blocked. There’s also a baton that when used and blocked makes the blocked character stunned for a shorter amount of time. Other weapons can for example deal splash damage to adjacent opponents, or maybe you have to click the right mouse button fast to build up to a single deadly blow? There’s a bunch of possibilities.