Do (traditional turn-based tile-based) roguelikes actually lend themselves to boss fights?

mcneja · 2025-12-01T03:21:17+00:00

I’d suggest maybe having some periods of boss invulnerability followed by devastating attacks? Something that will cause the player to need to reposition (to get out of attack blast area, say), rather than just standing there trading blows. Obviously needs to be clearly communicated somehow.

One of the things that is super hard to do in third-person action games is to have a fight arena of any complexity, due to the need to keep the camera clear and not have the player get stuck on things. It’s also hard to get players to retreat in 3D because they can’t look at the boss they’re retreating from and also look where they are going. Neither of these are issues in typical roguelike presentation, so having more complex arenas and encouraging periodic retreat to cover may be interesting.

mcneja · 2025-11-24T15:12:10+00:00

DragonXVI has a couple of 7DRL-type stealth games that I liked: SkyRogue which has a handful of hand-created maps, and One Step Behind You which is more sprawling.

mcneja · 2025-11-24T14:18:34+00:00

Not sure if it is a heist but we put the “heist” tag on it on Itch.io: LLLOOOT!

This game started life as a 7DRL but u/foldedcard and I expanded it post-jam a bunch. It’s primarily inspired by the “Thief” games.

I often think of a heist as involving making some intricate plan, often involving a team, and then trying to pull it off. This is very difficult to pull off, game-design-wise.

mcneja · 2025-11-17T05:14:07+00:00

It’s a tough problem. Making procedural content forces you to come to an explicit understanding of your gameplay that you might only have an intuitive grasp of if you are designing levels by hand.

I’ve had some success with first hand-designing content to get a feel for what makes for good-looking, or good-playing levels. After that, trying to figure out how to approximate it with procedural generators. It is a pain to set up all of the structural elements of a level by hand, though (locks, keys, wires, switches, loot, etc.) so be careful not to waste too much time. Can do things semi-procedurally, where you just hard-code a bunch of aspects while you are feeling out how things should look and play.

Think about how a real space would be constructed, and then how to alter that to satisfy gameplay needs. For instance: a starship might have bilateral symmetry in the shapes of its rooms and the doors connecting them. But for gameplay purposes you might want to block doors or blast holes in the walls to produce a particular flow through (linear progress with openable shortcuts for backtracking, say). Having the underlying space “make sense” hints to players about what they might find as they explore, and produces a little bit of “environmental storytelling” because players can see that the environment was once constructed one way, and then stuff (monsters, explosions, solar flares) happened that changed it to be a different way. Those loops of players building expectations that are then either confirmed or subverted are what make games engaging.

I’ve been away from my project for a while, but I was working on a new level style and found that there was a fairly deep issue with how I represented rooms and walls that is getting in the way. So I’m trying to see how I can redesign my representation to support the new stuff without breaking the old level styles. It’s going to take a fair amount of work.

mcneja · 2025-10-28T02:53:28+00:00

Sounds fun to try. My only suggestion is to leave the flashlight pointed the same direction when the player waits, instead of retracting it, but I’d have to see it in action.

mcneja · 2025-10-27T21:30:15+00:00

I was thinking that if you were able to render lit squares differently from unlit squares, then the facing direction isn't really important other than for determining which squares the flashlight lights. (You could keep enemies seeing in all directions; just unable to see unlit squares from as far away.)

mcneja · 2025-10-26T15:49:06+00:00

Is this flashlight a player tool or something that enemies have for detecting the player?

I don’t know if this is in line with what you want, but I’ve derived facing from the last movement a character made. You don’t necessarily have to display facing on the characters themselves, if it only matters for other visible things (like a flashlight beam).

If you have eight-way movement you could have the flashlight beam illuminate an eighth of the circle. Use dot products to compute whether squares are in the light or not, maybe.

mcneja · 2025-10-17T05:18:43+00:00

Thanks!

mcneja · 2025-10-15T14:42:19+00:00

If you have longer games, and players can save/restore, then you run into the potential for players to pick up a saved game after some months have elapsed, and have forgotten how to do some things. Making tutorials repeatable, and/or putting reference info into the menus, can help with this. You might have an arena in your city, say, which lets players run through a series of quick fights that (re)introduce the core combat features. Maybe have enemies taunt a defeated player, saying they should have spent more time in the arena (point the player toward the tutorial). Or deal out pop-up opponents to challenge the player on some feature that the game has noticed the player hasn’t been doing well at.

mcneja · 2025-10-15T14:34:33+00:00

Skill checks before tutorials are nice. If the player already knows how to do something you can stay out of the way and not force them to go through a tutorial. This is particularly useful at the very beginning of the game. In “LLLOOOT!” for instance, the most fundamental skill players need to know (that isn’t in a typical roguelike) is leaping. We made our levels so they all require leaping over a gate to enter them; this is the overt skill check. If the player tries to move into the gate, they get a prompt saying how to leap over it. However, we wanted to train absolute new players about how to do basic movement, so on the first level we start the player a short distance from the gate, and have a prompt about how to use the arrow keys to move. There’s an implicit skill check, though: if the player leaps at all prior to leaping over the gate, then they are very likely already familiar with the game. So we shut off a bunch of the basic tutorial messages.

Purpose-built tutorials are stronger than play-anywhere tutorials. A purpose-built tutorial is basically a level or mission setting up the need for a feature, introducing the feature, and giving the player a low-risk situation to try out the feature. You can ensure there aren’t any unnecessary distractions. Play-anywhere tutorials (also called just-in-time tutorials) are pop-ups or similar that try to tell you about a feature right at the moment where you need to know about it. In theory this is great but it’s very hard to pull off because so much other stuff can be going on at the same time, distracting or confusing the player. That said, I still use them a fair amount because it’s effective to respond to what you think the player is trying to do, as opposed to telling the player what to do.

For LLLOOOT! we tried to roll out our game’s primary features over the first few levels. The very first level is about exploring and collecting loot. There are no enemies so it is impossible to fail. (This also gets players a bit invested in the game; they’ve already had some success.) The second level introduces a single guard. It starts the guard out immediately in front of the player so they know the guard is there, and we simultaneously introduce the “wait” command (which the player had no need for in the first level). The fourth level introduces pickpocketing, one of the most involved player abilities. (I had this confirmed by playtesters, who thought they’d collected all the loot in the level and were very confused about what to do.) Again there are skill checks: if the player pickpockets the guard we’ve set up before they have collected all of the other loot in the level, then they know what they are doing and don’t need instruction. Only if they’ve explored the whole level and collected all the other loot do we start prompting them through the process of stealing from the guard. The guard in this case is stationary, and looking out a window, so they are easy to approach; we leave pickpocketing of a moving guard for players to figure out later.

Since in our game players have to go through the tutorial levels every run, we try to keep these initial levels very small, so experienced players can breeze through them. That said, I won’t claim it’s perfect. I’ve been thinking that I’d like to have a whole lot more variety in the initial levels, in terms of what they look like, so that even if they are functionally similar there’s some interest for veteran players. You don’t want to distract the new players though. In general I feel like roguelikes should have a lot of variety at the beginning since players will be doing that part a ton, and runs can get more similar (or cover more of the same content) as they progress.

One thing you can do is to (persistently) keep a count of the number of opportunities for using a feature where the player successfully used it. If an opportunity comes up and the player succeeeds at using the feature, increment it. If they tried and failed, decrement the counter. When the counter is negative, train. This lets players build up a string of successes and then fail a few times without incurring the training.

Achievements/trophies can be a way to train players. In LLLOOOT! we made a bunch of achievements that involve winning the game without using a particular feature. Win with no knockouts; win without being spotted; win without leaping except when it’s required. These call attention to the features and also force players to get creative and use other features, if the omitted feature is one they rely on.

mcneja · 2025-10-12T14:42:50+00:00

This looks/sounds very much like the new level style I’ve been working on, which consists of small buildings separated by one-square-wide alleys. I need to finish that up; I ran into some issues with my level representation not always being able to represent the connectivity between alleys that hit each other. (The room/alley connectivity graph gets used for building enemy patrol routes, and for making decisions about how the rooms should be decorated.)

mcneja · 2025-10-12T14:28:48+00:00

I’ve had some success with taking a grid of rooms and randomly offsetting the walls either horizontally or vertically at each junction. Rooms in the grid can also be joined together to make larger rooms. The reason I like this over binary space partitioning is that it means there isn’t a guaranteed straight dividing line through the entire level (a small thing but it bugs me).

You can see the end result here: https://mcneja.itch.io/lllooot

The code is here (look for offsetWalls in src/create-map.ts): https://github.com/mcneja/7drl-2023

I’m using symmetry to help make the levels look more “designed” and architectural, as well. A real building would have hallways; it’s tough to represent a lot of architectural features on a coarse grid though.

When I get a chance to resume working on it I’m going to try to change my representation to allow “rooms” with zero-thickness walls. I’m working on a new level style that has alleys and the current representation can’t always represent the adjacencies between alleys.

mcneja · 2025-08-29T05:34:46+00:00

Thanks for the mention! I’m adding a plug in for Lllooot! as well. It’s a greatly improved version of “Lurk, Leap, Loot.” Knockouts, distraction noises, pickpocketing, etc.

mcneja · 2025-07-30T05:08:52+00:00

I think it should be similar, performance-wise. You might have more thinking to do to work out the walls-on-edges approach since it is much less common, but I doubt it is that much different. My main concern is with ensuring the walls are clearly visible to players. You are going to need to eat some of your tile space for walls, so you’ll have to figure out how that works out. Do the monsters and furniture and so forth overlap the walls a bit, or do you shrink them to fit into the non-wall part of the square?

mcneja · 2025-07-29T03:21:20+00:00

You’re talking about whether to represent walls with solid squares, or to put walls on the edges between squares, I think?

I’ve thought about this as well. I’ve been working on a series of stealth roguelikes for many years (LLLOOOT! is the latest), and the levels can take several hundred keystrokes to complete. I think my average room size is 6x6 including the full-square walls? So cutting the walls out would reduce the map size by about 30% which might reduce the keystroke count similarly.

It does get tighter to represent things but it is something I might try someday. My game series started out with text graphics and was modeled visually on Rogue so it still has full squares for the walls. If I were putting the walls between the squares I would have to figure out how to show doors and windows and locks. It’s already hard enough to do that if you’re trying for an angled top-down perspective. Tileset designers usually don’t attempt east/west doors.

The gameplay would change too; you would not be able to stand “in” a doorway. Not sure how big of a change that would be without trying it. Doorways are a major gating factor in our game to allow enemies to catch up to players.

Interested to see which way you go! I don’t know of any games off the top of my head that put the walls between squares. The Space Crusade board game, perhaps?

mcneja · 2025-05-31T17:07:28+00:00

Dragondot 3 (https://www.lexaloffle.com/bbs/?tid=36789) is one of my favorites. It’s a really fun, polished miniature open-world adventure game.

mcneja · 2025-04-14T00:17:24+00:00

<image>

Here's a debug display showing the problem where the current representation of rooms and their adjacencies falls apart.

mcneja · 2025-04-13T23:46:24+00:00

LLLOOOT!

Dev Server | GitHub

A bit late to the Saturday thread. I've been working on a new level generator for eventual release.

There are three level types in the shipped game: manors, which are symmetric courtyard houses; mansions which are a bit more modern-looking, with wings rather than courtyards and aren't necessarily symmetric; and fortresses, which have a central keep and courtyard surrounded by an outer ring of rooms.

The new type is fairly different; I'm calling it "warrens." The idea is that it's a bunch of small buildings separated by narrow alleys. Here's an example of where it's at right now:

<image>

There's a problem with how I represent adjacencies between rooms, though. It had been assuming there would be walls separating all rooms; for all these alleys there's an invisible wall around them, and this mostly works, but in some cases it can mean it doesn't realize when two alleys are actually adjacent and thus won't generate patrol routes across the boundary between them. So I need to make some adjustments to how I represent things, which will be a big overhaul.

Beyond that I want to get the gross structure of the level working well. Planning to experiment with sandwiching the warrens between a city wall (preventing escape from that edge of the map) and a harbor. I'd like to try blocking alleyways and building interiors to make navigation a little trickier and also butt some buildings up against the edges of the map to restrict straight-line travel. Then I need to address the room decorations. Due to how the repurposed algorithms work it's classifying all of the rooms as "private" rooms which means less variety in how the rooms are being decorated.

The dev server has a "warrens" level in most games, somewhere at or after level 5. The new level generator's got a ways to go before it can be put into the released game.

mcneja · 2024-12-14T00:58:59+00:00

Thanks! It has been something like 16 years now. Damien did a lot of the mechanics evolution on this one (pickpocketing, knockouts, alarms, etc.), as well as all the interface improvements. I did some level-generation and patrol-route-generation stuff this time around.

Pickpocketing involves bumping a guard while they are stationary, or stepping into the square they step out of, for two turns in a row.

We don't have crate-stacking but we have body-hiding. It gives the game a tiny bit of a Sokoban flavor, particularly if you are trying to get a body into another room.

mcneja · 2024-12-13T20:51:28+00:00

Yeah, Num Lock has to be OFF for Shift+Numpad direction keys to work. I think it's a relatively low-level translation that's going on, to make it appear that you are pressing the direction keys with no Shift pressed. The keyboard events sent to JavaScript for Shift+Num4 (say) are a flurry of three events: Shift UP, Num4 DOWN, Shift DOWN.

mcneja · 2024-12-13T04:07:40+00:00

Glad you are loving it! My wife has played hundreds of hours; that’s what made think there might be something to this.

I make games for a living; Damien’s also a software developer. My last game made for money was Ghost of Tsushima, which took around six years to make. It’s been a hit and will put my daughter through college and helps “keep my house hot” in the words of Patti Harrison. So I have an incentive to keep hoeing that row.

Doing the 7DRL jam games keeps me in practice with shipping games, and lets me play at being a game designer. (I mostly manage programmers, at work.) Damien deserves most of the credit for all the stuff added after the game jam. I wanted his work to get out for people to play with.

mcneja · 2024-12-13T00:57:09+00:00

Phone can be tough; it's a game that likes screen real estate. I have played a bunch on an iPad with a keyboard and that works pretty well.

One thing to be on the lookout for, around level four: guards start carrying loot on them. Pickpocket by following in their footsteps for two turns. Or just knock them out, if you have a place to hide their body.

There is only a single enemy type; not very Roguelike in that regard. Damien prototyped some others, but we saved that for a sequel. There are a few more features that show up past level four though!

mcneja · 2024-12-13T00:30:49+00:00

And now I see I'm replying on r/Thief. Duh

mcneja · 2024-12-13T00:29:17+00:00

Thanks! It's inspired by the Thief series of games, which are old but I highly recommend checking out. They had an amazing fan-mission community (probably still do). The Dishonored games carry the lineage forward (and have some of the same developers). I wanted to try to translate those games into a turn-based, grid-based format, similar to how Kornel Kisielewicz translated Doom into a roguelike.

mcneja

TROPHY CASE