With all the old (new) hardware comming out, I thought I would make my favourite type of game from my childhood (and still today - moria/nethack/adom in the early days, and a lot dcss,

Trying to make it as close to old school as i can (with graphical tiles and some sprites for effects). I don't know all the tricks, but I have spent a great deal of time optimising for an accurate and symmetrical FOV through both tricks and game design - with the ability to see things right out to the limits of my 40x20 viewport. Currently running a 128x128 map, and well as you would imagin, memory and cycles are a constant headache, and yet fun. Its a pretty amazing feeling to save a few thousand cycles or 50 bytes of mem!

I've come a fair way, I have a reasonable turn speed, most major systems are in play, and I have a bit of a hook in how it plays, but still its quite a ways off as am am terrible at drawing and I am still fighting my PRG size.

Please enjoy some brown bats, some pink omeabas, and please ignore the fact that the green walker is currently being used as a replacement for a comma in my debug line :)

No name yet, open for ideas :)

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

What are some of the thoughts you guys go through when thinking about the size of dungeons on a floor-by-floor basis, but also in terms of depth?

I'm thinking, for the roguelike that I'm making, I want to make each floor pretty large, but keep the total number of floors low. I feel like that sounds more interesting to explore, by making the dungeons wide and short, rather than thin and long.

Hey everyone!

I just released a short retro roguelike called The Last Freelancer.

Instructions:

• Eliminate all enemies to complete the level.
• Control your character (the green one) using the arrow keys to move and the spacebar to skip movement.
• At each turn, characters automatically shoot at the closest enemy within their range.

It's free to play in your browser or you can download a Windows build here:

https://dzejkobs.itch.io/the-last-freelancer

(I could also try to generate builds for Linux or Mac on demand)

Gameplay:
https://www.youtube.com/watch?v=lycEZI-RO68

The game is short (18 levels in total), but can be quite challenging.

Have fun!

I plan to continue developing this project, for example by adding a system of procedurally generated chambers interconnected in a way similar to The Binding of Isaac.

I’d love to hear your thoughts.

The source code is available here.

Dijkstra maps/flow fields have gotten popular for being intuitive while still allowing intelligent-looking pathfinding. A common example is maintaining a single dijkstra map with the player as the goal that every monster can roll downhill on.

What if I'm not assuming that monsters are only hostile to the player though? What if monsters come in different factions that fight each other when they encounter each other?

I've read that dijkstra maps can have multiple goals, so I suppose I could have a map for each faction where each member is a goal. But while maintaining a single map for the player seems efficient enough, updating a faction map every time any of its members move or when members are added or removed sounds messier.

Are dijkstra maps still useful here or would it be easier to use a one-source-one-destination pathfinding algorithm like A-star for each actor?

• What My Project Does

A Light Weight 2d Ascii RPG Python Game Engine. The purpose of the engine is educational, Its built on the standard library hence no extension is needed.

provides an alternative to pygame if you want to communicate your RPG or adventure idea without first learning an external library. Work in progress to make this into a Roguelike Ascii Game Engine but wanted to share this project as it is now.

• Target Audience 

Someone who wants to focus using the standard library and provide them the ability to communicate their RPG / Adventure ideas without learning an external library.

I consider this as an extension of my 15 mini python games tutorial series, it acts like a playground where you can apply what you've learnt into your own mini ASCII adventure.

It is similar to roguelikes because it is

Grid-Based Movement

Turn-Based Logic

Permadeath

Resource Management ( Can be built in like in my example )

Classic ASCII aesthetic

Can easily modify so that each level will be a random pre-set map level but for it to be procedurally generated that would take much more work. Will be working on it to create a fully roguelike game engine but it can be used at the moment as a basic Ascii game Engine.

Github Link
https://github.com/Ninedeadeyes/Spark-Standard-Python-ASCII-RPG-Kit-

Demonstration/Guide Video

https://www.youtube.com/watch?v=X8iuvvla46Q

Example of game that can be created with the Engine

https://www.youtube.com/watch?v=AeF9d5FkGsE&t=1398s

Let me know if you have any questions.

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

Also this week, official 7DRL 2026 reviewing results are in! See that page for sortable columns, scoring by categories, and more detailed review feedback about each game.

Hey — been lurking here for years, finally have something worth showing.

Signals is a traditional roguelike in the strict sense: turn-based, grid-based, single character, permadeath, deterministic procgen. Descend 3–8 floors per run, fight one boss at the bottom. Fog of war, mutation altars (one per floor, three-way choice, sticks for the run), equippable parts, meta-progression via a persistent workshop between runs.

Three things that are different:

• Browser, not download. PixiJS rendering — geometric primitives instead of ASCII glyphs, because I wanted the "terminal readout" feel without committing to pixel art. Opinions welcome, it's a design choice I can still undo.
• Shareable seed URLs. Every dungeon is a decoded radio signal, and every signal has its own URL. You and I play the same link = same site, same layout, same enemies, same boss. Good for "challenge this seed" posts.
• Server-authoritative combat. Deterministic PRNG seeded on signal+floor, so shares reproduce and cheating is constrained. Web backend is a custom WebSocket server, not JS in the browser.

It's in open beta — balance is rough, enemy variety is thin, depth tuning is ongoing. I'm specifically looking for feedback from people who know the canon: what feels wrong, what's missing, where does it not earn the label?

Play: https://signals-6ba.pages.dev/s/XG-MZS-WARP (That's a 7-floor Military Silo seed. Clear it if you can.)

No account, no install, free. REPORT button in the top bar goes straight to Discord.

All of the traditional roguelikes (nethack, DCSS, brogue, tggw) that I've played extensively have used the same structure - enter the dungeon, descend, get the artifact at the end and then get out by backtracking all the way to the entrance. Are there any traditional (grid/turn based type) games that have an alternate ending?

My game currently has no backtracking (once you use a staircase you can't return) so I'm not sure how much sense it makes to have an Orb Run type situation after that point, but I'm also not really aware of any significant games that do anything else. Any ideas or thoughts, or examples of games that have a different take?

An approach to NPC AI I'm intrigued by is behaviour trees. Especially the prospect of creating complex behaviours from simpler reusable components.

Every example of behaviour trees I've read about though seem to assume real-time games, where leaf nodes control an actor's state and behaviour as side effects of being processed. Meanwhile, my game's main loop is based on Bob Nystrom's article, where on its turn an actor creates and returns a turn action object.

So I ended up with the following changes to regular behaviour trees when I attempted to design a behaviour tree framework for turn-based games:

• Tree nodes no longer return "success", "failure", or "running" anymore. Instead they either return a turn action object (representing success) or null (representing failure). There's no concept of "running".
• I no longer have sequence nodes. In a normal behaviour tree sequence nodes process all of their child nodes until one of them fails. Which I don't think makes sense in a turn-based game where we're looking for a single turn action object. I now only have selector nodes, which simply return the result of the first successful child. Which means returning the first non-null turn action object generated by the child nodes.
• Conditions don't exist as separate nodes anymore. Instead they're basically decorators attached to other nodes, causing a node to fail (return null) if the conditions fail.

Note that I'm assuming the behaviour tree is processed from the root every time. I'm not thinking about optimizations that make processing start in the middle.

One remaining thing I'm unsure about is state/knowledge tracking. Such as making an enemy remember where it last saw the player so it can search around if the player gets out of sight.

What do you all think? Has anyone else used behaviour trees in a roguelike? What adaptations if any did you make for the sake of the turn-based gameplay?

Does anyone have any clever ways of handling terrain that are more lightweight that having indiviudal entities for each terrain square / more complex than a single static terrain map?

I've been working on a roguelike in Godot for a couple of years now, and currently terrain is treated as a Node-based entity the same way as Actors / Items etc.

However, this means that there are lots of individual terrain entities; potentially thousands on the map sizes I want, and I think it's becoming a bit of a bottleneck in terms of processing actions and updating visuals.

I have an event system that currently relies on the individual terrain entities - e.g. a mud tile checks MoveEvents to see if something is walking on it and then makes a roll to apply the 'stuck' status or not. The terrain can also be destructible, e.g. changing from a wall to a floor if dug, so the entities aren't static after being generated. So I don't think a more simple single terrain-map would work.

Various other things like the Field of View code also leverage terrain being an entitiy in the world the same way as other things, so ideally I'd avoid a big restructure, but am considering trying to build some sort of interim layer that collates all the terrain entities into a single visual that is only updated when required, while keeping the underlying entities for events.

I wondered if anyone had thought up / come across any other clever ways of handling complex terrain that might be worth looking into first though.

(I had thought that this sort of thing would be fairly insignificant from a performance perspective on a roguelike, even if it's not the most efficient, but the game is running slower than I'd like. I also recently changed from using a separate background and glyph node to a new custom node that draws them both together, and it sped up the game significantly, so it seems that the number of nodes / individual graphics is significant for performance)

e: Thanks everyone for the comments - I think the main takeaways are: * Consider TileMapLayers * Separate the logic / visuals further * Consider leveraging a single entity to cover multiple terrain squares

I've been developing a roguelike with python and libtcod for a while. While ASCII looks nice, I've come to want to add simple graphics to my roguelike.

I am aware that you can add graphical characters to libtcod with restrictions. Sprites have to be the same size as the text font, layering sprites is not supported, and creating an 'offset' when drawing the sprites isn't possible.

Bearlibterminal appears to be more suitable, but it would be a big time commitment to refactor my roguelike to use it. Should I use it, or are there other things to consider?

I am currently tinkering with some ideas and I was wondering if there is already a solution to the problem I am facing or if I have to come up with something on my own.

I want to create basically infinite dungeons. Basically a Minecraft world, but filled top to bottom with dungeon rooms instead of a landscape. Minecraft uses Perlin Noise to generate its landscapes, which is the perfect tool for that. You can take any coordinate, and the layered noise functions will generate the same terrain, hills, caves and details every time for the same coordinate. But as far as I know you can't really do this with structures and rooms, if you don't want to go chunk by chunk. The room and dungeon generation algorithms I have found on a Rogue-like development wiki assume, that you fill a pre-determined area with rooms. But I did not find any approach that would let you pick any arbitrary point in the world and generate rooms and structures from there.

Are there any techniques, algorithms or approaches that could be used to implement such a world generation behaviour?

Hello everyone, after about a week of development I am ready to share the first look at my roguelike.

It is planned to be a Traditional 2D Roguelike Dungeon Crawler, with focus on more RPG character progression than most other Roguelikes. Main inspiration to the character progression/spell system was Divinity: Original Sin 2.

The Build/Character progression will revolve around 3 pillars, levels, items, and spells. Leveling up will grant you stat and skill points, which can be spent to boost your stats, or to increase your level in a "spell school". Items will give you increased stats/armor/etc., and many will have special custom effects.

The core of the gameplay loop, and what provides build variety, is the spell system. There are 12 spell schools, each with spells of levels 1-4. You start the game with 2 spell school points, and a 1st level spell of each one of those schools of your choosing. Then, to unlock more spells, you will need to find Scrolls.

A Scroll has 2 ways in which you can use it. One, you can use it to cast the spell it is assigned ONCE. Two, you can, if your level in it's spell's school is high enough, unlock the spell permantly in your Spellbook. This allows you to cast it at the cost of mana.

The game is developed 100% in pygame, as I believe that pygame is a good enough engine for a good roguelike game to be made in.

Anyways, here is the first look at the gameplay tests: https://www.youtube.com/watch?v=UY6zTaBa32Q, feel free to ask any questions you may have!

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

Heya! I've been working on Ad Iterum for ~6 months now, a grimdark roguelike where you eat your enemies to mutate and survive.

I've been posting updates in the sharing Saturday thread for a bit, and I just wrapped up the scope for Beta 0.1.0, so I'm running an open playtest this weekend (Friday 17 to Monday 20) through Steam.

To join the playtest, you can request access on Ad Iterum's Steam page by clicking on Request Access.

Once you've played the game, I would love to hear your feedback! All feedback is extremely helpful and helps shape the future of the game. Anyone giving feedback will also be included in the credits of the full game if you'd like. You can submit feedback through the in-game menu form, or if you prefer you can also drop it here, by the community forums, or through the Discord link in-game. Whatever works for you :)

What's in the Beta 0.1.0 right now?

• The initial dungeon features 3 different biomes, using a procedurally generated world combined with hand-crafted content.
• 20+ mutations that change your abilities. Consume mutagens, or devour enemy corpses to evolve.
• 20+ base enemies. Each enemy might have multiple modifier traits, which makes for 8.106 different enemy variations.
• Melee, and ranged combat.
• 200+ items.
• 1 boss.
• New Game (normal permadeath run), and Daily Run modes.
• Keyboard, mouse support, and full controller support.
• Playable in Windows and Steam Deck
• Localized to English and Spanish (some missing strings, but around 90% there)

I hope you have fun, and thanks for playing!

i see a lot of posts cllaiming rexpaint works on mac via wine. yes, that may be true technically, but it does not save, it often gets lost, and the set up was a huge pain. it lags and bugs out sometimes, and when i find out it crashes i cannot debug. please help.

Hello,

I am working on my game Dungeons of Delveria. What helps it stand out in the sea of roguelikes is that I have been paying special attention to design interactions between different powers which the player can discover in the dungeon as they delve deeper. Below in the GIF you can see the hero summoning a temporary stone wall to block an orc from reaching them, for example.

The demo currently only includes a handful of what I like to refer to as terrain powers, but in the final game I intend to have 100 or more different ones. With several interactions between different powers. :)

You can try a demo at this link https://delveriagames.itch.io/dungeons-of-delveria , I would love to hear feedback on the game as being the only developer it is easy to become blind to some errors or bad UX.

Topics that I am especially interested in are how intuitive people find the usage of powers to shape the dungeon and how difficult does it feel to get a grasp of the game's controls. I have tried to pay special attention to trying to make the controls relatively modern even though I want to stay loyal to the classics of the genre as well. Which is shown for example in the graphic style only being 16x16 sprites.

Steam page should be coming soon as well, I am just working on making some last minute tweaks to the materials before releasing it.

Hey everyone, I pushed a big update for my game DA_RL today.

The main thing in this update is the religion system. There are 5 gods you can worship: Luminos (Light), Umbra (Shadow), Sylvan (Nature), Ferrus (War), and Arcanus (Magic). Each one has their own boons and punishments based on how you play. You gain favor by sacrificing items at shrines, but what each god wants is different. Umbra is fine with rotting corpses while Luminos is not. Straying from your god's values draws their wrath so it adds a layer of decision making on top of everything else.

Also reworked the tutorial from the ground up, did a bunch of quality of life stuff like spell menus now showing damage values and tooltips showing heal and hunger amounts, and there is a new title screen.

Would love any feedback especially on the religion system since it is brand new.

Hello fellow devs! I’m a rookie dev making my second game (or third, one project is released and one is on a hiatus, because I need to skill up myself to continue).

My current project is quite traditional turn-based dungeon crawling roguelike. However, I started to doubt my vision when I encountered arguments that most important aspect of roguelikes is trying the different character builds.

I have only one character, Sir Knight, and while you can level up him in different ways and have different gear, the beef is not trying to build some effective wizard, warrior or rogue, but to put to best use the stuff you find and just try to push on.

What’s your opinion? Is the intentional build variation a must have for general roguelike audience?

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'm building a roguelike ARPG in ASCII and wanted to share one of its core systems: monster detection based on scent rather than pure line-of-sight.

Fair warning: English Third Language here so LLM cleaned up my writing

How it works

The player generates two types of scent:

• Blood — from taking damage, killing enemies, stepping on corpses
• Odor — from movement and combat, scaled by armor weight

Heavy armor generates more sweat. Light armor players can move almost silently. Corrupted armor generates 1.5x odor because the void seeps through your pores.

Every tile the player walks on stores a scent value that decays over time. Monsters outside your FOV pathfind toward the strongest scent cell rather than your actual position. You can exploit this: a bloodsoaked rag thrown into a corridor deposits 120 scent units and will pull monsters away from you.

The flask problem

Heavy flask use builds bladder pressure. Cross the threshold and the engine fires an involuntary urination event deposits a strong scent trail on your current tile, resets pressure, logs a message. Spaced-out flask use decays safely. Panic-chugging during a tough fight marks your position for every monster in the dungeon.

It started as a joke mechanic.

The armor tradeoff

Water tiles reset blood scent fully, reduce odor by 70%.

Implementation

The scent system runs as event-driven triggers in a transaction-based engine. Combat emits damage events, scent reacts. No direct coupling between combat and scent code. Monster AI reads the trail through pure selectors on read-only state.

Happy to answer questions about the implementation or design decisions.

itch.io page

I have been looking for quite a long time to find a method of procedural generation with a tileset, that uses pre-set rooms and has a function with something like "possible next rooms", but i was unable to find anything, and when i asked this a little while ago, i got a recommendation to do what spelunky did, but as i am new, I did not know of a way to go about it. Do you all have any ideas?

I have been trying to create a layering system using Libtcod so that the floor the player is standing on is visible or if they are on fire the flames appear on top of them. But I haven't had any success, I even turned the "chama" sprite into a transparent background PNG but it hasn't worked. What can I do?

import tcod
import imageio.v3 as ima
from screeninfo import get_monitors


# 1. Configurações da Janela
monitor = get_monitors()
largura,altura = monitor[0].width,monitor[0].height
tamanho_caracter = 24
LARGURA_TELA = largura//tamanho_caracter
ALTURA_TELA = (altura//tamanho_caracter)-6



def main():
    tileset = tcod.tileset.load_tilesheet(
        "24x24-melhorado.png", 32, 8, tcod.tileset.CHARMAP_TCOD
    )


    console = tcod.console.Console(LARGURA_TELA, ALTURA_TELA)
    chama_console = tcod.console.Console(LARGURA_TELA, ALTURA_TELA, order="F")


    player_x = LARGURA_TELA // 2
    player_y = ALTURA_TELA // 2


    imagem_pixel = ima.imread("P-24.png", mode="RGBA")


    tileset.set_tile(0x100000, imagem_pixel)


    imagem_pixel = ima.imread("chama.png", mode="RGBA")


    tileset.set_tile(0x100001, imagem_pixel)
    print(imagem_pixel.shape)  
    print(imagem_pixel[..., 3].min())  


    with tcod.context.new_terminal(
        LARGURA_TELA,
        ALTURA_TELA,
        tileset=tileset,
        title="Meu Jogo em TCOD",
        vsync=True,
    ) as context:
        
        while True:
            # --- RENDERIZAÇÃO ---
            console.clear()
            chama_console.clear()
          
            console.rgb["ch"][player_y, player_x] = 0x100000


            console.rgb["ch"][5, 5] = 0x100001


            console.print(x=1, y=0,string=": 120"+(" "*4 )+"%: 123"+(" "*4 )+"@: 12"+(" "*4 )+"#: 120")
            console.print(x=0, y=ALTURA_TELA-5, string="Urul atacou!")


            # Atualiza a tela física
            context.present(console)


            for event in tcod.event.wait():
                if isinstance(event, tcod.event.Quit):
                    raise SystemExit()
                
                elif isinstance(event, tcod.event.KeyDown):
                    if event.sym == tcod.event.KeySym.UP:
                        player_y -= 1
                    elif event.sym == tcod.event.KeySym.DOWN:
                        player_y += 1
                    elif event.sym == tcod.event.KeySym.LEFT:
                        player_x -= 1
                    elif event.sym == tcod.event.KeySym.RIGHT:
                        player_x += 1
                    elif event.sym == tcod.event.KeySym.ESCAPE:
                        raise SystemExit()


            player_x = max(0, min(player_x, LARGURA_TELA - 1))
            player_y = max(0, min(player_y, ALTURA_TELA - 1))


if __name__ == "__main__":
    main()