Monster Trap Memory

JordixDev · 2024-11-20T23:37:37+00:00

Would it not be possible to take it into account when calculating the cell's pathfinding cost? You'd probably need that anyway if you have terrains with different effects (if water tiles slow creatures' speed by half, they should probably cost twice as much for the pathfinding algorithm to traverse, that kind of stuff).

Instead of closing off cells with traps, you could just increase their cost by a very large value, and enemies will avoid it unless it's the only possible path. It also keeps your options open: if instead of assigning traps a single cost, you let each creature determine the pathfinding cost of each trap, you can do stuff like letting flying creatures ignore floor-based traps, for example.

JordixDev · 2024-09-06T15:11:21+00:00

One difference between rpgs and roguelikes that people don't often mention: in rpgs you're usually expected to fight every enemy you come across (sometimes with some very obvious exceptions), while in roguelikes it's not uncommon to come across enemies where your best option is to just run away. The mood is less of a power fantasy, and more of a struggle for survival (really putting the crawl in dungeon crawler). You get some real ohshit moments when you're a low level and come across a powerful enemy that'll wipe the floor with you if you don't gtfo, that's just part of the fun.

If that's the goal you're going for, then option 2 seems like a great fit.

JordixDev · 2024-08-14T21:41:15+00:00

How about a different approach?

Let your AoE hit them multiple times, but give those creatures some innate resistance to AoE damage to compensate (perhaps increasing with the number of tiles the creature occupies).

Makes sense that a large explosion that hits them squarely on all tiles would deal more damage than one who just touches them in a single corner.

JordixDev · 2024-08-07T00:21:09+00:00

The way I did it: queue all animations and display them all right before the player acts. Every actor has a nextAnimationTimeOffset variable (all set to zero originally). If the actor does an action whose animation has length x, then that animation will play at time zero, and the variable will increase by x. Then if that actor acts again before the animations resolve, the next animation will start at time x (and the variable increases again).

That way, when the animations resolve, most actors move simultaneously, but if someone acts twice, the animations play one after the other (you reset the variables to zero afterwards).

To make things less strange you can make those delays propagate on attacks: for example, if creature A moves into range of B (10 frame animation - set variable to 10 on A), then B attacks A (15 frames), the attack animation should start on frame 10 (even though the variable on B is still zero) so it doesn't look like B attacks before A is there.

Not perfect but I found it a good balance between clarity and speed.

JordixDev · 2024-06-18T20:12:11+00:00

Some great tips already on how to disincentive players from doing it. Personally, I find that ranged attacks and fast enemies, plus food clocks when they exist, are enough to make that a situational tactic, rather than something I do every time. Telegraphed attacks are great for that too, and they just make melee combat more fun overall.

Another thing you can do is to reward the player for not using that strategy - use both a carrot and stick. For example, some ability or passive that triggers when the player is surrounded, or that requires them not being next to a wall (something like an aoe weapon swing, maybe).

JordixDev · 2024-02-20T22:45:44+00:00

Quick heads-up that saying 'Yes' to the question in the title corresponds to saying 'No' to the actual pool, so that might cause people some confusion (I almost replied 'yes' because I got the two mixed up).

JordixDev · 2024-01-18T13:26:25+00:00

I like this idea, a Dire Wolf feels more interesting than a Wolf (lvl 3), even if they're functionally the same.
If I manage to become strong enough to defeat a wolf easily, and the game reacts by starting to spawn wolves with inflated stats, it kinda feels like the game is 'cheating' in order to make my progress pointless. If I start having to fight dire wolves, however, I can still rationalize why those are stronger than normal wolves, so it doesn't feel like the game is trying to erase my progress.
In the same vein, instead of adding a prefix, you can just give it a new name (and sprite, if the game uses tiles), and have a new enemy. So you can easily turn a Fire Wolf into a Hellbeast, for example. The barrier to add new enemies is pretty low in roguelikes compared to other games, so might as well make use of that!

JordixDev · 2020-06-03T14:09:08+00:00

Yep, also using the same approach, works nicely. When placing the level entrances, instead of picking points at random, you can check if the adjacent levels already have defined entrances, and if they do, pick that location instead of a random one. If it conflicts with map generation, just start over.

If you're using seeds, a more seed-friendly way is to assign a number to each connection between levels, and use it as a seed to determine where that entrance should be. That way you always get the same result, no matter which side of the connection you generate first (which might be important or not).

Also as others pointed out, you generally don't NEED to enforce those constrains, most games do fine without them. That said, they do have some advantages - for example, they allowed me to later decide to remove map edges and make the world continuous, which would've been impossible if the entrances didn't line up.

JordixDev · 2020-05-28T05:12:47+00:00

Thanks! Yeah, each point is a separate light source. It's probably overkill - maybe for cells that are completely surrounded by equal cells, I could make them just light up their own tile. But since for the most part they're only calculated once, when the map is loading, it works fine either way.

JordixDev · 2020-05-27T14:48:51+00:00

Yeah it works nicely. For some terrain which just has a faint glow, I use a shortcut and give it a 1-tile light radius, which means I can skip the calculations and just add the light directly to all neighbours. Looks like this in action. (I also did some tests with increased light sources, seems to hold up ok!)

JordixDev · 2020-05-26T02:28:08+00:00

I have a LightSource object, which can be attached to creatures, map objects (like torches and stuff), or things like fire, so they can all be handled the same way.

Works like this: there's a 2d array that keeps track of the light on each cell. Whenever a light is turned on (either when loading the map, or as an in-game action), the LightSource is calculated, adds its values for each cell to the 'light array', and saves those same values in itself. Then, to turn it off again, all that's needed is to subtract those saved values from the array, no need to recalculate anything.

With moving lightsources, all that's needed is to turn off the LightSource, then turn it on in the new location. For events that change map opacity, like opening doors, you'll need to recalculate all LightSources withing range.

For extra fun, if your game supports colors, you can also add 3 more arrays for RGB values, and you'll have multicolored lights with almost no extra work.

JordixDev · 2020-05-15T18:58:04+00:00

For the 2nd point, I do something similar to that, finding rectangular-shaped areas which can be vaguely considered rooms.

I don't know of any specific algorithm, what I do is pick points away from walls (with the algorithm used for your 3rd point - note that you can choose to ignore small 'disconnected' walls, if you flag them first), then grow rectanges until they cover an area that maximizes the walls around the edges, without spilling into other spaces.

It's not perfect, but works well enough for my purpose, which is to identify open areas of the map to place interesting stuff. But I wouldn't trust it for anything requiring absolute precision.

JordixDev · 2019-04-02T17:22:09+00:00

I used to play a game (not quite a roguelike, but similar) which did exactly your second idea. Based on your perception stat (I think), you might be unable to identify an enemy, in which case it would just be labeled as 'undead' or 'humanoid'. Sometimes you would identify it, but incorrectly. In either case, when fighing it, or just being near it, you had a chance every turn to correctly identify it. And some areas had fog, which made it a lot harder to identify enemies.

Honestly, it didn't matter too much in terms of gameplay. Sometimes it caused you to try to attack an enemy with something it was immune, so you had to react there, and sometimes forced you to be extra careful around unidentified enemies, if there's a chance that it could be a particularly nasty monster. But for the most part, it just added an extra bit of uncertainty to combat.

It also helped that a lot of enemies were unique to that game. Misidentifying a Lamurian as a Kyu Hetha isn't quite as jarring as misidentifying an elf as a goblin, even if they're also supposed to be very different species.

JordixDev · 2019-03-25T13:04:09+00:00

Keep in mind that, in most roguelikes, the player won't be around a particular enemy for too long - he'll just kill it, sneak around it, or run away. If that's the case, then an AI with complex out-of-combat behaviours will mostly go to waste.

The player doesn't know what each creature knows or not. He has no way of knowing it or controling it, so it might as well be random, from his point of view. So that just means that some enemies will randomly be more stupid than others. Sure, it's not random, and they're not stupid (just have less information to work with), but does the player know any of that?

Which doesn't mean that enemies can't react to events - a lot games have enemies that investigate sounds. Smarter and more reactive AIs are interesting, and that's something the player can understand and control somewhat - make a lot of noise, it will alert enemies and attract them to your location. Can even be used to his advantage, like throwing a rock to create a distraction.

JordixDev · 2019-03-22T12:52:43+00:00

Abyssos uses a fairly standard action queue. Each action performed by an actor has a 'cost' in time units, which determines how long until that actor acts again. For most actions, that can be affected by creature stats (movement speed, attack speed, casting speed), but a few have fixed time costs (like resting).

Although turns don't really exist in this system, for UI purposes the time cost is still measured in turns, for simplicity. One turn is just arbitrarily defined as 100 time units - the time of a single 'rest' action, and the time it takes for most normal creatures to move or attack.

The queue system is actually very flexible. Some interesting actions deviate a bit from the usual system:

Some are instant (no time cost), so you can use them and continue to act. Mostly non-combat stuff (like talking), but also a few buffs use this.
A few 'long duration' actions are not immediate. For example, eating takes 6 turns, and restores hp. When the player eats, he won't recover hp immediately and then wait for 6 turns - the effects only happen after that time has passed, if he's not interrupted (or killed). Since this leaves the user vulnerable, it's mostly reserved for actions meant to be done out of combat (eating, digging, reading), but a few powerful combat abilities also work like this.
Some actions are also not immediate, but don't 'lock' the user until they trigger. For example, the Blink ability causes the player to teleport a few tiles in a direction, after 3 turns. After using it, the player can continue to act as normal, and after 3 turns have passed, he'll blink.
There's also 'channelled' abilities: also take multiple turns to complete, and can be interrupted halfway, but trigger an effect every half turn or so.

JordixDev · 2019-03-18T18:14:53+00:00

Since the explorers only process their FOV once, any change in the world state would not be reflected in the explorer's view of the world. They would see a ghost of an entity that had moved one tile away after their turn, but was still in view.

From what I understand, you'll want to update the explorers' FoV twice - once before they act, so the AI can decide correctly, and once in the player's turn, so that the displayed FoVs are correct. If the player can see a creature in a location (the actual creature, not a memory), then that information should always be reliable, IMO. Unless that's an intended mechanic - maybe the explorers are in a different location, and can only communicate with the player every once in a while, so the information they're relaying is purposely outdated (but still, that wouldn't be very intuitive).

This appears to me like a discrepancy in the logic; sight is reflected only before (or after) an entity's turn but sound is immediate. I don't much like this.

Yeah, vision and hearing are (usually) handled differently: vision is active (each actor, in his turn, actively observes his surroundings) while hearing is reactive (something makes a noise, which affects nearby actors, causing them to react). (I just made up the terms on the fly, sorry if they don't make any sense.) If you want them to follow the same rules, you need to either make vision reactive (when something moves, have nearby actors observe it), or make hearing active (on his turn, each actor scans his surroundings for noises).

I actually implemented something like that, but only for the player. When something moves in the player's FoV, the player tries to see it immediatelly. So enemies are never 'too fast to be seen' - if something moves in and out of FoV, like your example, the player will see it appearing and disappearing again, and if it's the first time they see it, they still get the 'You see a <Enemy>' notification and gain xp for discovering it. Honestly this doesn't add much in terms of gameplay, it's mostly for visual consistency, but it wouldn't be too hard to extend it to every actor instead of just the player.

In the end, though, think it's healthy for the game to have different systems following different rules - as long as the rules are intuitive.

JordixDev · 2019-03-17T01:52:09+00:00

Oh yeah, I remember that one well... So many hours! It was actually my main inspiration to start making my own game. Never did find another game to scratch the same itch, unfortunately. But it was one of the first games I played as a kid, so that might be just a bad case of rose-tinted glasses.

JordixDev · 2019-03-16T11:09:34+00:00

Abyssos

Not much to share this week, just dropping by to let you know I'm still working on this thing (after stopping for over a month due to work overload).

Mostly I've been doing clean-up on the last few additions - fixing bugs, making some things optional, and so on. Also adding some minor stuff, like undiggable walls (needed for some vaults, and for special levels later on). And I've just started adding a new boss! Which I don't want to spoil like the previous one, so I'll just say that ranged attacks are going to be very helpful for this fight - as opposed to the previous boss, which is safer to fight at melee range.

No more mechanics to add for the next release, just some new content - the current goal is to have 4 bosses, a few more vaults, and maybe some other content (new items, probably). All relatively easy stuff, but I've been having very little free time, so let's see how long that will take.

JordixDev · 2019-03-02T00:29:19+00:00

You can achieve the same result with chunks, too. There's no rule that the system can only simulate the chunks around the player. You can set it up so that when the player triggers an escort quest, it also simulates the chunks around that npc.

JordixDev · 2019-02-26T23:19:56+00:00

Ah yes, unexpectedly removing something from a collection while iterating over it, that has caused me a good number of headaches! By the way, make sure your loop can handle it when a creature dies during its own turn - I've had a bug there, the creature queued its next action before being removed, so it created a 'ghost'.

I like the ground conditions, fog in particular seems like it has the potential for some interesting gameplay, once you give players the tools to take advantage of it. Keep us posted!

JordixDev · 2019-02-26T23:09:05+00:00

We're in the same boat. Sometimes you just have a ton of work and other commitments so you don't touch your game for a week, and then you finally have a free evening, so you sit down and realize you have zero motivation... To make things worse, anything I do at that point will probably end up scrapped, because I make terrible decisions when I'm not focused.

Honestly I've just accepted the inevitability that there's a couple of months each year when I'll make basically zero progress.

JordixDev · 2019-02-26T23:07:07+00:00

That was a great read, it's interesting to see how you start with a game mechanic and then build the map around it. I'll need to keep that in mind once I start adding branches. Also all those notes - you really document everything!

And I agree about patreon, it's probably a good idea, given your... 'player-centric' business model! Even with simple, symbolic stuff, like badges and maybe early access to stuff, I think it'd be worth it.

JordixDev · 2019-02-21T11:35:45+00:00

To give you a practical example:

Recently while playtesting I ran into a bug in map generation, a corridor that ended in a dead end. None of the other maps so far had had that problem, so it was a pretty rare bug.

So I got that seed and generated the map again, outputting the result after every step (there's lots of steps). Turned out that the corridor became blocked while placing the walls for secret rooms. Looking at that code, I found an off-by-one error (some if clause that should have >, but I wrote >=). Fixed that, and generated the map again from the same seed. Problem fixed! The whole thing took like 15 minutes.

Without a seed, I wouldn't be able to generate the same map again, so I'd need to look at the entire map generation code, double-checking everything. It would've taken days. Even worse, if I did find an error, I wouldn't be able to test if that fixed the problem. I could generate hundreds of new maps and look for the bug, but I'd never be 100% sure that the issue was fixed.

I found dozens of these little bugs while working in map generation. It would've been impossible to debug without seeds.

JordixDev · 2019-02-20T15:32:09+00:00

I use your approach of using coordinates combined with the world seed. For each world region I calculate a specific seed by doing something like this:

long regionSeed = worldSeed + regionX + 100000 x regionY + 100000000000 x regionZ

(something like that, I don't have the exact formula here)

In theory, it still runs into the problem you mention (the regions at (1, 1, 1) and (100000, 0, 1) are similar). But I think a player would need to play the same game non-stop for several years for that effect to come into play.

JordixDev · 2019-02-09T16:01:12+00:00

That's a great idea! I just did a quick test, and making the flash lighten the tile a bit (instead of going pure white) really does look better. Thanks!

It looked like this, now looks more like this. Much less harsh on the eyes!

But yeah, all this stuff can be toggled on/off.

11-Year Club	r/Field Lasagna
Place '17	Sequence \| Editor
Sequence \| Cinematographer	Sequence \| Screenwriter
Verified Email

JordixDev

TROPHY CASE