python-tcod-engine-2023 VS simalq

This month I wanted to work on a new Python tutorial, but I'm having trouble getting parts of my test engine to work cleanly (right now involving interactions with how actions poll their inputs from the UI). I might have to settle for making another "bad" tutorial and then fix architectural issues later.

I have repurposed a recently failed game jam project into my next Python libtcod engine. The source is here. This will be the 2023 Python engine. I plan on working on this over the month and then using it for the upcoming 7DRL. I intend to implement the tutorial features in a simpler and less intrusive way than before so that the engine is easier to extend with new features.

Last week, I hit an important milestone: I implemented the last tile type needed to make one of Yves and Serge Meynard's original scenarios, New DeathQuest, playable from start to finish. After three months of on-and-off work, I have an essentially playable game.

I have a function [pos+](https://github.com/hylang/simalq/blob/e8ade1506f70a61ed83662e6fb02c6acd8ad3ba9/simalq/geometry.hy#L104) that adds a Direction to a Position, for things like seeing what square is directly east of another square. It used to raise an exception when the result was off the map border. It now swallows that exception itself and returns None, because I noticed I had to catch the exception pretty much every time I used the function, and it's neater to check that it's None than catch an exception. In general I'm an exception enjoyer, and I shudder at how e.g. Go makes you follow practically every function call with if err != nil { … }, but it comes to show that errors that happen a lot and need explicit handling every time are more easily treated as just another value.

Infinitesimal Quest 2 + ε (GitHub)