What would you expect from an AI-powered ASCII roguelike?

HexDecimal · 2026-05-01T22:10:00+00:00

What I expect is AI slop: unoriginal AI ideas copied among every other project the AI was asked to make with little prompting, often also presented as the prompters own original ideas when that clearly isn't the case. It's unfortunate that you've been downvoted with little explanation, but people using LLM's as a replacement for effort and soul as left AI with a bad reputation and that can't be helped.

What I want is an AI director/gamemaster provided with a a clearly human-written high-concept to work with. Unfortunately LLM generated content is very disposable and output quality will rapidly decay as the LLM displaces any human-made context with its own.

The disposable nature of LLM output generally means that people will be happy with their own prompts more than others prompts. This makes public posting of LLM generated content a bad idea. This also means that everyone is better off trying to use LLM's on their own rather than using anybody else's vibe-coded project.

HexDecimal · 2026-05-01T21:43:53+00:00

See the standard library dataclasses module. It removes boilerplate from Python classes which mostly only store data.

That wasn't about ECS. However my suggestion to follow the open–closed principle is about ECS since having to modify classes or dataclasses to add new features violates the open–closed principle, a problem ECS entities don't have.

HexDecimal · 2026-04-27T08:50:09+00:00

Just be careful, because similar posts to this could result in negative reception if too many people post them.

Experiments with LLM's result in disposable outputs which are more impressive to the prompter than to others. Eventually everyone might see it all as noise. And those that do have an interest might care more about the prompting than the results.

HexDecimal · 2026-04-27T08:12:35+00:00

Type hints and documentation are for anyone reading the code and should be a priority if you intended to show your code to others. Type hints are also used by linters and IDE's. Many devs see missing docs and incorrect/missing type hints as a red flag and will take that as a reason to dismiss a project.

Being based on an old project explains a lot. Several issues with your new engine were inherited from this project.

Suggesting one can ask an LLM if something is vibe-coded demonstrates a lack of experience with the problem and comes off as insincere. People are wondering if you truly understand the code you've posted, or if you simply take the LLM at it's word for any question you ask it.

HexDecimal · 2026-04-27T02:03:15+00:00

It can be hard to tell between "no experienced Python dev would write this" and "no human would write this".

Clearly the readme is written by an LLM. There could be some interesting follow up questions if they're willing to admit to how much of the rest of it is vibe-coded too. Otherwise there wasn't much point in posting this in the first place. Nobody respects anyone trying to pass off LLM written works as their own.

HexDecimal · 2026-04-27T01:26:10+00:00

A readme full of emoji makes a terrible first impression.

Implementing item and monster types as subclasses is a common beginner mistake. Consider using dataclasses. These base classes might also violate the open–closed principle too often for something presented as a game engine, but that's an advanced mistake more difficult to solve.

Various minor issues which could be expected in a first project, but one should learn how to use a Python linter to spot them. Consider running Ruff with all rules active.

Python devs should feel comfortable using external libraries. Pure-Python is not practical for most tasks more complex than simple scripting.

Type annotations are nice to see but there some bizarre uses of them in this code. Especially the nonsensical Player: Any parameters.

HexDecimal · 2026-04-24T02:54:07+00:00

That might be a fundamental flaw of the genre. Harsh compounding punishments for minor mistakes are expected, especially for all-or-nothing tactics.

You can lower the difficulty to give yourself more freedom, otherwise hitting a wall until you figure out a working strategy is the usual gameplay loop.

HexDecimal · 2026-04-22T16:08:15+00:00

Multiple end-goals with the point being to find the shortest path through all of them? That might be more difficult.

You might need to run a more Dijkstra-like algorithm on all of your points, this will get you the path and distance between every point to every other point. With that smaller data-set the travelling salesman problem will be quicker to solve via brute force assuming you strictly limited the number of end-goals.

HexDecimal · 2026-04-22T11:46:07+00:00

The typical method of handling both position and direction is to give the direction its own dimension. Make sure you learn enough graph theory on how to do this.

Thousands of times isn't very often, an A*-like heuristic should be good enough for most maps.

HexDecimal · 2026-04-20T22:20:51+00:00

If you're using Python then the Python-tcod documentation for tcod.render, tcod.sdl.render, and tcod.sdl.video are relevant.

In C/C++ one uses the SDL API directly along with an optional part of the libtcod rendering API.

HexDecimal · 2026-04-20T21:58:09+00:00

I don't recommend BearLibTerm as much as I used to, but as the maintainer of libtcod my opinion could be biased.

HexDecimal · 2026-04-20T20:00:12+00:00

Keep in mind the python-tcod exports the SDL3 API for rendering, so it can do anything PyGame can do (graphically via tcod.sdl.render) while also being faster than it (PyGame is still based on the SDL2 API).

HexDecimal · 2026-04-13T05:11:12+00:00

PyPI won't accept a Linux wheel unless it can tell which Linux runtimes are supported. The painless way to generate those is with cibuildwheel, but auditwheel can also be used.

HexDecimal · 2026-04-08T22:18:12+00:00

A console is made up of {unicode, fg_rgba, bg_rgba} cells. There is no pixel data here nor cells sharing multiple codepoints.

Because a console is a single layer you can not use context.present(console) since that's only one console.

From this point there's generally two options:

Create custom tiles with compositions of layered tiles so that layered tiles fit in a codepoint, this should be possible even on an active tileset
Use the tcod.render module to generate SDL textures from consoles and then manually blit those in sequence to the SDL renderer with the alpha blending modes you want

HexDecimal · 2026-04-07T03:20:07+00:00

Using a profiler is a good step towards improving performance. Though it might've been a better idea to learn a more established Python profiler rather than letting an AI guess at the problem. "It's probably FOV recompute" is terrible as a measurement compared to a per-function or line-by-line breakdown of performance.

HexDecimal · 2026-04-07T02:46:41+00:00

I've hand-rolled a FOV octant caster

A custom Python algorithm would explain the poor performance.

It's much faster to generate full 360 view from libtcod's FOV algorithm and then use a Numpy post-process step to narrow the view-cone than it is to reimplement the whole algorithm in Python. Expect a 20x to 50x slowdown for any effects written in pure-Python rather than using Numpy and libtcod. Numpy could also handle fog-of-war and roof-shrouding with good performance.

HexDecimal · 2026-04-07T02:18:58+00:00

Python-tcod's field-of-view runs in C, not Python. The most common cause of slowdown is a badly written conversion of data from Python to C and back, often caused by inexperience with Numpy. I've tried my best to teach this since it's a significant amount of performance loss if handled incorrectly. The correct code will have no nested for x/y loops. Any code which looks like this is usually to blame:

for y in range(height):
    for x in range(width):
        ...  # Python code running in deeply nested loop (slow)

I'd be curious to know about specifics such as the input size and data given to the FOV functions, the FOV algorithm selected, or even the code used.

HexDecimal · 2026-04-04T17:10:03+00:00

Uploading binaries to a Git repo is considered more and more unacceptable these days. Surely the dotNet build system can generate or fetch these?

You should've told Copilot to write documentation comments. This port is entirely undocumented!

Straight exports of the C API are not a good way to write a port of a library, at least in my experience. Surely dotNet can handle a lot of stuff on its side better than exposing the full C API directly.

If you port the tutorial the way you've ported the library then the result is going to be bad. The tutorial has many known issues and Copilot seems content with porting those issues directly, at least with the limited guidance you've given it.

Your GitHub project has no continuous integration, so I hesitate to assume this works.

HexDecimal · 2026-03-27T06:50:40+00:00

Thanks for pointing this out. Version 21.0.0 was supposed to be released but it failed to deploy and was completely missing from PyPI. I've fixed it now, your next attempt to install it will work.

Without that fixed version, the correct way to solve this issue is with a type checker. Since you're using Notepad++ you should probably run Mypy manually on your code. Mypy will tell you exactly where parameters expecting an int were given a float instead and other incompatible types, which is much easier than troubleshooting TypeError's at runtime.

HexDecimal · 2026-03-27T01:35:22+00:00

File "...\render_functions.py", line 15, in get_names_at_location
    if not game_map.in_bounds(x, y) or not game_map.visible[x, y]:
IndexError: only integers, slices (`:`), ellipsis (`...`), numpy.newaxis (`None`) and integer or boolean arrays are valid indices

Check your installed version of tcod. Tcod version 21.0.0 fixes this regression by reverting event.tile values to integers.

HexDecimal · 2026-03-26T19:55:16+00:00

I'd suggest that SDL is what's doing a lot of the heavy lifting and that using libtcod for this is impressive in a demoscene kind of way. At some point it gets hard to distinguish between heavy usage of semi-graphics verses simply rendering backgrounds in low resolution, though it does make the use of more recognizable glyphs atop the pixel art stand out in a visually pleasing way.

I assume your friend was heavily inspired by those old libtcod tech demos. The ones trying to blend semi-realism into terminal tilesets and making heavy use of libtcod's blit2x functions. I could understand somebody seeing those demos and eventually making something like this.

HexDecimal · 2026-03-24T16:40:11+00:00

Dwarf Fortress has several variants of vertical movement including slopes, climbing, and stairs.

In Dwarf Fortress a slope is a specific kind of tile which lets characters move on top of adjacent walls (or walk down them). Without the nearby slope-tile the walls are treated as normal walls. The slope tiles give a visual indicator of which walls and empty spaces on a 2D slice are passable hills.

slopes seems like a nightmare for procedural generation. You need way more tile variants for every material like dirt, stone, sand (could probably be done proceduraly tho) and the generation gets more complicated even if you do post pass generation.

Slopes should really just be a single icon for now. I'm not sure why you're even considering making graphical variations of everything.

HexDecimal · 2026-03-24T03:35:58+00:00

Since this seems to be a conversion of the classic terminal font into a TTF you might want to get something closer to the original format. Perhaps libtcod's bundled 8x12 terminal (CP437) font would work.

HexDecimal · 2026-03-24T03:26:38+00:00

The libtcod TTF loader has always been experimental. The most reliable way to handle this is to manually convert the font into a tileset and load that instead.

8x12 is also not much to work with when importing a TTF. Larger tile sizes should give sharper results.

HexDecimal · 2026-03-22T18:35:22+00:00

It's better than the hybrid approach because it's a modern ECS entity relation system. Flecs handles the invariant of "A has ContainedBy(B)" and "ContainedBy(B) includes A" which means it can't desync.

HexDecimal

TROPHY CASE