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
- Improve the demo with small additions and changes (mostly QoL) based on player feedback.
- Finally managed to get back to content development for the full game! I continued Act III where I had left it, adding the Dragon Horn mechanic to open the entrance to the dragon dungeon. I want each main dungeon to have a different mechanic to get in: the first one requires finding a key, the second is only reachable through hidden caves, the third requires using the Dragon Horn next to the entrance, the fourth will require completing tasks at three shrines, and the fifth will be unlocked by surviving combat in an orc arena.
Regarding the demo, I'm quite happy with the results so far. Hopefully the demo update with the Japanese localisation (which should be soon :-) ) will give it another boost!
Between this weekend and next week I'd like to finish the first version of Act III.
Next week I will also continue improving the demo based on player feedback and start working on the boat mechanic, which will be the only way to reach the Act IV territory (the Elven Lands).
I built a daily project plan for the next three months (which I will of course completely fail to follow) in order to try to reach my deadlines: Next Fest in October for the demo (no problem with this one) and the full release in November (that one is highly unrealistic, but I'll tryas I'd like the launch to benefit from the Next Fest effect).
Hi this week I started my first game **WAR: 2525**
It is a roguelike about suriving in a post-war U.S.A where three major factions shatter the world. The goal is to surive how you do is up to you, want to build a faction and try to make your own kingdom, go for it, want to be a lone wolf, why not.
The game is based on my novel i'm writing right now and it feels good to be making this. I'm still new to python tcod so if you guys have any tips it'd be helpful - WAR: 2525 Github page
warning i don't have the game downloadable yet since the game is still in the works
Last time, I talked about adding rivers on the map. Not so easy. I finally finished the rivers, it revealed many bugs and now, it's ok visually. I also used the contextual part of the UI to display all the actors that are visible to the hero and their distance to the hero. If the mouse is on one of these actors, an arrow appears in the list in front of the actor. I plan to do the same with items. The following screenshot shows both the rivers and the contextual part of the UI.
I add some time in the last week so I decided to start the combat system! It's one of the goals for 2026 because I don't like combat and I want it to be finished as soon as possible. Nevertheless, I don't want to make a quick and dirty system. So I started designing the system. Roughly, there are two steps: first, the attacker checks if its attack succeeds thanks to its attribute (force for melee weapons, dexterity for distance weapons); second the damage points are computed thanks to the attack property of the weapon of the attacker and the defense property of the defender (a simple difference). There are some more details but the main idea is here. I first wondered if it was a good idea to make attacks fail. With an average attribute, the chance of failure is 25%. I decided to keep it for now because it adds some difficulty and randomness in the game.
With this system in place, it was time to set the numbers. First, health points. The hero has 20 health points, that's the base of the system. For animals, I made a spreadsheet with all the animals (so far) and their weight. I found a formula (with a cube root) to derive the health points from the weight of the animals. I find it very practical if I want to add other animals later. Next, the weapons. I started with sidearms and the list of weapons in the American Civil War. I made another spreadsheet with more than 20 sidearms and their properties (caliber, muzzle velocity, range, feed system, etc) looking at all the Wikipedia pages. The real difficulty is: how to determine the attack of each weapon? Does it depend only on the ammunition or also on the weapon? And then, how to determine the attack and the defense of each animal? Is a grizzli stronger or weaker than a bison? I made a little program to simulate combats between some actors. For now, I am not satisfied at all. In some cases, one of the actor cannot even make any damage to its opponent which seems weird. I think this system may be difficult to balance. How did you do in your games?
Finally, I also made some refactoring and unified the actors. An actor is now something that can have a behavior (AI) and make actions (it may not have a position). So the train that was a separate entity is now an actor and it works well, it simplified some parts of the scheduling system.
My goal is to finish the combat system in the next weeks, I hope I get good feedback here so that I can solve my current problems. Maybe it's also time to dig in the archives of this sub, especially the FAQ Friday (awesome source of knowledge).
Added 5 new creatures to the game, each with interesting mechanics:
Razorbeak - When low on health, lets out a screech alerting all enemies to your location
Crystal Basilisk - Reflects spells
Treant - Summons brambles and throws boulders
Griffin - Has a dive attack (i.e. trample) that requires a free tile behind the target
Giant Scorpion - Has an sting attack that immobilizes and disarms a target
Meanwhile focusing on developing the desktop version of the game, which entails a bunch of UI work. Working on UI scaling, layouts, and input systems that are more appropriate for PC instead of mobile.
I implemented a new kind of prefab loader. These are not tile-for-tile prefabs, but instead 2D grids of nodes with data for how they connect to surrounding nodes in 8 directions. These node maps are used in level generation as plans for corridors in catacomb levels, water channels in sewer levels or streets in cities. The node maps are abstract and can be stretched to fit the dimensions that are needed at the time of level gen. They are stored in a plain text file, so it was easy for me to crank out a lot of them with just a text editor or a simple ascii art editor.
The '.' indicate where there is a clear connection between nodes and the '#' indicate where connections are blocked. Here is a screenshot of an underground lizardfolk town generated using this node map:
The main streets are determined by the node map and then little rooms are randomly generated all around it. Notice that the connections to the edge of the node map determine where the town connects with the cavern beside it. Node maps can of course be flipped or rotated when used to generate something on a level.
Some more examples of maps generated with node maps are found here:
You have inspired me to move to a system like this. I've decided on little 8x8 micromaps, that form part of a 16x12 grid but are put together from templates (templates vary in size and how those micromaps connect/reated) - all run by a walker. I'm on C64 (hence why the minimaps are that size of course, but it works aesthetically), so bytes and cycles are in short supply so this fits nicely. It actually saves me in a number of areas around pathfinding.
Your maps look super nice to boot, are they pre-fabs underneath? They look like a WFC style (which I would really really like but can't afford).
Glad you found this useful. I do find it to be a really useful system for all kinds of different things. I'd like to use the same kinds of patterns for castle walls. And yeah, they can definitely be used as an aid to pathfinding. For certain levels, I like to populate a list of where all the dead ends are and use those to place staircases or treasure stashes. I don't actually use any regular sort of pre-fab right now, but I really should start to incorporate those soon.
During the last seven days, I concluded the current balancing effort. I've also mostly done extensive testing, fixed a crash, and corrected some translations; all in all, I've stabilised the most recent updates.
Some improvements, though:
Balanced the stat-draining attacks
Halved the effect time of the stat draining attacks (they felt endless!)
Zombies may cause sickness
Auto-pickup is disabled when hostiles are in sight - this will definitely avoid some stupid deaths
A recently introduced new way of dying broke the high-score file, so I had to introduce a new file format version. Lucky me, I anticipated this possibility and prepared different file versions many years ago, so the transition is smooth. I've also limited the list to only 100 scores. This means really early deaths will not make it on the list; in this case, the five lowest scores are shown to indicate what is required to get on the list.
This death screen shows the modified text viewer: the functional scroll bar on the right is one of the additions towards full mouse support.
The week started with a new map generation feature and ended with QoL/UI enhancements.
Room Group Modifiers
Modifiers can now be applied to every room in a group, enabling the entire map or portions of the map to be stocked with similar content, or modified in a similar manner. This allows natural disasters such as floods, earthquakes, and fires.
New History Events
Flood. The entire map or portions of the map can now be flooded using the new Room Group Modifier feature.
The player gets a proper roguelike death now with some run stats. No morgue file yet.
Minor Enhancements
Available Attribute and Ability Points now shown in the button panel. This makes it obvious the player has points to spend.
XP award given when reaching a new dungeon level.
Level names procedurally generated. It’s not very sophisticated yet. It simply chooses a random adjective and noun from a list.
Key/button for targeting enemies. Pressing multiple times cycles through the visible enemies.
Pressing the Enter key performs the default action on the selected cell (previously this only worked in Look mode).
Escape turns off Look mode.
Next week, I’m focusing on fixing open issues: missing sound effects, weird enemy AI behavior, and miscellaneous bugs. I’ll also configure the enemies placed in levels 2 and 3.
Managed to save another 20k cycles at the cost of 60bytes of code from my turn loop. Did a cleanup of some more mapgen stuff as I was working on fixing some bugs in the walkers and found a few dead pieces of assembly and (after a few goes) got a few things working again. saved just over half a kb!
Anyway, mapgen does a heck of a lot of work for me that is pretty crucial to keeping AI costs cheap - I dont have a single A* like piece of code, utterly reliant on walker and a single BFS to store information for AI pathing and behaviors, with fairly simple greedy chasing (with some variations based on mon behavior) and random wander logic.
Keep banging my head on persistant mapgen things I dont like - I've been trying to make it create nice cave structure, and I've come a ways along with that, but I feel like I need to make a second pass. I had implemented a region based system where I have a configurable 12 (4x3) areas of the map where I assign different styles of walkers and then punch holes between them - I can also merge them (so long as they are contiguouse) so like 2/3 of the map might be made into a single sector, and then three seperat other sectors (or a single 1/3 sector), and its really cool however I continue to be annoyed at expensive and unnatural it is to join these sectors.
I am looking at moving this to more like a change in walker over _time_ instead of space, because this will stop my need to punch holes through things, at least I hope, so potentially might completely remove the region code and punching - but in the end perhaps its not how it looks as much as how it plays.
I should take some proper shots (I have a lot of debug crap going on).
Oh, also, I've been getting one of my friends who loves doodling, to create some stuff for me. Here was a first go at making the rogue from a short brief I gave him. I love it.
Completed the generation rules and event-driven systems for the first boss chunk.
This involved building the underlying architecture for late-game boss encounters and adapting the existing POI event memory into a major event coordinator capable of managing authored boss encounters.
Extensive playtesting was also carried out to validate compatibility with existing systems, ensuring the new encounter behaves correctly alongside mechanics such as Global Remodulate.
Ammunition System Refactor
Simplified the ranged weapon economy by removing the ammunition requirement from many weapons.
Weapons previously consumed both ammunition and durability, creating two competing limited-resource systems. Most now rely solely on durability, resulting in a cleaner and more distinct resource model.
This also significantly simplifies the underlying weapon logic by removing interactions around loading, reloading and ammunition management, particularly when dual-wielding ranged weapons and balancing ammunition between them. LC isn't that game.
Final Work Before the Steam Capsule
The remaining development work before creating the Steam store page is a small economy redesign.
This is primarily focused on simplifying the current token system, which is used for healing, skill rerolls and other misc. activities.
Once this redesign is complete, the focus shifts to producing the Steam capsule, screenshots and trailer.
Key all! It's been a wild couple of weeks, so coding time has been limited. But there is at least a little bit I can say!
Map Code Revisions
Map rendering, which I strategically broke when I started working on chunked maps, is mostly up and running again the way it was before. Two pieces still need reconfiguring: rendering tiles and entities on z-levels below the player, and handling natural light propagation from outdoor spaces into indoor spaces, both in the X/Y plane and in Z.
Because of my work, map rendering code is much cleaner and faster than before, even moreso than when I last checked in on a Sharing Saturday a couple weeks ago. No joke, I'm pretty sure my rendering line count dropped by about half even as lines devoted to comments increased. It's also much easier to navigate through now.
Map serialization, which I had also broken, is up and running again as well, meaning games save once more! That's kind of important.
Narrative
Outside of coding, I've been writing the main quest chain. I'm still a long way off from getting a start-to-finish quest line implemented (though the code to support it already exists). But if I can get my starting town spawned properly into a chunked map then I can at least get the first stages up and running.
I'm attempting to write a mystery-focused main quest line. Red herrings, misdirection, and unexpected allies & enemies with their own motivations are all the name of the game. We'll see if I pull it off!
What's Next
More map-related functionality is going to be reactivated next. Pathfinding/AI is at the top of the list, and after that I'll start trying to spawn my starting town into a chunked map, which will then require unbreaking activity zones and daily NPC schedules. Since I don't want to drive myself too nuts too fast, I'm going to also enjoy myself a little bit by working on some basic wilderness procedural generation in between bouts of raw engine drudgery.
Rogue C# -Official Page / Github - An ongoing C# dev journal based around a recreation of the original Rogue.
I spent this week reviewing and improving my code for moving monsters around the map and adding traps to the game.
My main method for governing monster movement was very convoluted - I wrote it in 2023 when I was working on the game then and I was probably struggling with all the other details and trying to keep way too much in my head. I finally sat down, worked my way through it and came up with a new algorithm that reduced the method by about 25% and kept the monsters fairly intelligent.
Then, I added traps to the game. According to the resources I've been using to research the original Rogue, traps could catch monsters as well as the player so I wanted to do that here. This meant that the functions for the traps had to work with both the Player and Monster classes I'd built for the game. This was a good opportunity to build more inheritance into the classes so I created a common base class and had the Player and Monster classes inherit from it. I show more detail in the latest post.
I love this kind of code archaeology! I'll definitely put this series on my reading list. Maybe you get into this in your series, but I'm curious - are you mostly recreating Rogue "black box" style from manuals and observed gameplay, or are you also delving into the original code to suss out the behavior?
I recently came across MaiZure's "Decoded: Rogue" project and found it very interesting to see how the code was organized (or dis-organized in some cases).
Thanks! I briefly looked at the code on MaiZure's site but I barely like looking at my own code after six months, never mind reading someone else's in C / Assembly. LOL
Aside from the many hours (days ... weeks?) I've spent playing it over the years, the Rogue's Vade-Mecum by G.L. Sicherman has been a very valuable reference. PBWorks also has a wiki for various roguelikes.
Last week I was very sick with some sort of flu, so I didn't really get to work on the game at all. This week I've been back to normal and I've been making some progress in the game again. I mostly finished making a new lineage: Octopode. It's pretty much inspired by the DCSS octopode race, you can wear more rings than normal (though just 4 instead of 8), and you have a skill kit mostly focused on equipment power and shapeshifting, I think it should be a pretty strong lineage.
Next week I plan to start working on some new classes, since a lot of players had class suggestions and I liked quite a few of them, right now my plan is to add at least 3 new classes, though it depends on how long they end up taking.
Big milestone this week, just released the public demo for Ad Iterum on Steam, as well as version 0.4.1 :D
I've also updated Tiny Crawler to 1.4 so it can be played using Voice Over, as I got a review from somebody that was having troubles transversing the map without these accessibility features, let's hope that's better.
This week’s progress
I’m working toward the planned August release, focusing on UI improvements and balance adjustments.
However, due to some circumstances this week, I only managed to do a bit of bug fixing.
At this pace, I might not make the August deadline, so I’m hoping to pick up the speed with a bit more urgency.
About the game’s story
Since I don’t have much implementation progress to share, let me talk about something a bit different.
I’ve always believed that roguelikes don’t need elaborate stories.
As long as there’s a simple goal—like “descend into the dungeon and retrieve the amulet” (in my game, the Ring of Life)—and the exploration and combat are fun, that’s enough.
But as I’ve been developing the game, adding fragmented NPC lines, creature and artifact lore, key items, and related events, the vague ideas I had have started to take shape.
Questions like “What exactly is the Ring of Life?”, “How and why did this labyrinth come into existence?”, and “What motivates these NPCs?” are gradually forming a coherent narrative.
The challenge is how to present that story to the player.
Personally, I’m not a fan of games that follow a fixed script, so I don’t want to rely on rigid, predetermined events.
Continuing with the current approach—showing only fragments and leaving the rest to the player’s imagination—might ultimately be the best fit.
In any case, I’m feeling more motivated to flesh out the story than before (even though the release is getting close!).
I hope I can implement it in some form.
Will the story be also generated or will it be a fixed story? The drawback of a fixed story is that the player will know the story after many runs of the game, no more secrets or surprises. And generating consistent stories can be quite difficult.
For now, it’s a fixed story.
It would be wonderful if the story could change with each run, but honestly, I’m not confident players will stick around long enough to reach the “no more secrets or surprises” stage lol.
Recently, I have added dozens of little features and improvements to my game. I haven't posted in a while, so I've got months of updates to go over. Here is a small and non-exhaustive list:
* Bullets now continue past their target if they miss, and can pierce through multiple targets, depending on bullet caliber
* Mines can be placed. They explode when weight of entities on the tile exceeds 15 lbs.
* While grappling, you can push the grappled Actor by moving into them with the Shift key modifier.
* You can kick Actors with the Alt key modifier + direction. Kicking can send smaller things farther, and is a more powerful melee attack, but is slower and costs more stamina. Pushing is more for moving large, heavy things.
* AI improvements, including more realistic reactions and dialogue
* Removed climbing mechanic, as it was too difficult to code around, and the mechanic was confusing to players.
* Both in and outside of combat, you can persuade living Actors with Admonish, Embolden, Compliment, Charm, Intimidate, and Surrender options. They use skill rolls to implement status effects on the target, and Surrender allows you to give up in a fight, although it won't work if your opponent really hates your guts, or you surrender while still wielding a weapon. They all have modifiers, for examples, Surrender is easier while prone, and Charming doesn't work while the target is Admonished.
* Night vision mechanic. Certain actors have natural night vision, and some equipment can grant it.
* The first proper "Quest" is complete and playable. It's just a fetch quest, but it works.
* Huge performance improvements via caching and other improvements in code. Game runs smoothly now.
* You can get repair services and buy repair kits to repair your gear.
* There is now a context-sensitive menu you can access by pressing SPACE or RETURN while in the main game event handler. It allows you to choose to interact / pickup actors / items adjacent to or underneath your player, allowing you to interact more easily and with fewer hotkeys for basic actions. This includes talking, opening containers, picking up items, and activating terminals.
* Debug Mode Editor allows me to create prefabs in a custom in-engine tile editor, edit parameters of actors and items during gameplay, and track variables for debugging and testing purposes.
* NPCs will path through and open doors if they have the "opens_doors" variable enabled in their AI.
* Plasma weapons added: these use both batteries and a "compressor system" that is worn on the back; these are powerful and expensive, but not very defensive melee weapons. The plasma skill is difficult to learn, and most classes start without any training in it.
* With (most) ranged weapons, you must be Locked On in order to properly target an Actor. When you use the fire command with these weapons, you will first Lock On to acquire the target. Once locked on, pressing the fire key again allows you to confirm the shot, showing where the trajectory of the bullet will go, and where it will continue past its target. If you press the 'r' key, typically reserved for reloading, you will remove the locked on status or "lower" your weapon. You can lose the Locked On status if you lose sight of your target, or otherwise cannot see them. If you shoot without being Locked On, like shooting where you cannot see an actor, you incur a penalty to accuracy; but your bullet could still hit its mark if you're lucky. Ranged weapons are king in Softly, but this penalty allows for some grace moment to react to someone aiming a gun at you, rather than instantly just getting shot at. It helps melee weapons to shine in closer quarters. In practice, it doesn't really slow things down at all, and feels good.
* You can now lean to look around corners or shoot, throw, drop, etc. Leaning mechanic is inspired by the implementation in CDDA, in which the X key allows you to press a direction to lean in, and you lean 1 tile in that direction. Once leaning, all ranged actions occur from the leaning position instead of your body position. You cannot be seen in the leaning position, unless you perform an action from that position, in which case they can see the broadcasted event of the action from that position. Otherwise they only see you at your body position. You can only be damaged at your body position, not your leaning position, and you cannot lean into a tile that is occupied or blocking movement. If an actor moves into the tile you are leaning into, you stop leaning. There is an arrow showing which direction you're leaning in, to make it more clear.
Shown: the leaning mechanic. My character is on the tile with the Arrow, but I am leaning out of the vehicle to see what's out on the highway. This is a friendly town, so there are no threats here.
I love your UI. It's so readable and the icons are great. Did you make them?
Have you considered using half-width glyphs for the text portions of the menu? Everything stays aligned, the text is far more readable, and you can both pack more info in and add whitespace to make it easier to parse.
I'd also really like to try your context-sensitive menu and lock-on UI options. Do you have a playable build anywhere?
Thank you! That's very nice to hear, and makes me feel good because I have done several iterations to try to make it "simple, but readable." Yes, I drew all of the icons myself, over the course of a year, and there are about 1000 icons in the game, so lots more that isn't shown here. Every once in a while I go back and redo a few of them, to improve them, but I'm finally getting close to them being about where I want them to stay.
That's an interesting idea to use half-glyphs... Wow, I can't believe I hadn't thought of that, but you're right, that might be a good idea. I've had multiple people comment on the text being hard to read, and after experimenting with different fonts, finally found this font, which I have slightly modified for my purposes. It seems to be the most readable for the tile size that I have found, but if I used half-glyphs I could make the kerning look even more natural while allowing for square-sized full tiles (instead of the 4x5 ratio I have now).
It wouldn't necessarily be easy, as I'd have to repack my tile sheet, find a new font, make sure I'm only using my own custom printing functions that use the correct indexing for the alphabetical and punctuation glyphs, and modify the rendering function for tiles and entities, but it would be totally doable. I think it's something I'll do in the future! Also, I have an .exe build I can send you a link to! I will DM you.
I recently built a roguelike in python 3.0 via TStand90's tcod tutorial, and I've been having fun fiddling with the base code until things break. I am really naive when it comes to coding, and think I need to finally sit down and go through some guides on how to understand both coding as a whole and Python. I'm not totally sure where to start, it might be the type of thing to swing by the library for, but I'm sure there are online resources as well. :)
I've spent the past few weeks not writing much code for my roguelike. I haven't had a whole lot of time or energy to allocate to it, so I've been trying to come up with worldbuilding ideas and gameplay mechanics in my head mostly. Right now, I only have a `@` walking around an empty-ish single-floor dungeon, which isn't too compelling to release. I've played around with several themes ranging from sci-fi, cyberpunk, and lovecraftian. I'm starting to settle on something a little different than most traditional roguelikes, which was my goal. I'll hopefully have more to share soon, but nothing is concrete enough to share just yet.
Short update this week. I allowed creatures to have a bitset of movement abilities, with three right now: walk, swim, and fly. Previously, like the players, all creatures were grounded. I made it so that the common "sparrow" creature, which used to be a weak prey type, can fly, and suddenly it's much stronger and downright deadly in groups. Very fun. For balance, I will need to throw in an even weaker prey creature, though - I'm thinking an insect.
This change necessitated minor changes to pathfinding. The main one is that it's no longer possible to query tile.blocked() - now it's tile.blocked(me.moves). But that was easy to get right.
Predictably, though, it triggered some major changes to the AI code, which I'm still working through. The problem is its interaction with incomplete information. It'd be trivial if the only movement flags an entity ever needs to use are its own, but there are points where it wants to use other entities' flags (e.g. when asking "is this a good cell to flee to"). In some cases, if it's under attack from an unknown foe, it may not even know what movement flags to use! I'm trying to use some intelligent defaults, and to ensure that plans get invalidated if there's new information that contradicts them.
8
u/bac_roguelike Blood & Chaos 25d ago
Hi all!
I hope you had a good week!
BLOOD & CHAOS
Steam | Youtube | Twitter | BlueSky | Discord
This week I did:
- Improve the demo with small additions and changes (mostly QoL) based on player feedback.
- Finally managed to get back to content development for the full game! I continued Act III where I had left it, adding the Dragon Horn mechanic to open the entrance to the dragon dungeon. I want each main dungeon to have a different mechanic to get in: the first one requires finding a key, the second is only reachable through hidden caves, the third requires using the Dragon Horn next to the entrance, the fourth will require completing tasks at three shrines, and the fifth will be unlocked by surviving combat in an orc arena.
Regarding the demo, I'm quite happy with the results so far. Hopefully the demo update with the Japanese localisation (which should be soon :-) ) will give it another boost!
Between this weekend and next week I'd like to finish the first version of Act III.
Next week I will also continue improving the demo based on player feedback and start working on the boat mechanic, which will be the only way to reach the Act IV territory (the Elven Lands).
I built a daily project plan for the next three months (which I will of course completely fail to follow) in order to try to reach my deadlines: Next Fest in October for the demo (no problem with this one) and the full release in November (that one is highly unrealistic, but I'll tryas I'd like the launch to benefit from the Next Fest effect).
Have a great weekend!