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?

Grauken

Gourd vibes only
Patron
Joined
Mar 22, 2013
Messages
12,787
Here's an odd question. Have you ever wondered why some dungeon crawlers have thick walls (basically a wall or a door takes up a whole square on the grid) whereupon others have only thin walls or doors (basically taking up only the edge of a square)? Is there a reason for that beyond just aesthetics?

Most games with thin walls are games in the tradition of Wizardry while most games with thick walls are in the tradition of Dungeon Master. So is it a question of tb (or phase-based to be more specific) combat versus real-time combat? Yes and No.

Wizardry games have a specific metric I call S2E (squares to exit) though you can basically generalize it to S2O (squares to objective, whatever your objective is). Every time you step on a new square in these games there's a chance you enter combat, lose HP and other resources. Wizardry games, at least the early ones, are all about managing your limited resources until you can get back to the city. So in theory you should step on as few squares between the city and whatever your objective is as possible.

If you have levels with thin walls it leads to a very compact design with a S2E/S2O metric markedly lower than if you have levels with thick designs. For example, Level 1 of Wizardry has an S2E of 29, Level 2 of 63. Once you have access to the elevator, your calculation for each level changes again.

XuCG6Rzb.png
1LFz931b.png


The 2nd level of Dungeon Master has an S2E of 259 (if I didn't discount).

dzzkxH4b.png


Now some thick-walled games have smaller levels and would have smaller S2Es and some games with thin walls can have massive levels with probably equally massive S2Es, but the overall point is easy to see. If you have thin walls, your overall level design is far more compact and in general can lead to shorter paths, which is advantageous if you play a Wizardry-like where each step on each square carries the risk of losing limited resources.

I think it's something most developers stumble upon intuitively. An interesting case study is how the level design changes between Might and Magic 2 and 3, from thin to thick-walled.

oLVGXqnb.png
KTwp3Nkb.png


While M&M 3-5 aren't real-time, they also don't really have random battles (let's forget about respawns) and the ranged battle phase takes advantage of the level design with maneuvering almost similar to real-time crawlers, something you don't see in Wizardry-likes. And once you cleared an area you don't have to worry about enemies again.

Another interesting case is Mordor and Demise, who are both real-time but have thin walls.

7gvWQDjb.png


But they are unique in that enemies are contained to each room, they are somewhat randomized and each room functions similar to squares in Wizardry-likes, meaning you have the same resource management you face in Wizardry-likes where you have to optimize your gains going from the city to level exits.

Though, all that said, this isn't an iron-clad rule. Shining in the Darkness follows mostly the Wizardry gameplay (random battles, tb combat on one square) but still has thick walls.

vBpPVt1b.png


And then there oddities like zz's Geisterschiff that has partly random tb combat that takes advantage of the level design and is mostly ranged-based. Thick walls, but doors are mostly thin if I remember correctly.
 

Ysaye

Arbiter
Joined
May 27, 2018
Messages
771
Location
Australia
Interesting. I totally agree with the whole compactness part that suits with the random battles upon entering a new cell in Wizardry and I think I like it better from a design perspective. Having said that Phantasy Star (the original game) had Wizardry encounters but with thick walls - in fact maybe that was a very Sega thing to do?

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? One thought is that you have it defined in an array but where movement happens in increments of two, meaning that the information on the "odd" cells contains information on walls, doors and the like. I suppose another way is to have each cell define it's own walls. How do other people deal with it - are there better ways? How was it dealt with in the original Wizardry?
 
Self-Ejected

Thac0

Time Mage
Patron
Joined
Apr 30, 2020
Messages
3,292
Location
Arborea
I'm very into cock and ball torture
I have never thought about the difference, but I think it has something to do with secret doors aswell.

In a thin wall layout there can also be thick walls. You don't know wether the tile behind the wall is hollow or thick until you check.
AHRk8ys.png

As you can see, in this Wiz 1 snippet there might aswell just be secret doors into the grey wall partitions.
With thick walls you can rule out a lot of places for secret doors, so other possible places become more obvious.
aFMsnhm.png


On the other hand it becomes very hard to hide secret rooms in a layout like this, unless you resort to thin edge secret doors again.
 

Morblot

Aberrant Member | Star Trek V Apologist
Patron
Joined
Aug 30, 2014
Messages
2,288
Location
Finland
PC RPG Website of the Year, 2015 Codex 2016 - The Age of Grimoire Make the Codex Great Again! Grab the Codex by the pussy Insert Title Here RPG Wokedex Strap Yourselves In Codex Year of the Donut
Are there any games with thick walls but thin doors? Eye of the Beholder perhaps? (Never played it.)
 

Dorateen

Arcane
Joined
Aug 30, 2012
Messages
4,332
Location
The Crystal Mist Mountains
The Gold Box games had thin wall design. In the FRUA toolset, builders would select wall placement, but then you can further modify either side, making it solid or passable. In this way creating false, illusionary or one-way walls or secret doors. I prefer thin walls, but I think in some tile-based mapping tools, the only option is to place a wall tile on a square, creating the thick wall effect. It is still possible to make those walls have no collusion, allowing a player to pass through. Just like you could draw four thin walls around a cell to get that same blocky design.

Very interesting topic, from both a player and builder perspective.
 

Morpheus Kitami

Liturgist
Joined
May 14, 2020
Messages
2,476
I always assumed it was just because the developers programmed it so something takes up a tile, or something takes up a wall. In Dungeon Master, its clones and early FPS titles, the game works off the tile system. From an editing perspective, especially one where you don't have a fancy modern editor, its easier to program in, this tile contains this, that tile contains that. A tile can usually only contain one thing. I suspect doing a line-based system is harder. I have never actually confirmed that though, so I'm just assuming.
 

Viata

Arcane
Joined
Nov 11, 2014
Messages
9,885
Location
Water Play Catarinense
what is the best way to store a map with thin walls from a data structure perspective
Wizardry Legacy(fan game) had an interesting idea:
Maze Data Structure
Filed in: Development.DVmazedata · Modified on : March 17, 2018, at 01:43 AM - Visits 1692

The data structure of the maze in wizardry is pretty ingenious. The structure currently used will probably be changed in later version of the programm to be able to handle more features. Surprisingly, my engine is has much more stronger capabilities than the NES and SNES ports.

Thin Walls
Wizardry use a map system that allow to create thin walls. It took me a lot of time to know how to program these kind of walls. The first thing people are thinking about is to use a grid in indicate which square is solid or not, but that does not allow to have thin walls. The way to do it is to keep the information about the surrounding wall within the square.

So each square of the grid will record which sides are walled if the player was located in the middle of the square. This has the advantage of creating thin walls, but also have the disadvantage of creating 1 sided wall bugs. Still, Wizardry made it a feature rather than a bug.

Illustration_ThinWalls.png

The 1 sided wall or door bug is created if 2 adjacent square does not hold the same information about wall positions. For example, the left square could say that there is a wall to the right, but the right square could say that there is no wall to the left, allowing a player to move from right to left, but not other wise

Mazetile Structure
This is a proposed structure for the new maze system in order to support more features and possibilities in how to display the maze. The main changes is that the maze can support up to 16 different texture palettes which should been sections or areas of the maze. Each palette would have a shorter set of masked texture for example that would require less bits in the tile to be able to reference them.

1st Byte : Solid
7-6 5-4 3-2 1-0
North East South West
The first byte is divided in 4 sections of 2 bits. Each section represent one of the 4 walls. With 2 bits, there are 4 possible values

Wall encoding

Bits Meaning
0-0 Nothing
0-1 Wall
1-0 Grid
1-1 Door
2nd Byte : Event
Used to keep track of special events in the maze. Contains the key of the event. If more than 256 events are required for the whole adventure, I could make it palette or floor specific giving me 256*16 or 256*20 events. Or I could use less bits and use the extra bits for other event purposes.

3rd Byte : Special
This will work almost as the original except the size will be different. There would now be 4 bits for the filling, where darkness is actually a filling.

7 6 5 4 3-0
Undefined Light Solid Magic Bounce Room Filling
The room filling goes as follow. New filling could be added or

Room Filling table

Value Meaning
0 Nothing
1 Water
2 Fizzle Field
3 Fog
4 Poison Gas
9 Darkness
4th Byte: Floor and Ceiling Objects
Each tile can now have a different Floor, Ceiling and Wall object. Each texture palette can hold up to 16 different object pictures for floors, Ceiling and floor objects requiring only the use of 4 bits to reference them.

7-4 3-0
Floor Object Ceiling Object
5th Byte: Palette ID and Wall objects
The palette ID is used to identify which one of the 32 texture palette is going to be used. Wall objects are all thin objects like torches and chains that can be drawn above the wall from any direction and still look good (because objects are always facing the player).

7-5 4-0
Wall Objects Palette ID
6th Byte: Object Positions
Objects can be placed in various positions on the ceiling and the walls, this byte is used to keep track of these positions. Individual Objects can have 9 different position arranged as a 3x3 grid.

7-6 5-4 3-0
Wall Object Ceiling Object Floor Objects
Wall Object placement

Value Placement
0 None
1 Center
2 Pair top of wall
3 Pair center of wall (or bottom)
Ceiling Object placement

Value Placement
0 None
1 Center
2 4 corners
3 4 sides
Floor Object placement

Value Placement
0 None
1 Center
2 North
3 East
4 South
5 West
6 Pair on north
7 Pair on east
8 Pair on south
9 Pair on west
10 4 corners
11 4 sides
12 Square
13 Undefined
14 Undefined
15 Undefined
7th Byte: Masked Texture for Floors/Ceiling and Walls
Masked texture are special textures added over the regular wall texture to identify certain areas as different from the others (for example stairs down). Each palette has a selection of 16 textures for walls and for floor/ceiling that the player can use.

7-4 3-0
Floor/Ceiling Texture ID Wall Texture ID
8th Byte: Grid Texture, Masked Floor/Ceiling and Wall texture position
The first 2 bits are used to reference the grid textures. Each palette can have up to 4 different grid and these 2 bits are used to select the right grid to display. The other bits are flags that determine where the masked texture selected in the previous byte is going to be displayed.

7-6 5-4 3-0
Grid Texture ID Floor/Ceiling Wall
Floor/Ceiling texture placement

Bits Placement
0-0 None
0-1 Floor
1-0 Ceiling
1-1 Both
Wall texture placement

Bit Placement
0 North
1 East
2 South
3 West
Other Maze information
The structures above are not the only place where information about the maze are stored. There are data structure for each floor, the new structure will contain data for the texture palette and the database contains a list of events that can be triggered inside the maze.

The importance of having a compact tile structure is because it gets repeated thousands of time. It is important to be able to fit the most information possible in the least amount of space. This is why each bit must be used to it maximum capacity.

File Size
The maze size can be estimated the following way:

Width (100) x Length (100) x Depth (20 levels) x Tile Size (8 byte ) = 1600000 bytes.

1600000 / 1024 = 1562.5 K / 1024 = 1.52 Meg

This means that each adventure will have a minimum size of 1.5 Meg. Then you add the pictures, the database and the text to get the final adventure size.
http://wl.lariennalibrary.com/index.php?n=Development.DVmazedata
 

Arbaces

Novice
Joined
Sep 11, 2021
Messages
42
Thin walls let you fit more dungeon in the same grid size. It's an insightful point that Wizardry (thin) versus Dungeon Master (thick) lineage determines the style of walls. Wasted tiles would add tedium to wizardry style mapping puzzles with spinners and teleporters. Despite Grimrock's support for thin walls, see the slime room and hidden doors, its levels are generally spaced thickly showing its dungeon master lineage. It's more intuitive to write a tile editor for thick walls, and it's quicker to block out levels in a painting fashion.
 

mondblut

Arcane
Joined
Aug 10, 2005
Messages
22,205
Location
Ingrija
The title of the thread gave me an idea: are there any Dungeon Crawls with actual wall breaking mechanics?

Are there any games with thick walls but thin doors? Eye of the Beholder perhaps? (Never played it.)

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

Arena has thick walls in the dungeons, and you have a spell that can remove blocks.

Thick wall maps are way more readable, but have much less content per dimensions, ofc.
 

mondblut

Arcane
Joined
Aug 10, 2005
Messages
22,205
Location
Ingrija
If you have levels with thin walls it leads to a very compact design with a S2E/S2O metric markedly lower than if you have levels with thick designs. For example, Level 1 of Wizardry has an S2E of 29, Level 2 of 63. Once you have access to the elevator, your calculation for each level changes again.

XuCG6Rzb.png
1LFz931b.png


The 2nd level of Dungeon Master has an S2E of 259 (if I didn't discount).

dzzkxH4b.png

A Wizardry level is 16x16 20x20, a DM level appears to be 32x32. Put 4 3 Wizardry levels side by side, and the difference in S2E will be quite less drastic.

But the real reason has nothing to do with the thickness of walls. Dungeon Master is game where you walk in one direction, and there is every reason to make the one true way as complex and winding as possible, utilizing the entirety of the level in your way from the entrance to the exit. By contrast, Wizardry is a game of constantly running back and forth, and it absolutely demands shortcuts to quickly go from level 1 to level 4 or whatever, therefore the vast majority of every level is essentially optional and isolated from navigational progress.
 
Last edited:

Grauken

Gourd vibes only
Patron
Joined
Mar 22, 2013
Messages
12,787
But the real reason has nothing to do with thickness of walls. Dungeon Master is game where you walk in one direction, and there is every reason to make the one true way as complex and winding as possible, utilizing the entirety of the level in your way from the entrance to the exit. Wizardry is a game of constantly running back and forth, and it absolutely demands shortcuts to quickly go from level 1 to level 4, therefore the vast majority of every level is essentially optional and isolated from navigational progress.

That's essentially my point
 

mondblut

Arcane
Joined
Aug 10, 2005
Messages
22,205
Location
Ingrija
But the real reason has nothing to do with thickness of walls. Dungeon Master is game where you walk in one direction, and there is every reason to make the one true way as complex and winding as possible, utilizing the entirety of the level in your way from the entrance to the exit. Wizardry is a game of constantly running back and forth, and it absolutely demands shortcuts to quickly go from level 1 to level 4, therefore the vast majority of every level is essentially optional and isolated from navigational progress.

That's essentially my point

I thought your point is that Dungeon Master has notably larger S2E because you have to walk around solid blocks, whereas my point is that DM needs no shortcuts and isolated optional areas by its very design (no backtracking to the city).

Anyway, I am no coder, but I suspect that wall-based dungeons take less memory space than block-based dungeons, hence their prevalence in earlier games for calculator-tier computers.
 

Grauken

Gourd vibes only
Patron
Joined
Mar 22, 2013
Messages
12,787
But the real reason has nothing to do with thickness of walls. Dungeon Master is game where you walk in one direction, and there is every reason to make the one true way as complex and winding as possible, utilizing the entirety of the level in your way from the entrance to the exit. Wizardry is a game of constantly running back and forth, and it absolutely demands shortcuts to quickly go from level 1 to level 4, therefore the vast majority of every level is essentially optional and isolated from navigational progress.

That's essentially my point

I thought your point is that Dungeon Master has notably larger S2E because you have to walk around solid blocks, whereas my point is that DM needs no shortcuts and isolated optional areas by its very design (no backtracking to the city).

Anyway, I am no coder, but I suspect that wall-based dungeons take less memory space than block-based dungeons, hence their prevalence in earlier games for calculator-tier computers.

Dungeon Master has a larger S2E because it has solid blocks, but the reason it has solid blocks is that it doesn't need optimized paths like Wizardry-type games need. So I don't think we disagree. I think thick or thin walls are partly historical and partly organic design. If you don't care about optimized paths then you can put in solid blocks like many real-time crawlers do, if you do care about optimized paths because you somewhat follow a Wizardry mold, you most likely stick with thin walls.

Though since I'm not a coder I imagine there might be other reasons why either thin or thick walls are preferable I haven't thought of
 

Alex

Arcane
Joined
Jun 14, 2007
Messages
8,750
Location
São Paulo - Brasil
But the real reason has nothing to do with thickness of walls. Dungeon Master is game where you walk in one direction, and there is every reason to make the one true way as complex and winding as possible, utilizing the entirety of the level in your way from the entrance to the exit. Wizardry is a game of constantly running back and forth, and it absolutely demands shortcuts to quickly go from level 1 to level 4, therefore the vast majority of every level is essentially optional and isolated from navigational progress.

That's essentially my point

I thought your point is that Dungeon Master has notably larger S2E because you have to walk around solid blocks, whereas my point is that DM needs no shortcuts and isolated optional areas by its very design (no backtracking to the city).

Anyway, I am no coder, but I suspect that wall-based dungeons take less memory space than block-based dungeons, hence their prevalence in earlier games for calculator-tier computers.

I think it is the other way around. With a blocky wall design, you can represent the whole level on a single matrix of the same size as the dungeon. If you have thin walls, though, you need some way to represent each wall as well. This can be done in a variety* of ways; but they will always end up costing more memory than a simple blocky design.

*I think the simplest way is to store the dungeon in a matrix with both dimensions doubled and added 1. This way you can set all odd coordinates to refer to tiles while even coordinates refer to walls (assuming the array starts at 0). Another way is to store the the walls of a block as an array of flags inside a char. This way, you could have the least significant byte be whether there is a wall south, then right, left and north (or whichever order you prefer). This also allows you to create weird dungeon designs since neighbouring cells need not to match their walls.
 
Last edited:

mondblut

Arcane
Joined
Aug 10, 2005
Messages
22,205
Location
Ingrija
I think it is the other way around. With a blocky wall design, you can represent the whole level on a single matrix of the same size as the dungeon. If you have thin walls, though, you need some way to represent each wall as well. This can be done in a variety* of ways; but they will always end up costing more memory than a simple blocky design.

Possibly, but in the end the most space-consuming measurement is the sheer map size, and block design requires far larger dimensions to fit the same amount of content as does wall design. When the memory expanded, walls got bitmap graphics, additional overlays and sheeit, there was no more reason to conserve every bit, and newer games went after block design which is more readable for players and easier to work with for creators.
 

Alex

Arcane
Joined
Jun 14, 2007
Messages
8,750
Location
São Paulo - Brasil
I think it is the other way around. With a blocky wall design, you can represent the whole level on a single matrix of the same size as the dungeon. If you have thin walls, though, you need some way to represent each wall as well. This can be done in a variety* of ways; but they will always end up costing more memory than a simple blocky design.

Possibly, but in the end the most space-consuming measurement is the sheer map size, and block design requires far larger dimensions to fit the same amount of content as does wall design. When the memory expanded, walls got bitmap graphics, additional overlays and sheeit, there was no more reason to conserve every bit, and newer games went after block design which is more readable for players and easier to work with for creators.

Oh, I get you now.

I suppose it is possibly the issue; thought I suppose it might have been the mapping culture of the time as well? At any rate, I think thin walls are much better for a variety of designs, such as cells and whatnot.
 
Last edited:

zwanzig_zwoelf

Graverobber Foundation
Developer
Joined
Nov 21, 2015
Messages
3,086
Location
デゼニランド
Thin walls would require more memory per tile (the lowest possible number I can come up with is 2 bits to denote the north/west wall and use bits of other tiles create a block), while block-based dungeons can be simplified to a simple array of bits.

Which means to store a simple 20x20 level you'd need 50 bytes, but you'd need 100 bytes to store the same level with thin walls. Of course, the size can balloon if you start adding additional properties.

In modern games, I think it depends on the type and the developer. In case of Dungeon Master-style crawlers, assuming a developer decides to use Unity and use a plugin to handle pathfinding for him, most solutions I know tend to treat nodes as blocks and disregard space between them, making thin walls impossible without delving into the source and changing the way it's done. Wizardry-style crawlers, on the other hand, don't need pathfinding (unless you want to add auto-walking), so you can do whatever you want.

In case you're interested to see an example how dungeon data is stored, check out Xeen map format: https://xeen.fandom.com/wiki/MAZExxxx.DAT_File_Format
 

Norfleet

Moderator
Joined
Jun 3, 2005
Messages
12,250
Those are actually thin walls, they're just visually rendered thicker. The tileset simply includes different connection points to enable it to connect to the next tile while preserving the thickened wall appearance. If you were to map this by hand, you'd be able to do it using thinwall graph paper.
 

Grauken

Gourd vibes only
Patron
Joined
Mar 22, 2013
Messages
12,787
Those are actually thin walls, they're just visually rendered thicker. The tileset simply includes different connection points to enable it to connect to the next tile while preserving the thickened wall appearance. If you were to map this by hand, you'd be able to do it using thinwall graph paper.

Maybe you're talking about something different, though this is the internal representation of walls on a coordinate system inside the games memory. Shining in the darkness uses blocks for walls, not thin walls.
 

zwanzig_zwoelf

Graverobber Foundation
Developer
Joined
Nov 21, 2015
Messages
3,086
Location
デゼニランド
Those are actually thin walls, they're just visually rendered thicker. The tileset simply includes different connection points to enable it to connect to the next tile while preserving the thickened wall appearance. If you were to map this by hand, you'd be able to do it using thinwall graph paper.

Maybe you're talking about something different, though this is the internal representation of walls on a coordinate system inside the games memory. Shining in the darkness uses blocks for walls, not thin walls.
It looks like he mistook form for function.
 

RobotSquirrel

Arcane
Developer
Joined
Aug 9, 2020
Messages
1,947
Location
Adelaide
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.
 

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