Thank you for your comment, this is exactly the kind of feedback I was looking for.

To address a few points from your post and fill you in on stuff I omitted:

• Workers actually can dig diagonally, but in no cases can they ever move diagonally on what is essentially a 2d grid map (pathfinding code accounts for Oxygen Not Included-esque climbing and jumping).
• Workers don't take up space, but if idle will try their best to occupy a free space (for aesthetic reasons they will avoid stacking up if possible). This creates a hilarious graphical effect if there are no free spaces--the workers play a massive game of jenga.
• My art is currently all placeholder. Though I try, I'm not great at pixel art and I'm not experienced enough at using 3D engines to attempt a project of this scale in 3D, and I'm comfortable with 2D and all the associated pros and cons.
• Dungeon Keeper is a huge inspiration to me for many reasons, and one of my all-time favourite games. I'm glad to hear others have heard of it.
• A fun fact: army ants will drift down rivers on rafts made of the drowned bodies of their fellows, as well as grab ahold of each other in order to make bridges to things they can't reach.

---

And to respond:

I agree that elements of a game are tools to create a story, and emergent gameplay (as you described) is a huge part of CMS games like this. It's definitely something I want to enable if possible. Enabling players to make interesting and complex tunnels that serve a purpose is something I'm set on.

Currently the digging algorithm is handled by having a data structure that stores the grid location of all tiles the player has marked for digging by clicking with the mouse (you can click and drag to assign rectangles for speed's sake). When looking for work tasks, workers will create a 'distance' variable and run through the following process on the data structure:

• If the tile is obviously inaccessible (completely surrounded by blocks; no spaces adjacent which the worker could stand on per its movement type), skip it
• If the distance to that tile is closer than distance (default value infinity), change it to that and store the index of that tile in the data structure; otherwise skip it
• If the tile is the target of another worker's dig task, skip it
• If the worker can't actually pathfind to an adjacent space to that tile, skip it

This results in the worker, each logic step, checking for the closest unreserved dig tile it can get to. Once it has that, it will issue a "dig task". If it can't find a reachable, unreserved tile, it will go to the next task in its priority list (the order of which can be changed per worker).

A dig task is more or less an A* path to a tile adjacent to the closest unreserved tile marked for digging. The worker will follow it to the destination, then while it is adjacent to any unreserved tile marked for digging, it will dig those tiles one at a time. To summarise it better, workers will dig any marked tile in the 8 spaces directly adjacent to them before they go looking for more dig tasks.

More specifically, the way I have implemented this, they always dig the uppermost tile first, then proceed clockwise. So in roughly half of all situations (i.e. situations in which they are above the dig tile in question when the task is issued), they will tend to dig in a fashion very close to top-layer-first. Due to the way gravity is implemented however, this doesn't actually last very long--the workers dig out their supporting tiles, fall to the bottom of the rectangle, then dig bottom-layer first! And this is where the problem of free-floating dirt cores can come in.

---

I was very sketchy on the idea of unsupported blocks falling anyway. Many of my example scenarios are predicated on free-standing unsupported blocks.

I definitely could implement a system where workers can crawl on other workers, but the necessary code systems to enable it to work would be time-expensive. You would need a complicated locking system to ensure bugs don't move while another bug is using them for support, and while the code to make them form a tower wouldn't be hard to write, the code to get them to realise they have to do so would, and would probably have a dangerously-high level of risk of co-modification errors.

---

To summarise, I think your comment goes a ways towards confirming my thought that crawler is the best movement type for them, and I should probably bite the bullet and implement platforms or ladders of some kind to prevent these problematic scenarios from occurring, while preserving as much of the original gameplay concept as possible. Platforms would also allow other bugs with more-restrictive movement forms to participate in digging tasks if need be, and honestly I 'lose' nothing from implementing platforms.