make NPCs navigate the world

[yaelatletl]

No description provided.

[hhas]

Routefinding’s an interesting one. We’ll build on top of Godot’s navmeshes, ofc. I’ve already used these in Wheeels—they’re easy enough to set up and Godot’s pathfinding engine does a respectable job of navigating around obstructions baked into that navmesh. With a keep-away margin added around walls, they also prevent monsters cutting corners and clipping through walls; something M1 monsters sometimes visibly did when poly-starved maps constructed their corners poorly.

That being said, navmeshes alone aren’t sufficient to recreate Classic’s NPC pathfinding. With no obstructions in the way, a dumb AI (which M1’s was) will charge in straight line at the player every time—really boring!

One of the things that make M1 monsters movements a bit more sophisticated than “run straight at the player” is that they moved across each poly by starting at the mid-point of one edge and crossing to the mid-point of another edge where it meets the next poly. In rooms where the floorspace was constructed of multiple irregular-shaped polys, this made their paths interestingly indirect and a bit harder for users to predict as they zig-zag across the room while closing in for the kill.

We want to capture something of Classic enemies movements. Offhand, I can think of two possible techniques:

1. We can encode zig-zagging behavior in the new AI so that, finding itself in a large open space, it maps its own indirect route towards the player and follows that.
2. We can annotate important gameplay rooms in Godot, drawing lines corresponding to the original M1 pathfinder routes on top of the new geometry. When an NPC crosses one of these paths on its way towards the player it may elect to follow that graph for a bit, again making its route indirect and interesting.

There may be more tricks we could use; suggestions welcome.

This is something to prototype for Arrival, given how Pfhor navigate the observation rooms in slightly interesting ways.

One more thing: friendly NPCs need to be smart enough not to block doors or otherwise impede the player. Not hard to do and will reduce later levels’ unfortunate Bobicide incidents, for which M1 was infamous.

[yaelatletl]

I think we should go for the zig-zag behaviour, it'll be more dynamic, this way we can experiment with new kinds of geometry oustide a known level

[hhas]

Let’s experiment with both techniques—and any others we think of—and see what works for our particular needs.

Re. dynamism: MCR is a tribute to the original M1 game: a mid-90s DOOM-clone run-and-gun with some literary ambitions. As a tribute, there are aspects of the original we want to replace (low-quality billboard sprites) and things we want to preserve (first-gen combat). We don’t want genius-IQ enemies that adopt sophisticated combat/defensive tactics against us: much of the fun of these old games is being able to blast through waves of dumb enemies charging at us.

I still remember Unreal’s one-on-one combat with an intelligent opponent that leaps and dodges. Unreal’s second-gen gameplay was a true revelation, but that’s not our combat.

We can add a certain amount to mix things up a bit, e.g. so an injured Pfhor sometimes turns tail and runs rather than fight to the death every time. But MCR combat is primarily about quantity over quality, and we want to recreate that mechanic closely as it’s what sells retrogaming.

Another consideration: Bungie’s new game will doubtless use highly intelligent NPCs with modern AI. If we try to make our AI smart and modern too, it will only look second-rate by comparison to theirs. Whereas if we make our AI firmly old-school, we make it a key differentiator between our product and Bungie’s.

…

Re. flexibility: essential, yes! However we code pathfinding, it should only be physically affected by the prebaked navmesh and any mobile obstructions. It must not be coupled to the level geometry as it was in M1’s pathfinder. As you say, we want to use new geometries without it changing NPC behavior.

Our only requirement is that we have some way to bake a navmesh at the end. This is really easy. For Wheeels I passed Godot’s navmesh generator an .obj file containing the map’s floor, set a minimum keepaway distance for its edges, and pressed a button. It’s a great piece of automation: if you can make a mesh of your floor area, you can bake a navmesh from it.