hauberk

That code is seven years old: https://github.com/munificent/hauberk/commit/2ba2f260baa7004... I should fix it to use: https://api.dart.dev/stable/2.17.6/dart-html/Element/request... I just never noticed because it wasn't causing any problems.

It's been 357 years, and Dart still can't go full screen without a hack like this: https://github.com/munificent/hauberk/blob/master/web/main.d... https://github.com/dart-lang/sdk/issues/11506 (Jun 25, 2013)

Dart is also an option. https://github.com/munificent/hauberk https://journal.stuffwithstuff.com/category/roguelike/

That Bob Nyquist has a pretty cool roguelike on github called Hauberk written in Dart, amongst a number of other good related dev articles and best practices on his blog. https://github.com/munificent/hauberk Edit: I realized the link to Hauberk is at the top of his article, but it's worth checking out; mostly complete, good ideas, cool use of color.

I've run into this exact issue in my roguelike [1]. I don't think I have a fully baked solution yet, but the direction I'm going [2] is a combination of the Observer pattern and caching. For derived stats, it's not enough to just always recalculate its value from scratch every time you access it. At least in my game, I also want to tell the user when the value of a derived stat changes. If you equip a piece of armor that raises your strength, I want the game to tell you "You feel stronger!". So each derived stat stores its current value and then has a refresh() function to recalculate itself. The stat is refreshed at the end of each turn. It recalculates the value and then compares its previously cached one. If the value changed, it logs the result and then updates the cache. [1]: https://github.com/munificent/hauberk [2]: https://github.

> If I read right, the author is just implementing an older algorithm but switching the order of two steps for efficiency reasons. That's right. > No it never generates crossroads. It can, but they're rare. It would be an easy tweak to make them more common. > Despite saying the maze can be imperfect, I think they are wrong. It always generates imperfect mazes. The code that does that is: https://github.com/munificent/hauberk/blob/db360d9efa714efb6... Basically, it removes all connections between regions that are already connected. Except there's a finite chance it will keep the connection even when the two regions are already connected. In other words, it adds known cycles. > Anyway, it's kind of boring as maze generators go. Yeah, it does produce sort of same-y results. I'm not currently using it because of that. But I also intend to re