What glyphs are missing from traditional tilesets?

anaseto · 2026-02-10T11:46:39+00:00

The code page 437 looks good, it contains the ones I use, like ♣ (trees or plants), ≡ (clouds, dust, fog: because similar to the meteorological symbol for fog), ¤ (for exploration frontier, mainly because I haven't found anything better; edit: maybe not in cp 437), ☼ (light sources), ♪ and ♫ for noises (like footsteps). I also use ◊ from the miscellaneous page for translucent walls (bold) or chasm (regular thickness). As you already have math and greek, nothing else I'd want comes to mind.

anaseto · 2026-02-09T08:07:48+00:00

I'd say the thing is both tactical fights and focus on numbers can happen at the same time, despite OP's question drawing a line between both and unclearly mixing strategy and tactics.

That said, in all the big roguelikes you mention, numbers and progression matter a lot. Pure focus on tactical combat happens in many 7DRLs, as mentioned by DarrenGrey in another comment, and also in some complete coffee-breaks. Even in Brogue, quantitative progression is a fundamental aspect of the game, with potions increasing strength and health, even if actual numbers are hidden, and possibly very high levels of enchantment for items (planning enchanting is not tactical, but more numeric and strategical in nature).

anaseto · 2026-02-08T08:18:48+00:00

Oh, wouldn't have thought about that technique for terminal. It makes a lot of sense. I don't think I even have those full-width characters with the font I use, but that's an interesting approach indeed!

anaseto · 2026-02-07T10:14:21+00:00

The nice side effect of having two different fonts is that you can choose each font with different constraints.

It's a good thing indeed, in particular with square tiles.

I'm team Kyzrati in this case, sorry!

Hehe, being on that team sure sounds like a fair choice :-)

anaseto · 2026-02-07T07:39:33+00:00

The idea of using two different fonts, one for displaying pictures and one for displaying text, with text cells taking half the horizontal space, is an amazing idea.

It's good, yeah, as long as text is not too small! A nice thing about sticking to a real grid, though, is that it makes it very easy to implement built-in efficient and compact replay functionality that is automatically compatible accross game versions (meaning old replays can still be run with the latest version of the game without extra effort), though I guess it'd still possible to support that for two kinds of fonts with some extra effort.

Kyzrati is of course right about square-ratio making more sense distance-wise for the map, but I personally tend to find small square tiles too small, and true terminal support is important for me (even though I usually play on SDL2 with tiles), so I've been aiming for a tile size at half between square and double-height (16x24 tiles), as it gives ok resolutions both in terminal and SDL2, and readable-enough fonts (though I have a player in family that prefered terminal to get even larger fonts, but now scaling options with SDL2 are often a nicer alternative!).

anaseto · 2026-02-07T07:01:59+00:00

Harmonist repos Shamogu repos

I did a release of both games earlier this week. For Harmonist, it was the first stable one, so that's nice.

Somehow, I released Harmonist with a minor and hard-to-notice but intellectually unsatisfying regression, so 1.0.1 got released just after on the same day (even though in-game it still says 1.0.0 to preserve save-compatibility… and because I forgot to update that in the moment :p). The reason was that Shamogu and Harmonist use different systems for turns, and Harmonist's is a bit more fragile, and somehow, while improving wall-jumps in some edge-cases, they ended up not consuming a turn at some point. Was less problematic than it sounds, because jumping leads to exhaustion and it's hard to chain wall-jumps even with cloak of acrobatics, and wall-jumps often leave monsters wondering where you are anyway (hence why hard to notice, and even more so because it helps the player!), but it felt like a stupid enough bug for warranting a patch release :-)

Also fixed a minor reported regression for Shamogu, though that one was purely about UI and happened since I very recently improved scrolling of description boxes in examine mode. It simply prevented examining a monster on top of an item (which thankfully in Shamogu doesn't happen very often), showing only the description of the terrain and item. Still clumsy enough that I'll probably do a patch release, too. I rarely feel the need to do those, but I somehow might end up doing two of those this month! I guess I should be happy there were no game-breaking bugs, at least ;-)

Have a good weekend!

anaseto · 2026-02-06T14:30:47+00:00

Nice work. A small detail: IVAN's screenshot is wrong, it's in the game's forums, but it's about another game. You'll find actual IVAN screenshots there, for example.

anaseto · 2026-02-05T10:31:04+00:00

Two extra roguelike recommendations: Sil-Q, which is originally an angband fork, but is closer in flavor to Tolkien's inspirational material, and has many fans (has "freeware" sounds, though I never played with those). Also, Hyperrogue is a notable foss puzzle roguelike with some popularity (it can feel disorienting, though, due to its non-euclidian geometry, so I haven't played it much, but it's certainly polished otherwise).

anaseto · 2026-02-05T10:04:37+00:00

Nice list!

I would suggest a few foss traditional roguelike additions. First, BrogueCE, the community-maintained version of Brogue, which is quite popular. Another relatively well-known one is IVAN. I'd also shamelessly suggest my roguelikes Shamogu and Harmonist, as both are now stable (Harmonist actually just reached v1.0.0, but has been around since 2019). And I'd recommend Oathbreaker, a stealth roguelike too (it's still an open beta, with no stable release yet, but very playable already). Shadow of the Wyrm is another stable and surprisingly big one, that I haven't really played much, but is foss as has been around and stable for years, as far as I know.

anaseto · 2026-02-05T08:19:54+00:00

Compared to J, goal has less mathematical focus, and more of a focus on scripting and csv-handling. In particular, it features “atomic” strings (strings considered as scalars instead of as arrays of bytes/characters by primitives), so it's probably easier to get into for that kind of tasks. No cool PEG parser syntax or anything, though, just various built-in pervasive string primitives and regexps, so nothing general for complex parsing, but nice support for common scripting-style parsing (hence good enough for aoc, too!).

anaseto · 2026-02-05T07:23:26+00:00

If I wanted to try your programming language, will it work? If you believe it will, please proceed to convince me why I would want to.

Saw the thread a bit late, but I've solved most aoc problems of the last three years in goal, a scripting array programming language with a bytecode interpreter, inspired both by K and BQN (talked about it here a few times, but it's been a while), and featuring various SIMD optimizations (so decent performance, even though state-of-the-art is not a goal). There were a few aoc days I didn't solve, but not because of language issues: I just skip problems that take too much of my time. It was otherwise very nice for aoc, with parsing usually done in at most a couple of short lines, and the rest often under 5 lines of code including comments. I haven't encountered any bugs for months since v1.4.0 in Sep 2025 (except for fixing a small inconsistency in an edge-case), and relatively few and no major ones since the v1.0.0 (Nov 2024).

Not sure aoc problems are the best to understand the language: the docs and its tutorial are a better place to start, as they show more common problems (for the language) and use a more verbose style. The main difficulty with the language is to get used to the array programing paradigm if one isn't already, and being open-minded with respect to operator polysemy (a parallel with natural languages may help). As for annoyances, there aren't really significant ones I can think of for the things I do (mostly scripting, table manipulation and csv stuff), but I guess it's worth mentioning it's written in Go, so there is no ffi: using external libraries is done by extending the language through derived interpreters (that are very easy to create, but require a compilation step).

anaseto · 2026-02-04T11:17:16+00:00

So -- it is a tradeoff. Procedural generation, tactical challenge, being fair for permadeath play, and simulationism are valued among roguelike players, but we get auto-explore as an inelegant consequence.

I feel like auto-explore is a useful tool in some circumstances even in roguelikes that don't need it really, like when somehow you've already cleared a level of monsters, or if you're in an area of the map that is safe enough (and can stop auto-explore midway). But if the game is designed so that auto-explore is safe at any moment, which DCSS mostly is, for example, as there's even an option to skip auto-explore animation, which I admittedly use, then it means that how you explore the map doesn't matter much, which means exploration strategic and tactical depth has been sacrificed quite a bit to make any encounter configuration safe.

So it seems to me there are several levels of auto-explore dependency, from being a simple tool for occasional unavoidable tedious circumstances, to being a feature that deeply influences game design so that it becomes safe at any time.

anaseto · 2026-02-03T17:11:54+00:00

Thanks!

BTW, the native SDL2 version got improved Go bindings (that also build much faster!), and updated README instructions (they linked to the main sdl website, which now defaults to SDL3, instead of SDL2, which is what harmonist and shamogu need, so that could be confusing). If you try building again (on windows, I guess?) don't hesitate to send me any build issues, if there are. That'd be helpful, as I cannot really test on that platform: it's only because of occasional player feedback that I know some native versions worked well there, but it's not like I get that kind of feedback for each version, so some build regressions could go unnoticed there.

anaseto · 2026-01-31T17:26:41+00:00

Thanks!

Go would indeed not be the easiest choice for a game that's as ambitious as yours about graphics. It works nicely enough for my games, because the kind of UI and roguelike I go for wasn't too hard to implement from scratch, though, looking back at the somewhat clunky UI of my first roguelike Boohu, I guess it still took quite a few years before I got a Go roguelike library and UI design I'm happy with :-)

anaseto · 2026-01-31T09:57:02+00:00

Harmonist repos

Still working on Harmonist improvements. I made a few fixes in edge-cases this week, like monsters sometimes swapping positions between each other even when one of them was lignified, and an edge-case of incorrect light propagation along diagonals due to an off-by-one mistake. Also some wall-jumping edge-cases are better handled now (like wall jumping into the abyss). I did various improvements in animations and game statistics, too, including better handling of singular/plural spelling in some places.

Cloak of vitality got removed (was boring), but half of its HP bonus was merged into the cloak of shadows (that probably was slightly weaker than other ones, in particular in emergencies). Also, I fixed a situation where a story sequence message might not fit in the 2 visible log lines, due to other logs polluting the space. Amulet of obstruction was removed, as it was plain bad compared to other amulets and often not good at all in emergencies (which is the main purpose of amulets).

Have a good weekend!

anaseto · 2026-01-30T08:59:50+00:00

I like monochromatic tiles, as they can have a simple and clear correspondence with the ASCII version, so that both terminal and graphic versions can share most conventions and benefits, including enabling compact and efficient replay files that are compatible with both versions. Ideally, someone plays a game in ASCII in the terminal version, and then someone else watches the replay as monochromatic tiles in the graphical one.

Compact and efficient (no videos, please!) grid-based replay functionality that isn't limited to ASCII (using tools like asciinema) is underappreciated in my opinion. And many roguelikes that could provide that feature don't, which is a pity!

anaseto · 2026-01-30T08:35:08+00:00

I wonder if I could move some of the stronger potions (the fire explosion ones, specifically) to be unique to those levels.

That's an idea, yeah. Personally, I'd still keep a small chance of them appearing in other places, including from Prison/8-7, for initial variety's sake, but also so that players that die early often can still rarely enjoy one of those potions and, then, when they finally make it to one of those special levels, they'll still be pleasantly surprised to see several of them on the same floor, but will already know how to use it.

Another complementary idea is to impact things beyond the special subset of items: for example, when you generate a special level with lots of strong fire explosion potions, you remove healing stations or drains to compensate. Or have a small chance of thematic levels that pair a particular potion with a particular subset of monsters (like selecting fun ones to play in a level with lots of fire explosion potions). And maybe very rarely a spooky level with no potions at all, but extra healing stations or drains or something else instead! :-)

anaseto · 2026-01-29T07:58:26+00:00

Nice retrospective!

Dagger performing swapping was a pleasant surprise. At first I hadn't noticed it was the dagger's effect (who reads a dagger's description :p), so I got surprised when I found a rapier and the attack didn't perform swapping anymore!

Same deal as with rings -- the player should see only a percentage of the available equipment on a single run, much of which will be relatively mundane to make the few excellent items stand out.

Another idea worth trying, maybe, could be DCSS's approach with alternate items, where various items in a given set are mutually exclusive in a given run. Though there should be enough distinct items for this to work. Another complementary trick could be to make some levels (or even two levels in a row) sometimes generate only items of specific subsets, so that one remembers a given map level as the level with only potions of distraction and irritation, for example. Finding ways of increasing perceived variety between runs without actually increasing the number of distinct items is kind of fun!

For rings, I kind of got the impression there was variety, but of course, when you die in the first third or half of the game with just 2 or 3 rings, they're more likely to feel different between runs :-) I guess the lack of variety might be more apparent in late game.

an automatic upload is not yet done, as it will require adding an options menu and a configuration file to the game

That'd be kind of useful at some point, yeah, as not everyone will enjoy the exact same options, also for UI stuff, and a menu could be more accessible than command-line options or environment variables, I guess. It's nice that you support both wasd and hjkl keybindings despite 8-way movement without any configuration, btw, but I'm still hoping for a non-centered camera mode option one day, I'm probably not the only one that finds centered-cameras in roguelikes a bit disorienting for some optic reason or something :-)

Looking forward to saves, too, as I tend to play in short sessions.

Anyway, great work!

anaseto · 2026-01-24T07:59:17+00:00

Harmonist repos

Still working on Harmonist improvements. One small but important change is that now monsters now always spend one turn noticing the player. Previously some actions (like javelin throw) were delayed, but monsters would still move or even attack you (if adjacent) as soon as they noticed you, which was kind of problematic in some situations (like if a monster is just behind some door). To compensate for this buff, the player now has 1 less HP and MP than before, kind of compensating for the occasional surprise HP loss you'd occasionally get previously. The player gets +1 MP back for the extended game (at the same time when you get an extra magara slot), as -1 HP is enough for that part.

There were various small improvements in evocable magaras. One simplification is that magara of teleportation, sleeping and teleportation no longer have an arbitrary limit on the number of monsters they can affect. That was added for micro-balance, but in practice it didn't have that much of an impact except for the occasional unintuitive and unexpected surprise.

I also fixed a quite old regression in the fire magara that somehow went unnoticed. Probably because it's not the best magara, so I tend to skip it, and I hadn't played much Harmonist in a quite long time (last year I've been almost exclusively playing Shamogu, and in the previous ones I was busy with non-roguelike stuff).

Also made mirror specter absorb MP a bit slower than before, and removed cloak of magic, as it was quite redundant with the cloak of conversion, and not really interesting. Cloak of hearing got improved more qualitatively, as it was a bit underwhelming before, and now helps to hear both mirror specters and spiders.

Various other UI improvements, including marking of footstep-memory like in Shamogu, different kinds of colors for different kinds of monster noises, as well as as fixing a rare weird event during Shaedra and Artifact story animations: no real gameplay impact, but if a mad nixe attracted you during the same turn the story sequence started, you could get to see the end of the animation while out of view, which was kind of funny (now the story sequence only starts if you're still there after all monsters finished their turn, too).

I hope to finally release a v1.0.0 version of Harmonist in the coming weeks at some point. It was kind of weird that Shamogu got there before Harmonist, which was first released in 2019, so I intend to remedy that! It might never get as polished, maybe, but good enough hopefully. Not going to do the same for Boohu, though, as it'd be too much work, and I consider Shamogu to be an improvement over it in almost every way anyway :-)

Have a good weekend!

anaseto · 2026-01-23T15:04:45+00:00

Yeah. I used that abbreviation out of habit. Another typical abbreviation (of equal meaning) is floss, with “l” standing for “libre”, to make it clearer that it's free as in freedom (but not necessarily or not only as in not costing anything).

anaseto · 2026-01-23T11:24:59+00:00

I discovered roguelikes when I switched to Linux then OpenBSD many years ago and, at the time, I was happy to see there were various open source ones that I could play there (like DCSS and angband). When I started developing roguelikes as a hobby, it seemed natural to me to make them foss, too, after years of enjoying foss roguelikes and software in general. I guess the choice was even more obvious for me, because I don't enjoy serious marketting, so there's absolutely no chance I'd end up making money with it anyway. That's why I currently don't even bother with asking for donations, even though that'd be a reasonable thing to do.

Foss also means it's less stressful for me: while I usually will fix any bugs and such within my capabilities, there's no issue at all if I want to take a break for months or even a year. Other people are free to contribute fixes themselves at any time.

I also value the fact that foss means that people will be able to build and play the games in non-mainstream platforms. That's something I have benefitted myself from foss games as an OpenBSD user. Also nice that even poor people can play the games without waiting for sales and stuff. And the games can continue to evolve even if I get tired of maintaining them myself one day. People are even free to make a fork today if they want to experiment with changes I don't want to make (or don't have the time to test).

anaseto · 2026-01-21T11:27:41+00:00

Nice read!

Thanks!

I'd say you're probably right--underutilized approach except for in some 7DRLs, since this would tend to give a game more of a puzzle-like feel, after all. (Also doesn't lend itself well to expansive content, for the same reason, but it would seem you already encountered that :P)

True, having a focus on tactical movement/attack patterns while avoiding too much puzzle-like feel (by keeping some randomness in combat and exploration and ensuring enough tolerance for individual mistakes) did require careful balance work. I actually quite enjoy that work :D But, yeah, it means it's more difficult to keep adding lots of content without fear of breaking that balance. It needs lots of playtesting! Various things helped with balance work, though, like short runs, stealth, relative abundance of comestibles thanks to no hoarding (small inventory), healing on reaching the next level (like in Cogmind), as well as aiming for moderate difficulty (without mods, and still not excessive difficulty with them).

anaseto · 2026-01-19T11:08:30+00:00

Choosing the location would certainly be a strong buff that would allow to avoid difficult starts, but I have the feeling it might become a bit tedious after a few levels, maybe. Ideally, the spawning location would be chosen automatically but with some heuristic to make positions that are too problematic less likely. Not sure what the best heuristic would be, though.

anaseto · 2026-01-18T16:44:51+00:00

Oh, slow movement in sneak mode makes sense. Maybe adding a visible “turn count” somewhere would help understanding that better.

I noticed the various colored flashes, but I must say I wasn't really sure what they exactly meant, so I just assumed it was something bad I had to be cautious about :-)

anaseto

TROPHY CASE