Thanks! This is actually a tough one to find a balance (see mikecargal’s threads on procgen for another example). On one level, I’ve had to restrain myself a bit to keep focused on teaching Rust and concepts rather than bogging down into fine details; on the other hand, it would be really nice to catch these bugs (if I had a third hand, it would be remining me that I have a page count limit!). I intend to tackle some of this (particularly constraining item placement), but probably not all of it.

My current plan is to add some constraints to item placement, at the level of generating available spawn positions. It’s relatively easy to add a few “denied” slots (such as the exit) - so it won’t be too large or trash the reader’s flow too much by vanishing down an aside. I’m hoping to squeeze in a few procgen constraints, too - a quick call to add a forced boundary around the map, maybe cull unreachable tiles (that’s easy to do). Exactly how much of that I can get in is itself constrained by page count. Worst case, it’ll be presented as a “here’s some ideas to improve this” exercise.

The monster overlap is worth discussing a little because it highlights one of the toughest issues with an ECS design. When you are building your systems to run efficiently with little data-overlap from other systems, and each entity effectively processing independently - it does make checking against other dynamic entities harder than you’d expect.

In the Rust Roguelike Tutorial (my big project before this one), I had a whole “blocked” system with an additional data construct to track tile contents. With hindsight, that was a mistake - deep into “second system syndrome”, I spent as much time catching cache invalidation problems (it’s basically a location cache) as I did benefiting from it. So I knew that this book shouldn’t go that route. It does have the nice side-effect that mobs will realize a dynamic path is unavailable and route around to attack from a different direction - but it gets huge and complex achieving that.

So I’m going to do some debugging and get the “collisions lite” setup I was aiming for working better. Check “wants to move” message destinations and simply not apply them if they result in a goblin cheerleading pyramid. I’ve been planning to clean-up the did_something code for that system anyway; it is messier than it needs to be.

Thanks, and I hope my overly long reply makes sense!

Absolutely makes sense. The dungeon crawler being built from the book is serving a specific purpose. And a bug free game isn’t the primary goal. Of course, it’d be nice, but not the primary goal. I mostly just wanted to point out cases I saw. What code should not go into the book is just as important to consider when you’re trying to teach a point.

Second system syndrome is quite the siren’s song. Making a buggy game has more value than spending all your time building an overly complex system for a game that you might not finish. I tend to still try to make the overly complex system.