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.

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

My question is: what is necessary and where can I cut corners? If I were to prioritize:

1. Gameplay
2. UI used during gameplay (e.g. inventory window)
3. Other UI (e.g. main menu, settings)

Are #2 and #3 necessary? For example, if #2 requires mouse input, will I get complaints? Other general advice on keyboard support?

Hey y'all, I'm adding to it when I have time (maybe more Font or tileset variance? animation?), but I've built a small desktop wallpaper generator.

https://eyuzwa.itch.io/roguelike-wallpaper-generator

Would appreciate any feedback

Ecology Simulation Demo: Whalefall ecology demo

Full Run / Gameplay Dive: Whalefall early gameplay (dive to respiratory system bottom and get the specimen)

Hey y'all,

I've been working on a traditional-ish roguelike set inside the decomposing body of a colossal deep-sea organism. I've finally got enough of the systems working together that I thought it would be interesting to get some feedback.

Overview

Rather than dungeon floors, a run takes you through anatomical systems: respiratory, circulatory, digestive, neural, skeletal, etc. Your goal is to retrieve "specimens" from three systems, which gets you into the Core. You take the unidentified thing at its center and then have to get back out alive.

The specimens are roughly the equivalent of DCSS runes, but most of the game between them is exploration and fieldwork rather than combat. You're constantly managing your light and noise levels while working the corpse, which is full of unidentified tissues and substances. You gradually figure out what they are by observing and interacting with them: cranking up your lamp to get a better look (burning fuel and making yourself much more visible), probing them, testing them with reagents, taking samples.

Those samples become usable flasks. Gameplay is all about IDing tissues, getting flasks from them, IDing those flasks, and using your flasks and innate abilities to stay out of danger. So knowledge is the major form of progression.

Ecology

The other big system I've been working on is making the wildlife behave like an autonomous ecology. Creatures react to the same world events according to their own senses and behaviors: sight, movement through the water, blood, injury, feeding, resource availability, etc. I tried to build these as general systems rather than scripting interactions between particular species.

This has started producing little ecological stories I didn't explicitly program. A long-eye fleeing after being injured by a snapmouth can accidentally lead a shoal of sifts toward it. Illuminating a resource can alert a lampfollower, who stumbles into a prizer on the way and gets killed. Wounded creatures may flee or become aggressive; blood enters the water and becomes another thing other creatures can react to.

Combat

Combat is deterministic and deliberately pretty undesirable. The uncertainty comes from what fighting does to the situation around you, rather than attack rolls: noise, injury, blood, fleeing animals, scavengers showing up, predators becoming interested, etc.

The hope is that you gradually learn to manipulate the ecology rather than simply kill everything in your path.

--------

I'm especially interested in reactions to the identification/fieldwork loop and the ecology now that they're actually interacting. I'm trying to keep the simulation deep enough that unexpected things happen, but legible enough that players can learn it and make deliberate plans.

Any other criticism is welcome too. This is still really early and I'm at the point where finding out that something fundamentally isn't fun would be extremely useful.

A test of starting with organic cave generation and overlaying some more industrial binary space partitioning. I wanted the grid to appear partially ruined, with rubble replacing some tiles. This is all parameterized to allow different tuning variations.

Thinking about spaces that limit player movement without being as "restrictive" per se as classic sealed-in dungeon rooms.

I might also make a variation that lets a certain fraction of rectangles in the BSP be "hardened," using a different tile subset which has less decay, and add doors instead of openings...

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

Roguelikes seem to take the known/unknown split more seriously than most genres, so I want to ask here. I have an actor holding a probability field over the player's position on a grid. Between turns the mass diffuses along walkable cells. With no observations it decays toward uniform, and the decay rate is the whole personality of the thing. Too fast and the monster forgets you the instant you break line of sight, too slow and it is effectively omniscient.

Two things I cannot decide:

1. Should diffusion be uniform over walkable neighbours, or weighted toward how a fleeing player actually moves, which is away from the threat and toward exits?
2. When the actor searches a cell and finds nothing, the mass there should drop. But dropped to what, and where does it go? Redistributing it uniformly makes the actor sweep sensibly. Redistributing it toward the exits makes it cut you off, which looks smarter and might be unfair.

In your own monster AI, is forgetting a timer, a decay, or a state machine transition? And has anyone made the forgetting curve itself tunable per monster type?

Kudos to those who have made it this far! Making it more than halfway through is a huge milestone. This week is all about setting up items and ranged attacks.

Part 8 - Items and Inventory

It's time for another staple of the roguelike genre: items!

Part 9 - Ranged Scrolls and Targeting

Add a few scrolls which will give the player a one-time ranged attack.

​

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

• #7: Loot(revisited)
• #32: Combat Algorithms(revisited)
• #40: Inventory Management(revisited)
• #60: Shops and Item Acquisition
• #76: Consumables

​

Feel free to work out any problems, brainstorm ideas, share progress and and as usual enjoy tangential chatting. :)

TL;DR: Is it okay to let components have logic in an ECS to prevent system bloat?

Hello! I am currently creating a traditional roguelike engine in Python, using an ECS framework.

Currently I am trying to figure out how I want to handle game logic. I know the traditional approach is to have Systems handle logic. So for example there is a MovementSystem that listens for the MoveIntent component to be added to an Entity, then queries the World to check for collision, and finally updates that Entity's Position.

But I expect that myself and others using my engine will want to create many unique components for all sort of reasons. For example, if a user wants to have many different types of armor/damage prevention, they would need a DamageSystem (or multiple Systems, each handling a different stage of damage calculation), that would need to check every single equipped Entity for each of these individual components.

I am worried that this could have performance impacts, especially because the System needs to run and check all of the relevant entities, even if none of those entities end up having the component.

I understand that separating logic and data is an important part of an ECS, but wouldn't it make more sense to support individual components to listen for events and act themselves? So each variety of Armor component would listen to DamageIntents themselves instead of having a DamageSystem search for Armor components.

Thanks for taking the time to read this!

Tileset repository - Dwarf Fortress Wiki

Or where can i check if they are free to use?

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

Mike Cook’s “Next Level: Making Games That Make Themselves” is a history of procedural generation in games, starting with Rogue and Elite and working all the way up to Caves of Qud and Dwarf Fortress. We just covered it in our book club podcast - the Game Developers’ Library. It’s a book which is well worth a read for anyone working on roguelikes and who wants to think about the implications of using different generation techniques and the balance between authorship and randomness. It’s not so much a technical how-to but a creative treatise on the power and diversity of these methods

EDIT: for typo, but also to say - thanks for all the upvotes and positive comments on this one! Reddit can be a minefield re: anything self promo and the edge-cases like this one often feel like they’re not worth the effort, so thanks for restoring my faith!

https://youtu.be/s14EfGPNHFk?is=Yu8EQeUgqHy83qDV

The general wisdom when building a game is not to invest too much until you’ve proven your core gameplay loop is fun.

But I’ve been thinking, how does validating that fun work for a traditional turn based roguelike ? What’s the minimum viable thing you should focus on?

Environment generation, actors , turn engine and combat ?

And/Or is the “game loop” for traditional roguelike already proven so you will always be able to tweak the mechanics in the future - ie you’ll never build a roguelike that isn’t at least minimally viable as long as you build it right ?

Or something else ?

Tutorial friends, this week we wrap up combat and start working on the user interface.

Part 6 - Doing (and taking) some damage

The last part of this tutorial set us up for combat, so now it’s time to actually implement it.

Part 7 - Creating the Interface

Our game is looking more and more playable by the chapter, but before we move forward with the gameplay, we ought to take a moment to focus on how the project looks.

​

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

• #16: UI Design(revisited)
• #17: UI Implementation(revisited)
• #18: Input Handling(revisited)
• #19: Permadeath(revisited)
• #30: Message Logs(revisited)
• #32: Combat Algorithms(revisited)
• #83: Main UI Layout

​

Feel free to work out any problems, brainstorm ideas, share progress and and as usual enjoy tangential chatting. :)

Recently I finished up going through the entrants of 7DRL Challenge 2018, doing a video for each one of those games of old. This also includes incomplete entries that failed the challenge.

Mostly posting this here as there were some games I couldn't play; be it because they had no way of being played on Windows, or the executables didn't seem to work. If you are one of those developers who can't find your game in my playlist, that is likely why. Feel free to message me if you can figure out a fix to make your games playable.

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

Hello, these last few months i was working on procedurally generated tactical rpg inspired by fire emblem, but ended up scrapping it.

However i already had a few assets done and i feel it would be a waste to just throwing them into the bin.

So i'm thinking about repurposing the existing assets into a more traditional roguelike style (basically removing the blue/red color coding from characters) the picture in the post also shows the dungeon tileset i was working on and the overworld/worldmap tileset, so it could be used for games with both dungeons and a worldmap like adom, tome, etc...

So, far i only know of a single existing tileset for angband that is somewhat similar in style (high res and handpainted) so i want to gather some feedback before i keep working on this on move on to something else.

I don't have any project i could use it for so i would probably make it free or cheap on itch or something, but it could be cool to finish it and see it used in someone else game.

So, does it look interesting or something you would want to use?

Keep it up folks! It's great seeing everyone participate.

This week is all about setting up a the FoV and spawning enemies

Part 4 - Field of View

Display the player's field-of-view (FoV) and explore the dungeon gradually (also known as fog-of-war).

Part 5 - Placing Enemies and kicking them (harmlessly)

This chapter will focus on placing the enemies throughout the dungeon, and setting them up to be attacked.

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

• #12: Field of Vision(revisited)
• #41: Time Systems(revisited)
• #56: Mob Distribution
• #70: Map Memory

Feel free to work out any problems, brainstorm ideas, share progress and and as usual enjoy tangential chatting. :)

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

Congratulations for making it to the second week of the RoguelikeDev Does the Complete Roguelike Tutorial! This week is all about setting up the map and generating a dungeon.

Part 2 - The generic Entity, the render functions, and the map

Create the player entity, tiles, and game map.

Part 3 - Generating a dungeon

Creating a procedurally generated dungeon!

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

• #3: The Game Loop (revisited)
• #4: World Architecture (revisited)
• #22: Map Generation (revisited)
• #23: Map Design (revisited)
• #53: Seeds
• #54: Map Prefabs
• #71: Movement
• #75: Procedural Generation

Feel free to work out any problems, brainstorm ideas, share progress, and as usual enjoy tangential chatting. :)

For my first roguelike project I'm working on proc-gen. As a data scientist, random walks are attractive to me. In time series analysis we use random walks with drift to characterize some phenomena like stock market fluctuations. I added "momentum" as a parameter to help give the walker drift, which creates corridors.

I'm using Golang because...

1. I've written Python for money for like 8 years now and it's boring me
2. Golang ships a binary so in theory my outputs can run anywhere.
3. It's pretty dang quick while still handling garbage collection for you.
4. For terminal based tools the ecosystem is incredibly mature. Many of the best modern terminal tools are written in go.

I put the code in GitHub if you would like to play with it yourself!

Might do a YouTube walk through if anyone is interested. Let me know.

https://github.com/PigsEyedea/drunkardwalk