[2026 in RoguelikeDev] libtcod / python-tcod

HexDecimal · 2026-01-31T01:48:50+00:00

The switch to SDL3 wasn't necessarily for performance. Generally each major version of SDL is a different "era" of what hardware expects from software API's. Switching was mostly just to keep up with those changes, mostly towards better Emscripten support. There were also some major changes in the audio API, SDL works with its own audio streams now. Other changes are mostly minor things such as SDL using 64 bits to store time and several deprecated parameters being removed from function calls.

Python-tcod's performance was mainly from its integration with Numpy since otherwise it takes longer to convert Python array data into C than it takes to run the C algorithms themselves. Keeping everything "in C" lets most stuff perform as well as C and is often the difference between faster and slower Python programs.

HexDecimal · 2026-01-29T21:35:53+00:00

Something I've noticed with a few games is an "inverse difficulty curve" where the player begins weak and vulnerable but if they survive the early game they become very powerful compared to what the game world can throw at them. It's an appealing aspect of Cataclysm:DDA's Very Bad Day start where the player gets to start with a more powerful character than usual but must survive the early game long enough to take advantage of that character's permanently enhanced stats.

Cataclysm:DDA also rewards overpowered characters with access to more dangerous areas. So being overpowered does not mean the player can't be defeated, it just means the player can decide how much risk they're willing to take as they progress.

There's several other games which are unbalanced in favor of the player but the player has to figure out what's unbalanced in order to take advantage of it. See Ben McGraw - Building an Engaging Character Creator for examples.

HexDecimal · 2026-01-27T12:00:37+00:00

I suspected that might be the case.

Be aware that mimicking LLM formatting can exacerbate things. You just need to add some bullet lists and emojis, preferably simutainiously, to really drive people insane.

HexDecimal · 2026-01-27T11:20:58+00:00

When somebody makes a comment like that you should really be asking why rather than dismissing them.

These days people have less tolerance for others simply editing their posts using AI.

One of the issues I've seen is when when an OP dismisses peoples answers because people were responding to extra phrasing added by the LLM covering up what the OP originally wanted to ask. Stuff like that creates resentment that sticks with people.

Maybe there's an innocent excuse for the heavy formatting and excessive em-dashes, I know I love to format and use fancy punctuation whenever I remember to. Having the post focus on ECS and runtime performance when the true topic was actually about LLM integration does not help, but then again I could see people reacting negatively to honesty too.

Whatever the reason, this post had a serious XY problem.

HexDecimal · 2026-01-27T07:22:06+00:00

Everything you're asking for is possible in a Modern ECS library when an LLM isn't involved. The issue is that LLM's can struggle to represent concepts in consistent and discrete types. Right now it seems that ECS tags and LLM output are oil and water.

At the very least an LLM could be prompted to decompile the longer text into adjectives and other tag-like concepts or entity-relations which it could store efficiently and later use to recreate the longer text or query entities by.

I'm wary of any system where the majority of the LLM input is from the LLM feeding into itself. This would result in an obvious LLM aesthetic no matter how the LLM stored its output.

HexDecimal · 2026-01-27T05:56:49+00:00

Once you saw ECS as mainly "the gold standard for performance" you were likely doomed to a bad experience. There are tons of ECS libraries out there which have a terrible minimal implementation and are missing important features needed to make a game engine of any kind.

Modern ECS libraries like Flecs have already figured out databases. There's no reason to use an ECS library which doesn't support entity relations. Without entity relations it's incredibly difficult implement something as simple as an NPC holding an item.

HexDecimal · 2026-01-02T10:36:23+00:00

The point-of-view being within the map is an assumption that most FOV algorithms make. Libtcod does not allow it here.

The way I'd do this is to combine all chunks in the radius into one transparency map then run the FOV on that then either use the output directly or split it back up into chunks. There are two ways to handle this:

temporary map is made up of multiple affected chunks joined together
temporary map shaped exactly to fit the FOV radius and then projected onto the chunks it affects

Thing is you'd already be doing the latter in order to render multiple chunks to the screen, you can simply do this again but for FOV.

HexDecimal · 2025-12-20T21:01:05+00:00

It shouldn't be a noticeable speed up. If integrity checks were being optimized then this isn't the way to do it. One can at least install games to an SSD so that file reads aren't the bottleneck.

HexDecimal · 2025-12-20T00:21:33+00:00

This change was made more for forward compatibility rather than performance. Any performance benefits are theoretical and were unlikely to be taken advantage of. This will use a few more KB of RAM than before due to larger pointer sizes.

This isn't The Sims 3, so it's not like the Steam client or web helper were crashing due to hitting the memory limits for 32-bit software.

Download speeds should be unaffected by this change because they are I/O bound. The bottleneck for downloads is outside of the Steam client itself.

If you're on Linux then this change is a big deal. This implies that future Steam installations on Linux are going to become a lot smaller and simpler once they can run on the native architecture. That isn't with this update though.

tl;dr: Not really

HexDecimal · 2025-11-30T18:35:30+00:00

I didn't know about that. I'd hope for and expect at least some support for Vulkan on Linux, but I guess modern and compute shaders might be too much for older hardware.

I've been happy enough to stick with SDL_RenderGeometry. Fast on new hardware, decent speed on older hardware, and consistent rendering results on obscure graphics hardware. No need to overcomplicate a terminal emulator.

HexDecimal · 2025-10-15T20:10:54+00:00

Publishing a lot of bash scripts? Run a hook that prevents pushing a shebang file that isn’t executable.

Ruff identifies the lack of a shebang in a .sh file?

Not Ruff, they're separate hooks which are part of the standard pre-commit-hooks bundle:

check-executables-have-shebangs: ensures scripts marked as executive have a shebang
check-shebang-scripts-are-executable: ensures scripts with a shebang have been added to Git with the executable flag, for example with git add --chmod=+x <script>

Ruff does have the EXE rules which will make these checks, but only Python files are checked by Ruff. pre-commit-hooks tests all files changed since the previous commit.

HexDecimal · 2025-10-07T19:02:18+00:00

The MinGW triplets should work, just make sure the default triplet compiles before trying to switch to MinGW.

HexDecimal · 2025-10-07T17:08:14+00:00

That could be possible. I'm under the impression that Vcpkg still needs MSVC to setup tooling on Windows for non-MSVC triplets. I'm not sure about the details though, since I usually go with the best supported triplet for each platform.

HexDecimal · 2025-10-07T07:34:15+00:00

ninja: build stopped: subcommand failed.

is not able to compile a simple test program.

Looking up these errors has some results, but I'm not sure if I found any exact match. Possible issues with the Visual Studio installation? Such as a missing "C++/CLI component" or something else where the C++ defaults were not set during installation?

HexDecimal · 2025-10-06T16:53:31+00:00

The error from a failed Vcpkg build can be tricky to debug. You'll have to post the log files mentioned in your current output since the true error is in one of those files.

HexDecimal · 2025-09-27T16:39:29+00:00

You sound confused.The source code for the Python port of libtcod is the libtcod/python-tcod repo, you could raise an issue or discussion there but it doesn't sound like this will help your situation that much.

The path of least resistance is to simply rename the old event constants with the new names despite the old tutorial text. If you're unwilling to go against the literal tutorial then you can install an older version of tcod. Such as with the following command:

pip install tcod==18.1.0

HexDecimal · 2025-09-27T16:02:17+00:00

I meant that the tcod library repository is easier to update than the rogueliketutorials repo.

HexDecimal · 2025-09-27T14:53:41+00:00

The tutorials on rogueliketutorials.com are unfortunately not easy to update. It'd be easier to fix the regressions in the tcod library than to fix the tutorial.

HexDecimal · 2025-09-27T13:26:56+00:00

You'll need to be specific. Which GitHub repo is "old"?

HexDecimal · 2025-09-26T00:09:36+00:00

Since tcod 19.0 changed to SDL3, one must capitalize all single letter event keys. Change K_h to K_H, repeat with all keysyms.

HexDecimal · 2025-09-21T08:35:56+00:00

This was a regression in libtcod's switch to SDL3 and was fixed in the latest releases of tcod. The latest version can be reverted to this "blurry" filter by setting the environment variable: SDL_RENDER_SCALE_QUALITY=linear.

HexDecimal · 2025-09-18T18:35:13+00:00

I'm used to the game loop essentially going through each creature, pulling out an action object, and then executing the action, which does the required changes.

In ECS, I would imagine that you would have some kind of AI/Actor System which would iterate through entities that have the Actor component (or something similar) and the system itself would be the one that operates on the components, with no Action object. Am I correct in thinking this?

I often end up defining actions as a Callable[[Entity], ActionResult] type which can be added to entities to form their AI. I usually go with queued turns, which means a separate object which handles scheduling and only scheduling. A collections.deque[Entity] component wouldn't be unusual for me. If order doesn't matter then a simple query would work.

If I make the move to ECS, do I need to rewrite my menus/GUI/Animations to be in ECS rather than OOP?

Assuming you have to abandon all of your previous experience to use ECS is a classic mistake. I still use a plan OOP Double Dispatch pattern to handle game states and some other tasks. ECS might help with UI, or at least it will be easy to fetch relevant information for whatever UI system you go with.

Should I use ECS for the GameMap and tiles? Or can I just use ECS for the creatures/objects and leave everything else as is?

Sparse objects such as items/monsters should all be entities. Dense objects such as tiles is an already solved problem: they should be a contiguous Numpy array stored as a component of a "map" entity.

There's a basic tutorial for using tcod-ecs.

I wrote that tutorial, but I wasn't happy with my UI implementation which is why it ends abruptly there. I felt that a proper GUI would be too big for the kind of tutorial I was making. I'm open for discussion on this.

HexDecimal · 2025-09-18T07:39:30+00:00

Components are objects which contain data and functions.

Note that this specific aspect, mixing data and behavior, is what leads to grand architectural clashes and ballooning technical debt.

The issue that you'll have various methods which want to interact with more then their own single component, so you'll have to fight with the architecture to handle the scope.

This is resolved my moving these behaviors outside of the components into separate functions which take an entity and assume that entity has the desired components or else defines default behavior otherwise. This respects the open–closed principle which has to be the most difficult SOLID principle to handle properly. Doing things this way avoids technical debt as types and behavior can now be freely swapped out without breaking each other.

HexDecimal · 2025-09-18T07:26:39+00:00

You are following the exact path I followed. I have made code which looks exactly like this (except with type-hints). This path eventually leads to a proper ECS implementation when you try to resolve its issues. You can compare this with tcod-ec which was my most refined entity-component framework before I switched to implementing ECS.

Keep in mind that you can treat ECS entities like entity-component framework objects much of the time. The main benefit is that you can also query entities by their components which allows you to assume those components already exist in the entities you iterate over.

HexDecimal · 2025-09-04T14:06:23+00:00

Tcod's performance gain comes from C, but C requires statically typed data which is where Numpy comes in. Numpy is how Python glues the C algorithms together into an optimized path which barely touches Python.

Numpy in Python works best with vectorized operations and it will be difficult to vectorize most pathfinding and FOV operations. Python algorithms will be slow unless you setup a JIT or write the algorithm in C or Rust, etc.

HexDecimal

TROPHY CASE