Runeblight Development Update #2

Hello again! Sorry for the delay between posts. I was sick for a bit, and so my “every other week” thing almost immediately went down the drain. That being said, now that I’m back, we’ve been making some good progress.

We’ve got some really great sounds implemented. Definitely more to come, but here’s a few examples.

Had to do a bit of reworking to get footsteps to sound right. The game distinguishes sounds into two main categories, sounds that play everywhere with no distance falloff, “UI sounds,” and sounds that play in the world and have falloff based on distance, “world sounds.” The first name is a bit disingenuous, because I’ve found myself more and more needing to use these sounds for elements that while seeming like they belong in the world, need to play at their max volume at all times. 

Footsteps originally played in the world, and I placed them right at the player’s feet. This seems natural, but it ended up creating this weird effect where the player would hear their footstep behind them as they walked or ran away from it. The obvious solution was to increase the min distance of the sound, so it sounded like it was close even if the player started to walk away from it, but since the game has lots of movement enhancing abilities, I figured the easiest solution was to play the sound at max volume at all times.

Other than that, I’ve been working heavily on networking NPCs, as well as working on NPC AI and pathfinding. Unity has out-of-the-box navigation, and while not too different from what I’ve implemented, I thought there’s provided a little less flexibility, while also being a little cumbersome.

While still in development, I decided to take an approach more similar to the Source engine. In Source, the mapper places nodes, which NPCs and bots use to find valid paths between points. NPCs can walk on most surfaces the player can, but the nodes are mostly use to generally help guide the NPC through tight spaces, or give them an indication on optimal routes and good places to stand when performing certain tasks. I take a similar approach, although instead of having the NPC form connections between nodes at run time, I make them predefined, to makes things a bit easier for myself, as well as allow the mapper to be very explicit when it comes to helping guide NPCs. While different NPCs will exhibit different movement behaviors, most have one thing in common: When they need to find the player, they will have to navigate a path towards them.

The NPC dynamically finds good starting and end points, and then uses A* to get an optimal path, like most games.  The red lines you see are the enemy looking for good starting points. A point needs to be close, and visible, for an enemy to start on its path.

When it gets to its destination, if it still can’t see the player, it updates, and looks for another path. The overhead on this is so small its negligible, and I’m thinking it’ll stay that way even when there are lots of NPCs. 

It still needs a lot of work. Right now, it’s pretty rigid, it’s easy to confuse the enemy by making it take weird paths and then ducking out of its line of sight. The NPC will sometimes do things like backtrack a little when the start node appears behind him, but overall, I think it’s a good start.

That’s it for now. Hopefully I’ll be able to keep up a bit more with the updates. Tune in next time for a devlog where I talk about the sun.