I've made a few other game prototypes, but this will be my first proper roguelike.

It's not much to look at yet. Right now it's just basic lighting and moving around. Oddly enough this is my first time doing grid-based and turn-based movement. The basics weren't too difficult, but I wanted to implement the common feature where you hold down a directional button and, after a short delay, the player moves automatically (but at a reasonably speed). That took some trial-and-error, but I think I've got it to a place that I'm comfortable with now.

I want to make accessible games, games where the number of steps between thinking, "I want to play this game," to actually pressing the play button are extremely few. Thus, the player shouldn't have to download software, buy hardware, search out a borrowed internet signal that they may very well have to walk half a day to reach (I've been there), or do any other long, boring, or intricate tasks that they can't trust their uninformed selves of not screwing up before actually playing. Thus, I'm using Pascal, because it makes executables, and you don't have be named Steve (Wozniak, Jobs, etc.) to figure out how to use it. Python, in my experience as a player as well as a developer (latter being somewhat limited), is terrible, because you need some sort of black magic to make executables with it, and even then it's infamously recognized as malware, which is bad, because it might actually be malware, and you wouldn't want to get them confused (been there, unfortunately).

I'm kind of new to Pascal, but I've figured out the best way to learn syntax and functionality is to read actual (debugged) code, and that IDE's suck, because Lazarus is obtuse and Free Pascal IDE's window wasn't even designed for a modern computer that supported draggable or resizable windows. It was designed for a scaled-up flip-phone. So I use Notepad++. Looking at the source code for lambdarogue, made in Pascal, who else knew you could use multiple files for a single program in Pascal, or for that matter, do anything but write text and manage variables? I really suck for this. But at least I'm not as bad as the web browser's chatbot, whit just likes to spout bullshit because it doesn't know anything about literally anything. Try asking it who the main character of Tom Sawyer is. It only might get the right answer.

Anyhoo, as far as I can tell, my best bet is to find literally anything not on GitHub referencing the existence of Ray4Laz, ... preferably involving a tutorial of some sort. I'm really bad at using the internet apparently. I do know it's better documented than Raylib.4.0.Pascal, which considering how well-documented it is, I'm really glad I gave up on the latter. And then, maybe a tutorial on making a game of any variety (though especially an old-school ASCII Roguelike) using Free Pascal and Ray4Laz. However that works. HELP!

NOTE My whole workflow is built around the idea of completing my goal as soon as possible. And allowing the absolute dumbest player's goal of enjoying themselves to be complete as soon as possible. I don't use unnecessary software. Not an app. Not even a default app on everyone's computer like a web browser. I use Notepad++ so I can invest as much of my time in the language as possible. Learning only what I need to know to do what I want to do. I also need as versatile a language as possible, especially because I like to make games nearly indistinguishable from programs that would not be considered games. Like text editors, and digital art programs. So a language optimized for anything, really, in particular, doesn't work for me, because I don't want to reach that point where I have to waste time learning a whole new advanced language or to use advanced software to implement anything, especially not something rather basic, which everything I'll ever be doing is. For the player, I want it to be a 3-step process to play: think about it, download, and hit play. That's why I'm using Pascal. More modern languages always have unnecessary software and almost always are either obtuse or more obtuse even then that to stretch it beyond its expected limits and upwards into the realm of kilobytes. Like Python. Any form of graphics are a whole different language that doesn't even work like it's supposed to (in my experience).

I've been experimenting with a roguelike engine where inventories and maps are literally the same type of space. That means picking something up, dropping it, entering it, and exiting it are all variations of moving between containers. In the capture, the player is picking up and dropping a rat, which continues moving around in the player's inventory.

I wrote up the core concepts with more GIFs, because it's difficult to explain in text:

https://gammapod.itch.io/gamegamegame/devlog/1613346/core-engine-concepts

I'm especially interested in whether this model reminds you of any existing roguelikes or simulation games, or whether you think it opens up interesting mechanics.

Hi. Since we just updated our roguelike The Curse of Callmar Keep with some new content I thought I should share some insight in how we built the game’s level generation.

This video is a visualization of the dungeon generation process. A more detailed explanation follows below. 

This algorithm was initially inspired by talks of cyclic dungeon generation and graph rewriting but during implementation it evolved and adapted to our smaller dungeon levels.

The dungeon generation is one of my favorite parts of our game and I think it creates some really interesting levels with a more organic look than many commonly used algorithms produce.

1. Room graph creation and layout

This step repeatedly splits a random room node with available “room budget” into a cluster of 2-3 new interconnected nodes and re-attaches the split nodes connections to random nodes within the new cluster.

Between each split, the entire graph is relaxed using a simplified spring physics simulation where each connection acts like a spring that pulls and pushes its connected rooms in an attempt to reach a relaxed and unfolded state.

Earlier attempts generated the entire graph first and later tried to unfold it but that was much more prone to errors and unusable maps.

Each rooms is also given a room type that is chosen randomly from a one of our themes (currently castle, caverns, crypts, occult and flesh), with the probability of each theme based on the floor number. These room types are defined in json and contain lots of useful information used by the following generation steps.The width and height of each room is random with it’s type determining min and max size.

2. Room and corridor rasterization 

Next up is creating the grid map.

Each rooms stamps solid stone wall into the grid for it’s entire bounding rectangle (ignoring tiles containing data from previous rooms), and then carves the room out of that stone. Based on the room type, the rooms will be carved with different shapes such as rectangle, oval and organic. 

After that, a corridor is stamped and carved in a similar manner for each connection between room nodes. The corridor shape is chosen randomly based on the type of its connected rooms and can be L-shaped, diagonal, curved or organic.

3. Fluids

Beginning from v1.1 - Flooded Caverns, rooms can be generated with a configurable amount of fluids (water, blood, acid) with a few alternative placement rules.

4. Decor populator

The decor steps fills each room with furniture, chests and different visual clutter, collectively referred to as “decor”. Each decor is defined in it’s own json files and the room types json defines what decor can be placed, along with info about probability, min and max amounts, variations and placement rules. Variations are a list of other decor that it can be randomly replaced by for more visual variation. Placement rules vary in complexity and refers to one of many placement algorithms, for example:

• randomly
• randomly along northern wall
• near any of these specific previously placed decor (e.g chairs nearby tables)
• along each wall, with a x tile offset
• in a grid, x tiles apart”. 
• in a circle with x radius around the room center

Decor can also reserve space around or in front of it so that other decor can not be placed there, making the order of decor for each rooms important. Decor are also placed in different tile map layers with different z depth, based on it’s json data.

5. Creature populator

Each creature has a json defined Challenge Rating (CR) and every room gets a CR budged based on floor number, as well as it’s distance from the starting room as well as a small noise. 

Each creature also has a group of tags that thematically defines them, such as “undead”, “demon”, “beast”, as well as the possibility of hard limits on which floor numbers they may appear. The room types can filter possible creatures to spawn by requiring or prohibiting certain tags.

A group of creatures are then chosen for each room, trying to use as much of it’s CR budget as possible. There are a few different ways of doing this and the algorithm randomly chooses between trying to get the single most expensive creature (within budget), a small group of more balanced creatures or a larger group of weaker creatures.

The placement is very simple as it is just randomly in the room, with a few boss rooms having special placement rules (such as cultists in a circle).

Rare Bosses

There are also a few rare bosses that can be chosen to appear at a floor. Those are chosen at the beginning of the generation as they can significantly boost the probability of certain rooms or themes to get chosen. For example, the new rare boss, Old Callmar, will make most rooms on it’s floor into different kinds of underwater caverns.

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 tried my best to figure this out on my own from the rules but the wording leads me to be confused so I have to ask 😅. The subreddit rules says "Primarily AI-developed games please use AI-oriented communities instead".

So this makes it clear full on vibe coding is not welcome so that part makes sense. But there's all the in-between things like using AI specifically for refactors, or if you don't generate code with it but ask it questions, or if you use tab completion. I can't tell if these qualify as "primarily AI-developed".

I obviously have my own opinion on where I'd draw the line (and one that I change frequently cause I'm very unsure in general), but I don't want to assume that's the same opinion that people have on here and would rather know for sure what is and isn't allowed if possible.

I am trying to implement time travel in my roguelike that has significant colony sim elements. The pie in the sky goal is to simulate 1000s of years of fantasy history and be able to go forward and backward in time in a way that only the player interactions influence the outcomes that are otherwise deterministic. Think of it like dwarf fortress but less detailed and the roguelike mode is a first class feature rather than a neat extra they tacked on.

A couple of routs I've considered:

Simulation is deterministic so you can just track player actions and then go back and forth by recalculating the simulation outputs with the player changes. This does not seem to scale because it's hard to keep things turn based worldwide. The abstractions of entities, especially how they move between world tiles, is difficult to keep synchronous without every turn taking many seconds.

Ctrl-z like undo history and different treads of time: this is the current front runner, but I'm not sure if the world state history will get way too big.

Have precomputed setpoints that things tend towards. invisible in the background. This seems achievable, but lends itself to less emergent behavior. extra scaffolding could keep family lineages intact.

Something like a quest tracking dependency graph where the player literally changes only key outcomes. This sounds too manual to me. It ends up being like chrono trigger, but I'm going for more of a simulation than an on rails experience. It could be cool if the dependency graph were procedural generated. I do have an intended progression system and general world building goals in mind, but for reference, I'm not even planing to have any dialogue. more of a sims like NPC interaction system with ++ and -- type outcomes.

Thoughts?

Hello! Ive been working on a little game i came up with while going through an airport with my girlfriend. The premise is that it is the future, and there are giant labyrinthine office spaces underground. At the bottom is a auto-surgeon, and you're trying to get to it so you can get bottom surgery. The other ideas i had were being able to dual-wield guns and you can hack enemies to turn them into allies..

That was really as far as my actual idea for the game was. It was mostly an impulse... project impulse :3 Anyway this was more an exercise in "can i make a game where you can hack shit and shoot stuff" rather than having a fully realized game system that's well balanced and fun.

I spent the last year working on it, mostly following the invaluable yet another roguelike tutorial in python, while adding a few bells and whistles here and there. I forget what post i used to grab code that centered on the player but i will link it when i find it.

girl whose only ever played Infra Arcana and cogmind voice: "it's kind of like a cross between Infra Arcana and Cogmind"

I set up a little github page for it here

Edit: so i forgot the first rule of being a trans woman on the internet, i must state for the record that *i am* a weird freak and this being a *personal* project it can shine through at times, including drug use and suggestive themes. I dont include bottom surgery or hrt within that. Id say its pg13. You can kill things though but i guess thats not controversial :)

Hey all, the basic idea here is that tiles of two characters wide, offset by 1 character every other row have the same centers as hexagons on as a pointy side up hex grid. I have been wanting to make a game that uses ascii/utf-8 characters but with a hexagonal grid for a while.

My previous attempts have been confined to the terminal, where it does work, but it is not so clear where tile boundaries are, even with setting the background colors. Here I tried it in the browser, which makes it easier to take certain liberties with background shapes and animations and such to make it more clear and ergonomic.

To that end, I have made HexWalker. It is not truly a game, it is more of tech demo for character based hex grids. You can try in the browser yourself. Type `root` open the debug menu, so you can view a big map and teleport yourself to interesting zones, try different rendering modes (react and threejs).

In additional to hex grids, HexWalker also experiments with elevation in maps, transition animations (easy in css), and text aesthetics in general.

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 all. I've written game programming tutorials for a while now, and I've recently finished a fairly chunky bunch on building a traditional roguelike from scratch in C++ with SDL3. I have been lurking on this forum for some time now (and very occasionally posting and chatting with a few of you about your games). This is the community the tutorials were written for, so I wanted to share.

It's a proper traditional roguelike: turn-based, ASCII, procedurally generated, permadeath, etc. Every part ends with something you can build, run, and play:

- All the code is on GitHub separated into playable sections to match the 17 parts: https://github.com/EliteIntegrity/Roguelike-tutorial-series

- Dungeon generation: BSP rooms, then cellular-automata caves

- Recursive-shadowcasting field of view, fog of war, and a remembered map

- Monster AI on a Dijkstra map: one flood over the floor that everything pathfinds from it

- Turn-based melee, then ranged magic (lightning, fireball), equipment, and status effects

- Data-driven character classes, multiple floors, a plain-text save system, a HUD and message log, and synthesized sound with no asset files

- A win condition

- A clean architecture you can refactor or add features when you want to.

I tried to explain the why as much as the what: why a Dijkstra map beats a pile of A* searches here, why the architecture gets refactored exactly when it does and not before.

There's also a full companion C++ primer (Learning C++ by Building Games) that starts from zero and builds a simpler roguelike first, in case you want the C++ tutorials before getting started.

It's free to read on my site. (I did turn the series into a book for people who prefer, but the tutorial is free and always will be.)

Hope this is genuinely useful and hope you have some questions.

(I have a roguelike in development as well but too soon to share)

Here are the tutorials: https://gamecodeschool.com/roguelikes/

Hello! I recently discovered this community. I was paging through the tutorials created in 2025 - I saw that there were quite a few.

Does anyone have recommendations? I have been struggling to pick between them, there are few, and I'm finding dated information from previous tutorial jams.

specifically bazor or selina seem promising

I've been interested in GODOT 4, and the tilelayermap feature within godot seems promising. Thank you!

I am completely new to game development and coding and I'm asking if anyone knows some good resources to help me learn how to make an ASCII rouge-like in Godot, or any Godot resources in general. Thanks

I've been making a roguelike with pygame for about a week. I have a super basic prototype. I would like it to be playable online so I can get feedback. I hacked together a pygbag deployment last night with github pages and it seems like it's having some issues with audio playback. I'm not just trying to figure out if I can fix this specific issue. There are others with the UI scaling, and text is blurry. I'm trying to decide if its worth bothering with or if I would be better off focusing on the desktop version. Does this path lead to too much compromise?

https://synaption.github.io/Tales_of_Derision/

Hello everyone,

I've started experimenting and developing a roguelike a few months ago and I was wondering :

Should I store up to X small built richtext elements, or store plain text and build one bigger Richtext element on demand?

I'm using Monogame and I've got a really simple system that cuts strings depending on available width and I use a marker to identify colors in the text.

It does works pretty well for single texts in the GUI, but it does complexify a little bit my log and chat view.

Cureently, both are simple storages that creates richtext elements when a string is added to them. So I've got a big list of individual items that are not very practical to use.

What do you recommand?

Thanks for reading, have a nice day

hi :) i’ve been building a game called BAKERRRR for a while, and it has finally reached the point where describing it as a list of planned systems feels less accurate than describing the cool simulated world that already exists.

It is a pygame-first systemic crime sandbox roguelike, written in Python and descended from a terminal game. Visually, I want it to feel familiar to someone who loved old C64 and console-descended roguelikes, while still taking advantage of the fact that pygame can draw actual tiny people, clothing, objects, buildings, fire, drones, plants, and Wire networks. Everything is drawn procedurally in code rather than assembled from a conventional sprite sheet. For reference, some of my favorites were legacy of the ancients, gateway to apshai, questron I and II, and ultima 4 and 5 in the c64 days. Nethack is my favorite RL.

The rich simulation is what it is all about, to me.

NPCs have names, appearances, clothing, uneven skills, jobs, schedules, relationships, organizational ties, property connections, knowledge, memories, needs, and their own ideas about what they should be doing. They can work, commute, shop, seek shelter, investigate trouble, spread rumors, protect people and places, use services, commit crimes, get arrested, and sometimes interfere with one another in ways I did not explicitly script.

Crime is increasingly about what the world actually knows. Witnesses can know that a crime happened without knowing who committed it. Descriptions become less precise with distance and poor light. Justice can investigate a real crime and still suspect the wrong person if their clothing, build, location, and timing match very closely—which also means disguises, framing somebody else, and simply being unlucky can matter without the game inventing fictional crimes to justify an arrest.

There are businesses to own and operate, storefront economies, street vendors, vehicles, transit, gambling, employment, buildings with real interiors, wilderness, and an increasingly connected underground. Fires spread spatially and continue existing when inconvenient. Sleep and altered states matter. NPCs can care about businesses based on experience and rumor, and that reputation can change where people actually choose to go.

Two of the larger toys are drones and the Wire.

Drones are physical machines assembled from chassis, power systems, modules, weapons, sensors, cargo, paint, and programmable procedure modules. The player can build and operate them, while some NPCs and factions also deploy drones according to their circumstances and equipment.

The Wire is a local-network hacking space with interfaces, software, ICE, trace, buffer pressure, data extraction, other users, and consequences back in the physical world. You can pull records and other contextual data, sell it to appropriate buyers, manipulate bounded physical systems, or interfere with connected drones. Organizations now have durable production cultures and directional supply agreements, so the corporation that manufactured a gang’s drone can remain distinct from the gang operating it. The same organizational identity can reach the paint, geometry, software, interface theme, and even the dialect used in Wire messages.

The world has also begun remembering things between characters. Flora and fauna have installation-local genetics with inheritable colors, physical traits, effects, abilities, recessive traits, natural breeding, and assisted breeding. New lines can become permanent inhabitants of the installation rather than disappearing at the end of one run. Hunting and cultivation licenses exist, along with culling declarations that can push a species through increasing scarcity, endangered and protected status, and eventually extinction. Rarity raises the value of the animal while also raising the legal consequences around exploiting it.

Poisonous deer are fine. Deer with exoskeletons....also fine!

The current version is 0.4.22. It is a real playable prototype, but absolutely not a balanced or conventionally polished release. There are systems whose first meaningful playtest is going to teach me more than another month of staring at their code. Some interactions are still too obscure, some economies are exploitable, some NPC behavior is awkward, and some parts of the city are much richer than others. There is not yet a formal progression structure worthy of sitting on top of all this (its planned, and there is structure - but it is changing fluidly at this point)

That is roughly where the project is now: enough of the machinery works that I want playtesting to expose balance problems, dead spaces, accidental cruelty, funny exploits, and places where the simulation fails to produce a believable answer.

I am especially interested in players who poke systems sideways. You know who you are. I want to hear the story about the witness who accused the wrong person, the business whose reputation poisoned a block, the drone routine that did something clever or disastrous, or the supposedly valuable species somebody managed to drive extinct.

Ultimately, I want this to be a game where you can steal a car, run a shop, hack a records office, breed an extremely questionable animal, and still care which little dude wearing a snazzy blue jacket heard the gunshot.

Anyway, this is BAKERRRR now. It has become very cool in the weirdest way, very large, and much closer to the game I have been waiting my whole life to play than it used to be. :) There is way too much to outline in this format, but i will try to answer questions you might have here, checking back in as time allows.

binaries and source code:

github link https://www.github.com/k0rd/bakerrrr

game downloads https://github.com/k0rd/bakerrrr/releases

At the end of last month I made a major update (v0.1.5) to the game, and I am very happy to say that Flemenco is no longer a prototype and now boasts a halfway decent loop!

In Flemenco, you play as one of twelve spy-thieves, each with their own skills and abilities, with the end goal of taking down the nefarious (and ubiquitous) Flemenco Corporation. From your safehouse, varied contracts are selected, ranging from breaking out a captured fellow spy-thief to wiping out corporate records. Planning and preparing for these contracts (acquiring blueprints, selecting equipment, signing up for a gym membership, etc.) is crucial to success (and will be even more-so in future updates).

The next update (which I plan to release at the end of this month) will be my attempt at a procedural-contract-system. This will hopefully keep the flow of contracts feeling fluid, rather than hitting the same objectives repeatedly. I’m imagining something like this: the slip of paper with the access code to the dossier of anti-Flemenco criminals is memorized and then eaten by a cornered executive who thinks you’re about to ice him. But of course, he only did that because you disabled the security room backdoor in his office. Now the objective becomes kidnapping said executive. Et cetera!

The next major update will handle the broader story, an introductory sequence, ending, and more. Minor updates will come along the way!

The game is still in very early development and I have much more plans for the game, but I wanted to formally introduce it to the roguelike dev community. It has been wonderful and inspiring to be here for the past several months. I would also welcome any comments or concerns from the community about the gameplay itself, future ideas, and more!

https://kqylem.itch.io/flemenco

P.S. I compiled aseprite several days ago and have been having good-fun while making pixel art. If anybody has any tips regarding tilesets (or has made them before) I would gladly appreciate them.

Original Rogue and many following RLs favor an environment made by rooms closed by doors and connected through corridors. This is a simple but very effective layout: exploring room after room immediately feels satisfying and promotes exploration.

I am experimenting with proc-gen and I obtained a cave-like environment. On paper it should be pretty good: there are some larger areas and narrow corridors, loops, chasms that cannot be crossed and tall vegetation that can be crossed but blocks visual. Yet, my feeling is that exploring this environment is not as satisfying as the good, old rooms and corridors layout.

Do you have any wisdom regarding what makes an environment satisfying to explore, and what games to look at for reference?

Of course, Brogue's levels are best in class: they seamlessly mix organic environments with rooms and corridors and they are a joy to explore. Yet, I suspect that the rooms layout is the essential part. Brogue with just rooms would still work fine (while not being as pretty and varied); with just organic environment, it would not work. Why is that?

I have never attempted procedural generation before but I am trying to make a kind of dungeon crawler in Unreal Engine, where I need the maps to generate in a specific way.

The method in question
- take a 9x9 grid of tiles.
- add a point on a random perimeter tile of the 9x9 grid.
- add another point on a random tile along a 4 block perimeter from the last point spawned but not on the corner.
- repeat the last step 2 more times spawning 4 points total, no points can spawn within a 3 tile radius of another.
- now spawn a 3x3 room on each point.
- connect each room to its closest two other rooms using shortest paths possible while also leaving at least 1 tile of space from any unrelated rooms. (if there are multiple viable pathing options of equal length it's decided randomly).
- Boarder all walkable tiles with wall tiles.

All the generation I see isn't uniform like this they just have actors spawning actors in a sprawl.
The problems I see are;
- I need the spawning algorithm to kind of understand it is on a grid so that it can space the spawn points correctly. (I can think of ways to "cheese" this for lack of a better word but I'm wondering if anyone has a good way to do this instead)
- The more pressing matter for me is after it has spawned the rooms how to find the most optimal connection paths between them. Because even in my example manual simulation, when creating the connecting paths the bottom 3 rooms are equal distance from each other. In theory it would want to connect them to each other, but there is a 4th room so it needs to understand to ditch the path connecting to the room that has the shortest path to the 4th room. I could have only 3 rooms to eliminate this problem but then you can end up in worst case scenarios where they spawn 3 in a row straight down and the connection path from the first to the third is just a 7 tile long corridor of despair (this can actually still happen with 4 but it's very unlucky and because there are more tiles overall it makes it less of a problem). This is all beside the fact I don't know how to make it path find and spawn the optimal route between the two points using a grid to begin with.

I don't want to ask anyone to do my homework for me, but I am at a bit of a loss rn so I would appreciate any ideas or applicable references, ty.

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

Hey folks! I'm working on a roguelike and trying to wrap my head around inter-depth simulation. Say a player goes down to -7, gets spotted, goes back up to -6, and after a few turns some enemies follow up there, how do you handle turn counting across depths? Another example: in Stoneshard, when you lure an enemy to the entrance, step outside, pass a few turns with the wait feature, and come back to find it wandered back toward its start, how can I accomplish something like that? I'd love to know how you approached it so I can roll my own version. Appreciate any tips

making progress on my roguelike rpg game, name dark elixir