Hi all,

The Silver Key prototype I’ve been working on for two months is out! You can download it at the bottom of this page.

The prototype contains a small section of overworld with a merchant, a small dungeon with 3 enemy types and a boss. I look forward to your feedback.

This prototype contains a lot of firsts for me. It’s the most fleshed out 3D character I’ve built, it’s my first time creating real-time combat in 3D, the inventory system is new, and the monster ai is more complex than any I’ve made before.

Last month, I wrote about the state machine that manages the player. The monsters use a similar, greatly simplified state machine. This is what that looks like for basic enemies:

Deceptively simple, maybe. "Move to player if reachable" is a very complicated bit, it turns out. Let's talk about pathfinding.

PATHFINDING

The red line shows the chompers' navigation

For my first implementation, the monsters moved on a square grid. The dungeon is built out of modular, cube-sized tiles, so I was able to pass that grid to the monsters in order for them to know which tiles around them were walkable. Using that grid, they I programmed them with an A* search. In brief, A* is the name of a search method which prioritizes looking at locations with the smallest direct distance to the target. It starts by combing through every tile the monster can reach and assigning it a direct distance to the player. If there are no reachable tiles within melee of the player, we can assume the player is unreachable and give up.

Here's the explanation of A* I referenced when building it out: youtube.com/watch?v=-L-WgKMFuhE

The dungeon terrain is made up of 1x1x1 cube meshes

This implementation had a few problems.

1. The monsters could only move in eight directions. Unless the monster had reached the player, they would only move between the centers of each square. As a result, movement looked very unnatural.
2. Monsters could not change elevation. They could only see the terrain grid for their current elevation, so if the base of a slope was on their elevation, they could climb the slope, but if the slope led to a tile on a different elevation, they would see it as empty space.
3. If the grid is the only thing the monster factors in, it will collide with anything not on the grid- torches, chests, other monsters, etc. This causes monsters to get stuck endlessly walking into an object.

Two chompers trying to pathfind through eachother (or are they kissing...?)

So what to do? The only long-term solution to #3 is to detect what the monsters will collide with. I hoped to minimize collision detection, as that can get very intensive on the CPU. If every enemy has to check every collider between themselves and the player, that could result in massive slowdown.

I mentioned last month that I’m working in Godot, and Godot has a useful feature for this called NavigationRegions. A NavigationRegion is an object that divides a group of colliders into triangles.

Triangles generated by NavigationRegions based on floor colliders

These triangles can be used for A* pathfinding in the same way you would use a square grid, with some advantages.

1. Since these triangles break down the space based off of adjacent colliders, they allow for much more natural movement than the grid. Large, open areas will have few triangles, and monsters will move directly towards their target. Small, condensed areas will have more triangles and monsters will move purposefully from triangle to triangle.
2. Triangles are not bound to a specific elevation. While a triangle cannot touch more than three adjacent triangles, the vertices can be anywhere in 3D space. This means that moving up and down slopes is simple.
3. NavigationRegions detect colliders within its perimeter, and monsters can access which triangles are blocked when building a path. Having the region track this information means that a large number of monsters can pathfind simultaneously without much stress on the system.

From there, the next important piece is behavior. Melee monsters move towards the player constantly, while ranged monsters keep a safe distance. Eventually, I want to explore more advanced behaviors, such as movement in formation.

PHASE II?

I’m going to keep working on this project. The primary goal of Phase II is to expand combat. The player will have access to two new weapons in addition to the sword. Each weapon will have multiple attacks. I will also refine the dodge, and I intend to make the player less clunky to control overall. To match the player’s new tools, I’m going to give the monsters more kinds of attacks and make them more versatile.

To support the player having multiple weapons, I’m going to add a gear menu. I want gear management to be a core part of the game, so Phase II will contain the minimum viable implementation of the gear system.

My target is to finish Phase II by the end of August. I will continue to post monthly updates to track my progress.

Until then, if you play Silver Key, please share your thoughts. Thank you for reading, and see you in June!