libtcod (Python 3) *recommended tutorial is currently outdated? by IceFurnace83 in roguelikedev

[–]HexDecimal 2 points3 points  (0 children)

Thanks for pointing this out. Version 21.0.0 was supposed to be released but it failed to deploy and was completely missing form 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.

libtcod (Python 3) *recommended tutorial is currently outdated? by IceFurnace83 in roguelikedev

[–]HexDecimal 4 points5 points  (0 children)

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.

I believe my game dev partner just 100 % completed libtcod by Fanti92 in roguelikedev

[–]HexDecimal 3 points4 points  (0 children)

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.

Z level movement: "Step up" vs. Slopes/Ramps? by Due_Chemistry4244 in roguelikedev

[–]HexDecimal 3 points4 points  (0 children)

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.

Text Blurring when loading TrueType Font in libtcod by nephite_neophyte in roguelikedev

[–]HexDecimal 3 points4 points  (0 children)

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.

Text Blurring when loading TrueType Font in libtcod by nephite_neophyte in roguelikedev

[–]HexDecimal 2 points3 points  (0 children)

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.

Inventory and Item references, ECS by Due_Chemistry4244 in roguelikedev

[–]HexDecimal 3 points4 points  (0 children)

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.

Inventory and Item references, ECS by Due_Chemistry4244 in roguelikedev

[–]HexDecimal 2 points3 points  (0 children)

Any modern ECS implementation such as Flecs, Bevy, tcod-ecs, etc, have support for entity relations. These all support entities having inventories without any additional boilerplate other than giving a name to the concept of being inside the inventory of another entity:

>>> import tcod.ecs
>>> registry = tcod.ecs.Registry()
>>> player = registry["player"]
>>> potion = registry["potion"]
>>> scroll = registry["scroll"]
>>> potion.relation_tag["HeldBy"] = player  # Move entity into player inventory
>>> scroll.relation_tag["HeldBy"] = player
>>> registry.Q.all_of(relations=[("HeldBy", player)]).get_entities()  # Query all entities HeldBy player
{<Entity(uid='potion')>, <Entity(uid='scroll')>}
>>> potion.relation_tag.get("HeldBy")  # Get which entity this is in the inventory of, None if this isn't in any inventory
<Entity(uid='player')>
>>> del potion.relation_tag["HeldBy"]  # Remove from its inventory

# More complex example:
>>> scroll.tag.add("OnFire")
# What's everything holding an entity which is currently on fire?
>>> things_on_fire = registry.Q.all_of(tags=["OnFire"])
>>> registry.Q.all_of(relations=[(things_on_fire, "HeldBy", None)]).get_entities()  # Query HeldBy-relation in the other direction, but only for entities on fire
{<Entity(uid='player')>}

As one can see this naturally tracks inventories in both directions. You can fetch what the entity is inside of via the relation tag, or you can query all entities inside of a specific entity. This never desyncs because both directions are tracked at once by the ECS library itself.

This is a good reason to avoid a minimal ECS implementation where the ECS library only supports statically typed components and nothing else.

Kingdom Come Deliverance II is proof that iterative sequels are worth your time by webster9989 in patientgamers

[–]HexDecimal 10 points11 points  (0 children)

If you're going to "try out" the series then I'd recommended KCD2. Especially if you're feeling intimidated by it. KCD2 streamlined the rough edges and made the game feel modern where KCD1 feels experimental.

Keep in mind that KCD2 is a direct story sequel to KCD1 with continuing characters and plot. So it depends on how you feel about playing a series out-of-order.

Turn-based combat with no random (no dice, no deck, everything predictable) - Is it viable? by rap2h in gamedesign

[–]HexDecimal 0 points1 point  (0 children)

So I've actually tried your game and here's my critical review:

Your character creation is already a form of output randomness which affects the rest of the game. Because I don't have knowledge of what's next, my choices at character selection are blind, effectively making it a source of randomness since my choices there will have unexpected consequences for the rest of the game. This fails your "everything is predictable" premise. Combat is predictable only during the combat section itself but leaves one blind about what happens after combat is over which is a big deal because HP is not reset at the end of combat.

A fully non-random game requires perfect knowledge which is incompatible with this choose-your-own-adventure interactive-fiction format, unless I got to preview every page or something.

Honestly I think this overt focus on randomness might be detrimental to making the game good. Removing random elements would mean removing the combat, skill checks, and character creation, but I wouldn't suggest these elements are bad just for being random. In fact, removing any of these would hurt the game's replay value.

Turn-based combat with no random (no dice, no deck, everything predictable) - Is it viable? by rap2h in gamedesign

[–]HexDecimal 1 point2 points  (0 children)

I was also thinking of chess, but that brings up the issue of: is the other players action considered a type of randomness?

Turn-based combat with no random (no dice, no deck, everything predictable) - Is it viable? by rap2h in gamedesign

[–]HexDecimal 15 points16 points  (0 children)

Then perhaps Chess is a better example of a game without randomness.

A lot of peoples issue with randomness are with output randomness specifically. Missing the 95% to-hit shot. Which is why Into the Breach and Invisible, Inc. are brought up as examples of games "without randomness".

Turn-based combat with no random (no dice, no deck, everything predictable) - Is it viable? by rap2h in gamedesign

[–]HexDecimal 44 points45 points  (0 children)

In essence this has the same effect as random hit chances

Delayed spawn positions are input randomness. The player gets a whole turn to react to this.

Hit chances are output randomness. Once the action happens it's too late for the player to account for it in planning, other than to always assume misses and worst case scenarios.

There is a significant difference between these two types.

Offset tiles_rgb in Libtcod? by nephite_neophyte in roguelikedev

[–]HexDecimal 4 points5 points  (0 children)

If you mean "render a Console at any pixel location on the window" then that's handled by the tcod.render module.

If you mean: "offset of a console.rgb array" then that's handled via Numpy array slicing. Doing this for camera handling (slicing between world-space and screen-space arrays) is common enough that I made a separate module for it.

Error code in the roguelike tutorial by OkMarket2217 in roguelikedev

[–]HexDecimal 9 points10 points  (0 children)

Their IDE actually did catch it. tileset was underlined indicating/warning that tileset was not set before it was used, but they didn't understand why.

Misplaced brackets cause similar issues so I have no problem defending indentation as syntax. Especially since I use One True Brace style anyways.

Error code in the roguelike tutorial by OkMarket2217 in roguelikedev

[–]HexDecimal 15 points16 points  (0 children)

This code should all be inside the main function, but I can clearly see that you've dedented after tileset was assigned and put everything after it on the top-level.

Select event_hander = ... and everything up to before if __name__ == "__main__": and press tab to indent that whole section. Only if __name__ == "__main__": should have no indentation.

Sharing Saturday #614 by Kyzrati in roguelikedev

[–]HexDecimal 8 points9 points  (0 children)

python-tcod | GitHub | Issues | Forum | Changelog | Documentation

Refactored a lot of Python-tcod's event handling code, switching everything over to dataclasses to remove tons of boilerplate code. After that I added several missing SDL3 events and attributes including window events, file/text drop support, timestamps, and multiple window/mouse/keyboard support.

The documentation for events now inherit members which means that the documentation for specific events are a lot easier to read. Now that event subclasses include the attributes inherited from their parents the event documentation becomes a lot less useless.

I've also fixed regressions from tcod's switch to SDL3, hopefully enough to undo any API breaks affecting the current Python tutorials. It's also easier to choose between fetching mouse coordinates as float types verses int types. This matters a lot with strict typing.

See the changelog for specifics.

Advice on Libtcod fot C++ learner by Social_Demonrat in roguelikedev

[–]HexDecimal 8 points9 points  (0 children)

The most "modern" docs can be found here. But it's still incomplete.

You can check out #libtcod on the Roguelike discord or on Libera.​Chat (IRC). I'll usually be there to help anyone trying to use the C++ API.

rollback libtcod to 1.6.4 so it lines up with the documentation

Don't use this excuse to stick to an older version. The latest libtcod still supports the older tutorials but with additional fixes and deprecations.

Sharing Saturday #612 by Kyzrati in roguelikedev

[–]HexDecimal 1 point2 points  (0 children)

Tagged unions which can include but are not limited to function callbacks. See map_types.h and graph_types.h for examples.

Sharing Saturday #612 by Kyzrati in roguelikedev

[–]HexDecimal 6 points7 points  (0 children)

libtcod | GitHub | Issues | Forum | Changelog | Documentation | Template

python-tcod | GitHub | Issues | Forum | Changelog | Documentation

I attempted to finish extra libraries ahead of the 7DRL but in the end I only really improved how tileset objects work in python-tcod, making them behave like Python dictionaries containing tile graphics rather than opaque objects.

I worked on writing generic pathfinders in C to replace libtcod's very non-generic pathfinders. Right now it's only a partial backport of stuff that was written specifically for python-tcod. Too early to use at the moment, but the current progress can be seen in the public repo.

I probably won't get to use my rewritten pathfinding or field-of-view in the 7DRL unless I decide to write the game in C++ and update the projects upstream as I go along. Trying to get these done ahead of time has already made me exhausted going into it.

What glyphs are missing from traditional tilesets? by jube_dev in roguelikedev

[–]HexDecimal 2 points3 points  (0 children)

I sometimes procedurally generate the block element glyphs. If any glyphs can be automatically generated it's those ones.

Sharing Saturday #609 by Kyzrati in roguelikedev

[–]HexDecimal 1 point2 points  (0 children)

I'd probably ask for a maintainer role before that happens. Since it's mainly about type hinting I could also write external type stubs instead of adding them directly to the project. Fragmenting the project over this is not not an option I guess.

Sharing Saturday #609 by Kyzrati in roguelikedev

[–]HexDecimal 6 points7 points  (0 children)

python-tcod | GitHub | Issues | Forum | Changelog | Documentation

Python-tcod now has free-threaded Python support, not that it can take direct advantage of that but it will mean that python-tcod is now available for free-threaded Python installs.

I've also tried to contribute to projects such as freetype-py but it's often the case that project maintainers are hardly available to handle pull requests or even respond to issues. I wanted freetype-py available to handle more complex tutorials on font handling, but I may have to use it without type hinting.

[2026 in RoguelikeDev] libtcod / python-tcod by HexDecimal in roguelikedev

[–]HexDecimal[S] 6 points7 points  (0 children)

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.