Putting the 'role' back in role-playing games since 2002.
Donate to Codex
Good Old Games
  • Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.

    "This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.

Why have dungeon crawlers either thin or thick walls?

zwanzig_zwoelf

Graverobber Foundation
Developer
Joined
Nov 21, 2015
Messages
3,106
Location
デゼニランド
From an AI perspective thick is easier to implement A* as automatically its designed to work with such mazes. Thin walls are harder because they require custom rules for each tile, you have to tell the AI what it can and cannot walk through its not as simple as setting the adjacent tiles to 255 in weight like it is with thick walls. So that may also be a reason for why thick is chosen over thin.
It's not too difficult to do. You can run a simple check for each node whenever you create a graph and tell each node about its relationship with adjacent nodes (e.g. full connection, one-way connection, or no connection).
 

Arbaces

Novice
Joined
Sep 11, 2021
Messages
42
From an AI perspective thick is easier to implement A* as automatically its designed to work with such mazes. Thin walls are harder because they require custom rules for each tile, you have to tell the AI what it can and cannot walk through its not as simple as setting the adjacent tiles to 255 in weight like it is with thick walls. So that may also be a reason for why thick is chosen over thin.
What? I wouldn't say A* is designed for such mazes as much as it is the most common example. If anything, thin walls would be slightly simpler to program for since their representation is already more graph-like, effectively being a short adjacency list. Impassable walls shouldn't be nodes in the graph you're running A* on at all. Your approach would have AI prefer to try to walk through the wall than take a route larger than your magic number to a destination on the immediate other side.
 
Last edited:

The Avatar

Pseudodragon Studios
Developer
Joined
Jan 15, 2016
Messages
336
Location
The United States of America
I don't think A* was really used in games back then. Thin walls also are not really a problem for a* - you just have to do a little extra work to support it.

The thick walled approach is the simplest and can also take up the least amount of memory, because in theory you only need to store a single bit to determine if a cell is accessible or not. For a thin-walled system, you would need to store whether each neighbor is accessible or not, for each cell. A little more complicated, but not rocket science. The programmers probably just did whatever came to mind at the time.
 

Glop_dweller

Prophet
Joined
Sep 29, 2007
Messages
1,167
Legend of Grimrock uses the thin-wall approach, but has solid walls as well; primarily on the outer edge of levels. There are Lua function calls for detecting solid walls in scripts. It's nothing to do with the gameplay, but it does allow real 3D insets on the walls, that do not appear on the other side. Stairs as well, can descend or ascend through the interior spaces between the walls.

Thin walls do not allow for (or at least highly restrict use of) —physical— stairs in a dungeon. Bard's Tale and the Gold Box titles do not have these; [of course, Eye of the Beholder doesn't either].

If you tried something like that in Bard's Tale (2d or 3d), it would have to look something like these:
btr-stairs.jpg


stairs_down.gif


Or otherwise need to be wholly abstracted like this:
btr-stairs1.jpg


A real/physical stairwell (3d or 2d) would (or should) show from the back.
Though this particular issue mainly affects converting maps from 2d to 3d, as they had to do for the remastered Bards Tale games.... not that they actually did any of this; these are simply illustrative examples.

conceptual-stair-asset.gif


_______________________________
_______________________________
But as to why have them thin.... the answer is obvious, I'd think. ;)
With fixed perspective, the walls don't need to have depth to depict the map, and that leaves every cell as a traversable path; memory was tight, and solid walls reduce the explorable area of the (already tiny) maps. Also the maps wrapped around. Walk far enough South, and you would be in the top Northern cell; some maps exploited this. The level four map in Eye of the Beholder allows/uses this—the rest of its maps do not.

The thick walled approach is the simplest and can also take up the least amount of memory, because in theory you only need to store a single bit to determine if a cell is accessible or not.
But if they are all of them accessible, then they don't even need to store the bits.

For a thin-walled system, you would need to store whether each neighbor is accessible or not, for each cell...
FRUA (&BT iirc) do store whether wall tiles are passable; all tiles are passable from the rear; which is why there needs to be wall tiles on both sides of a wall... the walls are invisible from the rear.
 
Last edited:

RobotSquirrel

Arcane
Developer
Joined
Aug 9, 2020
Messages
1,960
Location
Adelaide
The thick walled approach is the simplest and can also take up the least amount of memory, because in theory you only need to store a single bit to determine if a cell is accessible or not. For a thin-walled system, you would need to store whether each neighbor is accessible or not, for each cell. A little more complicated, but not rocket science.
this is pretty much along the lines of what I was trying to say. Thick is basically on/off, Thin is you then have to tell each cell what walls are on and what are off.
The 255 number is what ever the max weight is for off, it wasn't supposed to be a magic number its what ever the max is that you think you need, some people may put different ground textures in that change the speed in which you move so they would be weighed differently for the AI so that it knew those paths might not be optimal but may not have a choice if suddenly a door was closed. If this were a dos game it'd more likely be a 0 or 1 since CPU and Memory was more sparingly used, for thin walls however would be 0,1,2,3,4,5 etc depending on what number associated to what tile was meant to be displayed, then the AI would have to have rules for each tile type.
 

Chris Koźmik

Silver Lemur Games
Developer
Joined
Nov 26, 2012
Messages
414
You are all wrong (always wanted to write this one day :D). Well, kind of, more like there is a widespread misconception that "thick" equals "one thing per grid cell". It's much more complex in practice. It's a bit difficult to explain (and not very intuitive), the trick to understand "thick" system is to stop thinking about walls and doors (since those are trivial cases) and start thinking about levers (like imagine a single grid cell pillar in the middle of a dungeon with a level on one side, then imagine it has levers on two sides and a button on another and nothing on the fourth side).

Let's start with an example, here is "thick" walls data structure (per grid cell) in Legends of Amberland:

Code:
struct SMapEdge
{
	short wall;
	short wall2;
	char passable; // for monsters only, party requires a better check
	short event; short eventparam1,eventparam2;
} edge[4];
int ceil,mid,floor;
short ceil2,mid2,floor2;
char passable; // for monsters only, party requires a better check
short event; short eventparam1,eventparam2;
int creature[3];
char climate;
char region;

And those interesting quotes:

In M&M3-5 there are "thin" edge walls the party can break through. Doors are similarly placed on the edges between cells.

Legend of Grimrock uses the thin-wall approach, but has solid walls as well; primarily on the outer edge of levels.

Notice how some "thick" wall games actually allow/partially use "thin" walls as well?

Theory
There are 3 basic systems:

1) Solid - one thing (like wall or door) is in one grid cell, a trivial system. Roguelikes use it.
2) Edges (AKA "thin" walls) - things are stored on a per edge basis. Gold Box series and Wizardry use it.
3) Solid+Edges (AKA "thick" walls) - the game looks as a simple solid grid based but also has separate edges on each direction of the solid grid cell. Dungeon Master and basically all dungeon crawlers use it.

The misconception is that most people think that games which have "thick" walls use system 1), while those use system 3). They have to, otherwise implementation of levers would be nearly impossible (or at least not feasible).

Therefore, "thick" walls system always INCLUDE "thin" walls system within itself.
Therefore, "thick" walls always use more memory per grid cell (since it has to have everything "thin" walls has + extras), amplified by the bigger spacing of the map itself.
Therefore, "thick" walls system is more complex to code.
That's why, early games used "thin" walls system (lower memory needs, easier to code) and later games advanced to a more sophisticated "thick" walls system.

Why later RPGs switched from "thin" to "thick" walls system
I think for two reasons. One is that the map is MUCH more clear for the player and more aesthetically appealing, it basically looks better. Second reason might be related to map editing which is probably easier for "thick" walls (since you paint Solid elements most of the time and deal with Edge elements rarely). Plus of course it allows crushing enemies by doors in Dungeon Master style. So, overall it's a superior system.
Of course the key reason was probably the memory requirements, later games could simply afford the extra data structure size and the code size to handle it.
 

Grauken

Gourd vibes only
Patron
Joined
Mar 22, 2013
Messages
12,803
Why later RPGs switched from "thin" to "thick" walls system
This isn't true, most RPGs in the Wizardry-tradition still only use thin walls, most real-time dungeon crawlers use either 1) or 3) and very few TB-crawlers use 1) or 3)

One is that the map is MUCH more clear for the player and more aesthetically appealing, it basically looks better.

Wrong

So, overall it's a superior system.

Wrong, thin-wall dungeon crawlers have usually much more complex and interesting dungeons than any thick-wall based ones, so thin-walls are superior


Oh yeah, the reason real-time crawlers switched to thick walls is that they have a lot more active wall-shifting puzzles that just can't be done with thin walls. And real-time crawlers need space to maneuver in combat, which isn't relevant in TB ones, hence thin-wall dungeons end up as more compact but not very good for real-time combat.
 
Last edited:
Joined
Jan 21, 2023
Messages
3,147
The title of the thread gave me an idea: are there any Dungeon Crawls with actual wall breaking mechanics?
Not a DC in the traditional sense, but the first Elder Scrolls game had a wall breaking spell that was extremely useful. However that was abandoned as the next games included stuff like verticality in their dungeon design.
 

V17

Educated
Joined
Feb 24, 2022
Messages
267
Regarding the technical implementation of grid-based maps, some Czech dungeon crawler, I think it was Gates of Skeldal, used a graph instead of a grid as the basic data structure for maps, where each walkable square had a link to its neighbors. This is important because while the maps were still on square grids, it allowed them to make essentially 4D maps, where some sections seemingly overlapped or wrapped around on themselves. This was used for teleports, rotator traps etc., and honestly I have no idea if the game was any better because of it. However it means that thick or thin walls cease to make sense - you can do both, create secret rooms inside thick walls or even in spaces where they logically could not fit.

Seems like a smart system and I always wondered how many other games used something like that internally.
 

Norfleet

Moderator
Joined
Jun 3, 2005
Messages
12,250
Wrong, thin-wall dungeon crawlers have usually much more complex and interesting dungeons than any thick-wall based ones, so thin-walls are superior
Well, of course thin-wall is superior, because it's simply a superset of all possible dungeon layouts with thick or thin walls. Any thick-wall dungeon can be reproduced 100% inside a thinwall setup, simply by not using the thinnity.

I will, however, point out that thickwall tends to be more REALISTIC, because thin walls in real life tend to lack sufficient strength to actually hold up the entire dungeon when you hollow it out so much and not have the entire thing cave in on your head, and where are you going to put all your plumbing and wiring?
 

Rincewind

Magister
Patron
Joined
Feb 8, 2020
Messages
2,467
Location
down under
Codex+ Now Streaming!
I made a similar observation and called them "tunnel-style", "wall-style", and "hybrid-style" maps in the Gridmonger manual.

KyTuYFo.png


1jB58mt.png


oP8afXv.png


And finally, there is the game Obitus that features a unique movement system that also allows 45-degree movement.
Gridmonger doesn't have support for it yet; I'll add it when I get to playing the game.

9FukgB8.png
 

Lord of Riva

Arcane
Patron
Joined
Jan 16, 2018
Messages
2,806
Strap Yourselves In Pathfinder: Wrath
And finally, there is the game Obitus that features a unique movement system that also allows 45-degree movement.
Gridmonger doesn't have support for it yet; I'll add it when I get to playing the game.

Nice, another wierd old game for the list, appreciated.


:updatedmytxt:
 

Rincewind

Magister
Patron
Joined
Feb 8, 2020
Messages
2,467
Location
down under
Codex+ Now Streaming!
I have to admit though what has occupied my thoughts (given we are in the codex workshop area) is what is the best way to store a map with thin walls from a data structure perspective?
I'm storing a matrix of cell structures in Gridmonger. A cell has various attributes, such as the floor type (e.g. blank, teleport, spinner, pit) and a north and a west wall. Walls can be of type "no wall", or they can be solid walls, doors, statues, switches, etc. Of course, that restricts it a bit so you can only have one "thing" on a wall (e.g. can't have both a switch and a fountain, for example). But because it would be hard to display multiple things in a grid view anyway, this is not a problem.

Then I have one extra padding column and row (to store the south and east walls of the last "real" column & row).

This data structure was chosen because it's efficient, and it can represent both tunnel and wall-style maps, and of course hybrids too.
 
Last edited:

Norfleet

Moderator
Joined
Jun 3, 2005
Messages
12,250
I made a similar observation and called them "tunnel-style", "wall-style", and "hybrid-style" maps in the Gridmonger manual.
There's really no "hybrid" involved. Your "hybrid" example is simply "thin" "wall-style" that doesn't use every available square as passable space, because "thinwall" is, as I said, a strict superset of both.
 

Rincewind

Magister
Patron
Joined
Feb 8, 2020
Messages
2,467
Location
down under
Codex+ Now Streaming!
I made a similar observation and called them "tunnel-style", "wall-style", and "hybrid-style" maps in the Gridmonger manual.
There's really no "hybrid" involved. Your "hybrid" example is simply "thin" "wall-style" that doesn't use every available square as passable space, because "thinwall" is, as I said, a strict superset of both.
I think otherwise. In the wall-style map there are no "tunnels", in other words unfilled cells. For example, 100% of the map cells in the Gold Box games are filled, and the dungeon is formed solely by the walls.

In the "hybrid" style there's a generous amount of blank, unfilled cells, *and* there are walls as well. The hybrid style is kind of unique because of this, and quite rare—very few games have this kind of dungeon design.

To me, the difference between the three styles is very clear, and I'm surprised you don't see it just by looking at the above three images:

- Tunnel style, it's obvious. Zero "thin walls".
- Wall style, almost the whole map has filled cells, therefore it's almost all white. Because of this, the dungeon must be formed by "thin walls"... otherwise you'd just get a huge empty 16x16 room or something!
- Hybrid, like the tunnel style, the map is "not all white", and there is a generous amount of internal walls *in addition* to tunnel style pathways and rooms.

Try to look at them again with this mindset and you'll see it.

My point: "wall-style" maps *always* use 100% of the available space! Water also counts; it's not blank! Check out the PoR and M&M1 maps which are clear examples of the "wall-style":

mm1-regions.png



por-regions.png
 
Last edited:

mondblut

Arcane
Joined
Aug 10, 2005
Messages
22,240
Location
Ingrija
I think otherwise. In the wall-style map there are no "tunnels", in other words unfilled cells. For example, 100% of the map cells in the Gold Box games are filled, and the dungeon is formed solely by the walls.

Absolutely not. Using blocks or walls is a question of technology. How to utilize the level space, is entirely up to the designer and has nothing to do with technology.

What kind of layout is this?

h1ktKhK.jpg


But what about this?

yMmEqoM.png


What happened? Is one quarter of the map "wall-style", and the rest "hybrid"? Come on, it's a bullshit distinction.
 

Rincewind

Magister
Patron
Joined
Feb 8, 2020
Messages
2,467
Location
down under
Codex+ Now Streaming!
I think otherwise. In the wall-style map there are no "tunnels", in other words unfilled cells. For example, 100% of the map cells in the Gold Box games are filled, and the dungeon is formed solely by the walls.

Absolutely not. Using blocks or walls is a question of technology. How to utilize the level space, is entirely up to the designer and has nothing to do with technology.

What kind of layout is this?

h1ktKhK.jpg


But what about this?

yMmEqoM.png


What happened? Is one quarter of the map "wall-style", and the rest "hybrid"? Come on, it's a bullshit distinction.
First is wall style (predominantly).

Second is hybrid style.

Easy! I recognise it when I see it :)
 

Rincewind

Magister
Patron
Joined
Feb 8, 2020
Messages
2,467
Location
down under
Codex+ Now Streaming!
Btw, why it matters from the perspective of my program is that you simply need to use different tools for creating tunnel style maps (90% the "draw tunnel tool" would suffice), and again different ones for the wall style stuff (first clear an area, which is first wall-less, then use the "draw wall tool" to draw in the walls).

Eye of the Beholder you can map only with the draw tunnel tool, for instance. So you're right in the sense that there might be maps or games where one level is this style, another that style, etc. Ultimately, whether you call them hybrid or whatever doesn't matter -- I was just trying to explain to the user how to draw different dungeon styles. For this reason the categorisation is useful, then I care much less about 100% putting a definitive label onto every single game. I like the term "hybrid", but that's me.
 

mondblut

Arcane
Joined
Aug 10, 2005
Messages
22,240
Location
Ingrija
Btw, why it matters from the perspective of my program is that you simply need to use different tools for creating tunnel style maps (90% the "draw tunnel tool" would suffice), and again different ones for the wall style stuff (first clear an area, which is first wall-less, then use the "draw wall tool" to draw in the walls).

Eye of the Beholder you can map only with the draw tunnel tool, for instance. So you're right in the sense that there might be maps or games where one level is this style, another that style, etc. Ultimately, whether you call them hybrid or whatever doesn't matter -- I was just trying to explain to the user how to draw different dungeon styles. For this reason the categorisation is useful, then I care much less about 100% putting a definitive label onto every single game. I like the term "hybrid", but that's me.

Well, we're talking about game tech, not mapping utilities. Regardless, in what you call "hybrid" you never know when a "tunnel" suddenly turns upon itself and becomes a wall maze. Nor you know when a "maze" level designer gets lazy and leaves half of the cells unused.
 

Rincewind

Magister
Patron
Joined
Feb 8, 2020
Messages
2,467
Location
down under
Codex+ Now Streaming!
Btw, why it matters from the perspective of my program is that you simply need to use different tools for creating tunnel style maps (90% the "draw tunnel tool" would suffice), and again different ones for the wall style stuff (first clear an area, which is first wall-less, then use the "draw wall tool" to draw in the walls).

Eye of the Beholder you can map only with the draw tunnel tool, for instance. So you're right in the sense that there might be maps or games where one level is this style, another that style, etc. Ultimately, whether you call them hybrid or whatever doesn't matter -- I was just trying to explain to the user how to draw different dungeon styles. For this reason the categorisation is useful, then I care much less about 100% putting a definitive label onto every single game. I like the term "hybrid", but that's me.

Well, we're talking about game tech, not mapping utilities. Regardless, in what you call "hybrid" you never know when a "tunnel" suddenly turns upon itself and becomes a wall maze. Nor you know when a "maze" level designer gets lazy and leaves half of the cells unused.
Game tech and mapping utilities are kinda the same thing :) E.g. if a map editor exists for a given RPG, then you have your answer (do they store only edges, tiles, or the flexible system that I use that can represent everything). But OK, I get your point. All categorisations serve a purpose; of course if an engine (e.g. my tool) can represent what I call "hybrid", it can represent everything.
 

Norfleet

Moderator
Joined
Jun 3, 2005
Messages
12,250
If your engine can represent "wall style", it can represent everything, because like I said: Thinwall is the superset of all of these. All thickwall maps are just thinwall maps with spaces unused. If your engine supports thinwall maps, it supports thickwall maps with zero modifications of anything: All you do is build the map with the space unused. Presumably you can then trip the player up by hiding mechanisms and secrets in there. Alternatively, if you give the player the opportunity to breach walls, breaching a faux-thickwall-map results in putting a hole through the wall and hitting a sewage line, resulting in the player being showered in shit, or a power line, resulting in electrocution.
 

Lord of Riva

Arcane
Patron
Joined
Jan 16, 2018
Messages
2,806
Strap Yourselves In Pathfinder: Wrath
If your engine can represent "wall style", it can represent everything, because like I said: Thinwall is the superset of all of these. All thickwall maps are just thinwall maps with spaces unused. If your engine supports thinwall maps, it supports thickwall maps with zero modifications of anything: All you do is build the map with the space unused. Presumably you can then trip the player up by hiding mechanisms and secrets in there. Alternatively, if you give the player the opportunity to breach walls, breaching a faux-thickwall-map results in putting a hole through the wall and hitting a sewage line, resulting in the player being showered in shit, or a power line, resulting in electrocution.

While that is logically true, it kinda depends on how the program is made. Just because logical two (to four) thin walls make a "full" wall does not mean that you have teached the software or engine to be able to place them like this or work around empty spaces for that matter. I agree naturally that it's unlikely to not think about that, but it is also a hen and egg question. Most likely thick walls came first, to fill a grid instead of parts of it.
 

Norfleet

Moderator
Joined
Jun 3, 2005
Messages
12,250
Just because logical two (to four) thin walls make a "full" wall does not mean that you have teached the software or engine to be able to place them like this or work around empty spaces for that matter.
That assumes that the game itself is placing them. Most maps are hand-designed rather than procgen, so if the map designer simply does not render an area accessible, the engine doesn't have to do anything special to "support" it. The player simply cannot go there. And most games will not be entirely made of 100% space-filling maps in either case.

I agree naturally that it's unlikely to not think about that, but it is also a hen and egg question. Most likely thick walls came first, to fill a grid instead of parts of it.
Well, obviously, it takes only a single bit to represent a tile in a thickwall grid and fewer computations, but at least two to represent a tile in a thinwall grid, and if you're strapped for memory space and compute, that's the way to do it.
 

As an Amazon Associate, rpgcodex.net earns from qualifying purchases.
Back
Top Bottom