TIL Bluesky does not support GIFs 🤦

Well, here at least is the last frame, showing where we're at now

To that end, we'll soon be reviving the playtest sessions, and we look forward to sharing these with you!

If you wish participate or learn more behind-the-scenes info, feel free to join us in the discord:
discord.gg/HAgkTE3yCw

From here, we'll continue designing levels to balance out the variety of content, and to expand our options so we can curate the ideal selection among them

Most of these are playable in game as well, and we're in the fortunate position where our tools make it easy to quickly reproduce our paper prototypes in-engine

In fact, we've reached the notable milestone of having as many levels designed (i.e. that have been at minimum paper prototyped) as we intend to have in the full game!

With this implemented, villagers now only attempt to exit the level when they will actually be able to do so, enabling a wider, more dynamic range of puzzle mechanics.

This is definitely a tool I'll be sure to keep in the toolbox for future projects! [8/8]

This does of course introduce an additional loop within the standard A* algorithm, but fortunately for the size of levels we're dealing with, this has not been a significant performance bottleneck [7/8]

So as the pathfinding algorithm considers each coordinate, it simulates the path found so far up to the current position, allowing it to enqueue a valid set of neighbors. Then the simulated series is undone in preparation to consider the next coordinate in the queue [6/8]

The delegate for simulating the path was made much more convenient since we've already been using the command pattern to encapsulate the act of moving from one tile to the next, making it easy to both execute and undo a series of these commands [5/8]

The way we do this is, we pass a copy of the level state to the algorithm, along with a delegate that tells the search algorithm how to simulate what level state changes will occur as a result of following the path [4/8]

So essentially, I've extended the traditional A* pathfinding algorithm to simulate the effects of following the path as part of the search process, so villagers can anticipate what will happen next... which is non-trivial to say the least! [3/8]

For example, with the prototype level in these screenshots, the initial level state seems to allow a fully walkable path. But, when the villager steps on that 1st pressure plate, it toggles the platform ahead to lift, making it no longer possible to complete the path [2/8]

The screenshot above shows a prototype level where this comes into play. It makes for some interesting implications for how to solve puzzles with this mechanic!

The challenge with cycles is ensuring you don't let the algorithm run indefinitely. I'll admit, my first implementation succumbed to this despite my intentions not to, freezing my editor and needing to force quit. Then I changed tack, and the next implementation worked! 🎉

In this case though, the teleport mechanic makes it so your options for where to go from any given tile can depend on which tiles you came from just beforehand, so the shortest path actually can pass through the same tile more than once.

This was more than a little bit tricky. The typical A* implementation does not allow for backtracking, since it's generally meant to find the shortest path, and revisiting someplace you've already been is inherently inefficient.

As a result, I've modified our A* pathfinding implementation to allow for a limited amount of cycles. That is, the algorithm can produce paths with loops, such that the same coordinates can be visited more than once.

Basically, given the way our new teleport mechanic works, there are some cases where you or a villager may need to pass through the same teleport rune twice...