I recently added a path-finding base class (fanfare, PathFinder). It’s broken into parts: there’s the algorithm (currently only A* is implemented) and a higher-level class that finds nodes and evaluates costs.
Currently, I implemented a MapPathFinder. It’s simple: if the edge of two tiles has a sharp cliff, the tile is impassable. Otherwise, it’s passable. In the future, I could extend MapPathFinder to include shortcuts, so the player peep will be able to automatically plan routes with shortcuts. (That would a top-tier quality-of-life improvement to RuneScape, but I digress).
The PathFinder creates a Path object, which is a collection of PathNode objects. The PathNode has a special method, activate, which takes a peep as a parameter. When called, the peep should begin to move along that node. For tiles, it’s simply moving from A to B; but for something like a shortcut, it would have to play animations and gain XP and so on.
In the future, the Path object will be wrapped in an ActionQueueCommand so walking can be interrupted. For example, say you click on an item on the ground; a “PickUpItemAction” should be composed of a “WalkPathCommand” followed by “PickUpItemAtTileCommand” (or something thereabout) with the condition of “item is on ground.” If the condition fails (say, the item vanishes), then the player should stop walking (just like in RuneScape).
There’s a new component, TargetTileBehavior, and a new system, MoveToTileCortex, that apply steering behaviors. The logic is simple: if we’re too far from the tile, steer in the direction by adjusting the acceleration in such a way to reach a desired velocity. Over time, it becomes more accurate. The current implementation leaves some wobble which I think looks cute and fits ItsyScape’s theme very well.
In the future, other steering behaviors (like avoid) could be implemented so peeps avoid each other even as they pass through the same tile, unlike the current approach where they will just happily walk through one another.