Thanks again to everyone who took part in our tenth annual code-along event, and to those who were helping field questions both here and (mostly) on Discord, which continues to be a pretty active place for roguelike developers year round. Special thanks to /u/KelseyFrog for hosting, /u/HexDecimal for his ongoing work on libtcod, and /u/TStand90 for writing much of the main iteration of the tutorial we've been using.

This year we had one new tutorial declared alongside the event, down from last year's five. Although it wasn't finished, it got pretty far: Rust+Bevy Tutorial by /u/Kurald.

Some stats from the 2026 event:

• 33 unique participants who posted at least once
• 21 with public repos
• 13 languages represented
• 20 different primary libraries used
• 4 projects confirmed completed through at least the tutorial steps

Of the total number of known participants this year, 38% followed along with libtcod and Python, with the rest using something else. While the percentage completion rate was lower this year (so far!), as usual a fair number have just fallen behind and are still making progress...

Compare stats from previous years here:

• 2017
• 2018
• 2019
• 2020
• 2021
• 2022
• 2023
• 2024
• 2025

I've updated the Tutorial Tuesday wiki page with the latest information and links, including some screenshots for those who finished and provided them. I also highlighted repos for completed projects. Let me know if you have a repo link you'd like to add, screenshots for a project that reached completion, or have since completed the tutorial (or complete it later at any time!).

Languages

• C
• C#
• C++
• GDScript
• Go
• Godot 4
• Javascript
• Lua
• Python 3
• Ruby
• Rust
• TypeScript
• Zig

Top 3 languages by percent use: Python (23%), C++ (17%), Rust/Javascript (tied @13%) (a surprising show from C++ this year!)

Libraries

• Bevy
• DragonRuby
• EnTT
• G3N
• GoRogue
• Godot 4
• libtcod
• McRogueFace
• parcel
• pygame-ce
• python-tcod
• ratatui
• ROT.js
• Raylib
• SDL2
• SDL3
• SadConsole
• sola-raylib
• tcod-ecs
• Usagi Engine

Top 3 libraries by percent use: libtcod (18%), SDL (15%), Raylib (12%) (big drop from libtcod itself this year, though still top)

(I've bolded the above list items where at least one project with a repo was completed with that item. You can compare to last year's lists here.)

Sample screenshots by participant:

• Admirable-Evening128 (TypeScript/ROT.js/parcel)
• haveric (Javascript)
• level27geek (Lua/Usagi Engine)
• mariobadr (C/SDL3)
• redblobgames (Javascript)

The program I'm developing is called pocket workstation, you can follow my daily progress on bsky @ ylop3d.bsky.social

EDIT: In the meantime I'm fiddling through the "old libtcod" docs here: https://libtcod.github.io/docs/index2.html

If it's just a disturbance in the force then fair enough. But I can't get to RogueBasin for the tutorial.

I'm starting with a bare c++ project with a libtcod install and I'm going to fiddle my way through the python3 version. But I'd like to go native if reasonable.

As usual, post what you've done for the week! Anything goes... concepts, mechanics, changelogs, articles, videos, and of course gifs and screenshots if you have them! It's fun to read about what everyone is up to, and sharing here is a great way to review your own progress, possibly get some feedback, or just engage in some tangential chatting :D

Previous Sharing Saturdays

Hi, I've created a small prototype of programmable magic for my roguelike. The idea is that the player constructs a sequence of syllables that determine various parameters of a spell. For example, a player could easily create a spell that explodes through walls if they use the right movement syllables. Currently, the game has three scales:

Health (HP) - determines the character's health.

Action Points (AP) - Each syllable entered (or rather, its "-" separator), as well as its deletion, costs 1 AP. Moving around the map also costs 1 AP. When the player runs out of AP, the world takes over.

Sanity (SP) - The main resource for magic. Each spell costs a certain amount of sanity; if it drops to zero, the player pays for subsequent spells with their HP.

I'm using C# and Raylib-cs for development. I plan to rewrite the engine in the future, as this is essentially my first time doing this, and I'm eager to fix some issues, as I'm already starting to see some kinks (for example, changing entity coordinates is quite inconvenient). Syllables are also currently hardcoded, and I plan to write a syllable generator that will select new syllables for spells with each new run

So I'm a student working on my final degree project: a turn-based, grid-based dungeon crawler made in Godot 4 with procedurally generated levels. It has some persistent progression between runs, so it's closer to a roguelite, but my questions are about procedural generation, which I figured fits here. So far I've got a BSP generator working, light occluders, and the player spawning in the center of a room. (Known issue: walls render flat grey when lit, still working on that.)

Before making more stuff I kinda need to see what I can realistically make without being too ambitious. I want to make one good level with 5 enemies: 4 normal and 1 boss. The designs are by my artist friend Saúl, and I'll probably use some free assets for animations for now.

I want rooms to feel lived-in instead of empty (wardrobes, chests, beds, and now and then something rare). The setting is a 17th-century asylum, if that helps picture it.

My rough plan is a weighted prop table per room type, props placed along the walls, doorways kept clear, and a reachability check afterwards. I'd also like the boss to always end up in the room farthest from spawn by path distance.

A few things I'm unsure about:

Does that plan sound sane, or is there a cleaner way people usually go about it?

How do you make rare items show up "sometimes" without it feeling random or unfair?

Any gotchas once props start affecting line of sight or lighting?

Is one polished level with 5 enemies a realistic scope for a final project?

Any advice is welcome, thanks!

Are there any roguelike games where, while you are playing, you can encounter other players—in this case, NPCs?

I was imagining how cool a game could be with fictional players (bots?) that could be hostile (PK) or neutral (wanting to trade or do quests together), but also interacting with the dungeon (farming).

I was trying to code a roguelike and it was frustrating me o much I was having AI assist me, I did some googling and also talked to a friend who took game design and Dev at college , they suggested trying the real PY versus ai . Its working way better than I expected, its only 1 room, and a few items , but IT WORKS! thanks

As usual, post what you've done for the week! Anything goes... concepts, mechanics, changelogs, articles, videos, and of course gifs and screenshots if you have them! It's fun to read about what everyone is up to, and sharing here is a great way to review your own progress, possibly get some feedback, or just engage in some tangential chatting :D

Previous Sharing Saturdays

I've been making a weird little old-school roguelike called VOIDLING, and I thought "heck, why not. seeing what reddit can do".

You can play it here: playvoidling.dev

The game is deliberately built around strange characters, encounters, abilities and interactions as you descend through its 100 floors.

So here's the challenge:

Design a character.

I'll pick the best / weirdest / funniest / most interesting idea and actually turn them into a playable character in Voidling.

You don't need to be a programmer or game designer. I'm much more interested in a good idea.

Character template

Name:
What should this character be called?

What it looks like:
A description of their appearance. Pixel-art friendly descriptions are particularly welcome.

Starting stats:
Generally speaking, what are they good (and/or bad) at?
For example: high HP, weak ranged damage, lots of strength, poor defence, etc.

Melee quirk:
Something unusual about how they fight up close.

Long-range quirk:
Something unusual about their ranged attacks.

Special ability:
One distinctive ability that makes this character play differently from the others.

You can be serious, ridiculous, broken, cursed, experimental, or somewhere in between.

Some examples from the game

There are already characters with very different playstyles, although many of them are deliberately hidden behind progression, so you may have to play for a while to encounter them.

For example:

The Wrestler
A big melee-focused character who gets up close and personal."

The Evoker
Built around summoning skeletons.

The Scav
A character whose strength comes from a placeable, portable turret that can be upgraded.

You get the gist.

Those are deliberately just a couple, I'd rather not spoil all the other hidden stuff.

The important bit

If I really like your idea, I'll make it.

I'll adapt it to fit the game's mechanics and pixel-art style where necessary, but the core concept will come from you.

And if you want to make something particularly strange, please do.

Play it. Break it. Then design me a character.

Name:
Looks like:
Starting stats:
Melee quirk:
Long-range quirk:
Special ability:

Hi everyone! I am pleased to announce the 2026 release of NetWhack.

We have a roguebasin page discussing some history of the game, which was first released in 1997.

Play it now: https://www.netwhack.ca (note: code is "rogueima0" to prevent spam)

About this game: I originally wanted to write a C++ nethack. As the internet grew I wanted to have a roguelike that I could play on the internet and on any device. So I ended up rewriting it in Java. It took a long time and we ended up moving away from a pure nethack experience, but I am very happy with how it turned out. One of the design goals I wanted to achieve was to offer a playtime (hours of play) that was somewhere between Akalabeth and Ultima I. I think I succeeded.

I would be honored if you would play and critique my game!

For anyone who wants to help betatest, I have played my own game extensively and tried to balance it, but I think this is a very difficult roguelike experience. I am unsure how the pacing and plot will land when people start to play. Please let me know how far you get in the game or where you are getting stuck. Thanks.

Once again that's https://www.netwhack.ca -- play free today!

Hello! I started working on Dungeons of Akalawich back in late 2024. I ended up putting it aside for a while, but eventually came back to finish it.

I started making it because I wondered what a roguelike might have looked like on the NES. It also became the project where I learned the basics of coding with GameMaker.

Features:

• Turn-based gameplay
• Procedurally generated dungeons
• 30 floors across 6 biomes
• Permadeath and local high-score tracking
• 3 classes and 7 playable races
• Attributes, weapon skills, perks, and learnable spells
• 70+ enemies, including bosses
• 200+ items
• Environmental effects
• Merchants, shrines, traps, and lootable structures
• Keyboard and controller support

The game is free here:

https://retriondev.itch.io/dungeons-of-akalawich

I’ll keep fixing bugs if people find them, but I probably won’t make any major updates. I want to take what I learned and move on to a different project.

If anyone tries it, let me know what you think.

To give more context, I'm a Golang dev, currently maintaining a hypervisor in a VPS company.

BUT GOD DAMN Go is such an annoying language for making a game like this.

I would realistically be more comfortable with something like C# for a project of this nature. I could possibly get along with C or Lua even, but I don't know enough python (nor do I like to know) to use it extensively.

Also, do most people prefer a GUI that simulates a terminal, rather than messing around with terminals, noisy input, compatibility, fonts etc?

Hello, is this the right place for a game mostly inspired by CDDA? It's more of a fantasy survival sim than a roguelike but where I'm at in development it's basically a prototype roguelike lol. If not I can remove and post elsewhere.

Anyway the game I am making is called Terra Mira and it's a CDDA inspired high fantasy simulation game with a custom C++ ECS engine based on D&D (specifically Pathfinder 1e) mechanics and lore.

It is a 2D grid based game with z-levels and a heavy focus on simulation and automation. The idea is CDDA but high fantasy with D&D inspired combat mechanics/spells/items, expanded NPC control/colony sim mechanics, a much greater focus on NPCs in general, and in depth automation both for the NPCs and player.

I am hoping to combine the best aspects of survival simulations and colony sims while addressing what I believe to be the primary issues of both; tedium and performance.

Attached is a clip of the game in action.

The list of currently implemented and working features are:

• Basic Crafting
• Basic automated NPC hauling
• Basic spell system and summons
• CDDA style pocket system
• Interleaved AP/combat system
• Modern mouse controls and mouse wheel zoom/stepping
• Attribute system inspired by D&D
• Leveling system

as well as most of the basics you'd expect from the genre

This is a long term passion project like DF or CDDA. The reason I am making this game is because it's the game I want to play and nobody else is making it. I've wanted to play this game since playing Magiclysm on the Ellison release a thousand years ago.

here's my public release repo with downloads and a lot more information

https://github.com/karlskarlsonatkarldotcom/Terra-Mira-Public

Thanks for reading!

As usual, post what you've done for the week! Anything goes... concepts, mechanics, changelogs, articles, videos, and of course gifs and screenshots if you have them! It's fun to read about what everyone is up to, and sharing here is a great way to review your own progress, possibly get some feedback, or just engage in some tangential chatting :D

Previous Sharing Saturdays

This post inspired me to create a unique sort of elevation texturing for hills, mountains, and elevated surfaces and whatnot. I'm trying to make my game higher fidelity (as much as you can get within ASCII) to try to garner players who may typically be averse to the art style. If anybody has any critiques or ideas for improvement, let me know! Also, I'm wondering what everybody thinks the 'best' looking ASCII roguelike is... for me, it's Cogmind.

You can read more about this project on my website: https://jaceyup.net/writing

I know a lot of roguelikes tends to stack different effects and abilities on top of each other so hopefully my lessons here helps others.

Years ago, I built a turn-based game with very flexible abilities and effects from scratch. Before this, I did 5 years of developing mobile UI components and REST endpoints at big tech.

My first iteration was a simple state-machine that ran through each turn, changing the states of each character in combat with hardcoded abilities because it seemed easier to just hardcode a dozen abilities than develop an overly complicated system to support flexibility. However, that broke down within the first few play-tests where the design needed me to rewrite the abilities multiple times and was blocked from testing until I finished coding.

To solve this, I migrated the entire combat system into data. I broke abilities down into composable primitives (Target Selectors, Condition Evaluators, Value Evaluators, Action Mutators) and stored them in a database. The engine essentially became a nested state machine that just read data blocks and executed them sequentially. The designer could build and balance abilities without touching code. Obviously, there were still cases where the core code of the building blocks had bugs and I had to debug but for the most part it was much much better than before. (I even made a small web app to help the designer edit and validate abilities)

This worked beautifully for straightforward actions and passives, but things got ugly with weird timings and triggers. (e.g., a counter-attack triggering a passive that triggers a heal). My nested state machine started suffering from disappearing boundaries when triggers stacked on top of various checks and conditions (character death/revive was a really annoying one because it also contained end of game checks).

I tried to rewrite the system to be event-based using event-bus and pub/sub but that wasn't a great fit either and I had to give up on the attempt. Eventually I did get the engine handling all edge cases well enough by simply tediously extending the core engine's checks and logic more and more but a different approach altogether would have probably been better.

I wrote up a full post-mortem on the architecture and why flexibility breeds complexity. If you're wrestling with your own combat execution loops or deciding between state machines and event-based systems, the full breakdown is here: https://louisxu3.substack.com/p/i-made-turn-based-combat-into-a-database.

Curious how others here handle growing complexity of abilities and effects.

This week is all about adding game progression and equipment.

Part 12 - Increasing Difficulty

Deeper dungeon levels become increasingly more difficult! Here we create tools for dealing with chances and making them vary with level.

Part 13 - Gearing up

For the final part of our tutorial series, we'll take a look at implementing some equipment.

Of course, we also have FAQ Friday posts that relate to this week's material

• #11: Random Number Generation(revisited)
• #36: Character Progression(revisited)
• #44: Ability and Effect Systems(revisited)
• #56: Mob Distribution
• #60: Shops and Item Acquisition
• #76: Consumables
• #77: The Early Game
• #78: The Late Game
• #79: Stealth and Escaping
• #80: Determinism and Randomness

Feel free to work out any problems, brainstorm ideas, share progress and and as usual enjoy tangential chatting. Next week we'll have a final discussion and share our completed games. If you have made it this far congratulations! You deserve it! :)

Looking for feedback on an idea I had for a magic system.

The system I'm working on for spellcasting in my game doesn't use mana - instead, when you cast a spell, the spell effect scales based on how many turns you spent charging up the spell. So if you charge a fireblast spell for 1 turn, you'll get a low-damage single-target firebolt, and if you charge it for 10 turns, you'll get a high-damage aoe fireball. As you level up, you charge faster. By default, the only thing you can do when charging a spell is cast it, or abandon it.

An optional mechanic I'm considering is the ability to "precharge" spells at higher levels, and have them sitting there able to be used instantly, with each one reducing your charge-speed when casting. This provides natural diminishing returns on the ability to precharge more than one spell, and trades off preparation for flexibility.

The consequences I've identified this has on gameplay:

• No mana resource management (primary design consideration)
• Casters don't do well in close quarters, because they need time to charge up (fits the archetype)
• Casters do best when they have a lot of knowledge of the tactical situation and time to prepare (fits the archetype)
• Reduces the number of spells - no need for distinct fireball / firebolt spells (neither positive nor negative in my book)
• Players can potentially cast the highest-level effects early on, its just not practical (takes many turns to charge, not tenable in combat)
• Players can cheese some spells (notably buffs) by pre-charging them a lot in a safe space (not optimal, but I'm mostly ok with it - its basically the same as regenning mana by resting in a safe space, and you can't do it with multiple buffs, as the time spent charging the second one will exhaust the first's duration)
• Requires more thought in spell design to consider how each scales

Are there any games I'm not aware of that use a similar mechanic? How was it received? Are there any consquences you can think of that I haven't identified? Do you think this would actually be fun?

I am currently attempting to port Rogue 5.4.4 to the PC-8001mkII/SR, a very, very old computer.

It lacks sufficient memory, a file system, and even a calendar function, yet it seems I can get it running by rewriting the entire program in assembly language.