I’ve caught up with B4.0. Quite enjoying it! I ran into a couple of “bugs” in the dungeon crawler game logic. I’ll point out what I am seeing, but maybe you can leave the implementation to the reader to try and figure out as a challenge.
Chasing/Random movement: movers do not consider other intent_to_move when moving to the same destination at the same time. This causes mobs to converge onto the same tile. like this:
The map building flow does not verify that amulet/exit positions are excluded from potential monster/item spawn positions (or vice-versa). While this isn’t an issue for the mobs (since they move), this can cause an item to be placed on top of the exit/amulet. There’s a few easy ways to fix this, but a solution in the book might require a more strict/safe solution to prevent confusion. In the current code the ordering of amulet/monster spawn lines in the implemented build() functions don’t particularly matter, but a fix for this could require a specific order.
I think the book itself prepared me to solve both of these problems on my own. Perhaps it could be something to point out to the users so they have a challenge for themselves to try and solve.
Also, It’s possible content in the future chapters might make these bugs not really relevant.
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.
