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?

Chris Koźmik

Silver Lemur Games
Developer
Joined
Nov 26, 2012
Messages
414
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.
It's the other way round. All thick wall (with possibly a few very unusual and extremely rare exceptions which I probably never encountered in a real life) can emulate thin wall. Note that thin wall can not emulate solid transparent objects in the middle of a tile (like wells).

Again, think "levers on the walls", those are almost impossible to implement (in a sane way anyway) if you use a thick wall system which can not emulate thin wall system. Basically, to implement levers (4 directions) you have to use thin walls subsystem in the thick wall system.

Of course if there was just walls, doors and floors (don't recall any such simplistic game) then indeed thick system could be made without implementing thin wall subsystem.
I honestly cannot make heads or tails of what you're saying. Just for your info, both EotB and Wiz7 (one thick, one thin wall) had no problems with levers and other objects in walls or objects in squares
It's hard to grasp it unless you actually implemented such system yourself. It's far from intuitive :)

What I'm trying to say is that thick wall system is not 1 thing per square but actually 1 thing + thin wall system per tile. So, thick wall system can always emulate thin wall and is always more sophisticated technically.
 

Chris Koźmik

Silver Lemur Games
Developer
Joined
Nov 26, 2012
Messages
414
It's the other way round. All thick wall (with possibly a few very unusual and extremely rare exceptions which I probably never encountered in a real life) can emulate thin wall.
Okay, how do you emulate a thinwall using a thickwall engine? You can't. A thickwall engine requires that a wall always take up a full square. Thus there is no way to emulate a thin wall where you can be on opposite sides of the wall in adjacent tiles. Doing the reverse just means you leave the filling space unused, as there is no requirement that all space be reachable.
"thickwall engine requires that a wall always take up a full square." Not exactly. I mean, it can be made as a soft rule but it's not what the thick system is about. For example a few posts above someone wrote that in the editor for Grimrock (which is a thick wall system game) you can make a thin wall map. So, basically, thick wall system does support thin wall system.

Note that thin wall can not emulate solid transparent objects in the middle of a tile (like wells).
Objects fall outside the scope of walls, but if the idea is emulating an impassable obstruction as a wall, you could just surround the tile in walls.
Won't work, you need a billboard rendered in the center of the tile, otherwise you would see two objects (front and one side), unless you face it exactly directly. Well, there might be some tricks and stuff to prevent it (like putting such object in the long corridor always surrounded from two sides by walls and make the object smaller and "floating" so you get the illusion of a proper perspective), but in practice it's just easier to implement a full blown thick wall system and use it mostly as thin wall system (with one exception where you use the thick wall feature to display such objects only).

Again, it's not very intuitive and hard to explain. Just wanted to say it's not how it looks like when you implement it. For you as a player it might look like thick wall is one square per grid object, but it can't be done like that. You need to always implement some sort of thin wall subsystem otherwise you won't be able to render any object except the very basic floor/wall/door combination (and yes, if you indeed make a game where all you have is floor/wall/door, you can make simple thick wall system where it's one object per grid cell, but such game would be so extremely primitive it makes no practical sense to attempt doing so).
 

CryptRat

Arcane
Developer
Joined
Sep 10, 2014
Messages
3,567
OK so given a double-sided wall system means you can paint each border of a tile, and each side differently, and thick walls means walls and wall related-object such as, typically, doors, fill in a one tile width, then a game can indeed use any combination of neither, one or both.

Depending on the game the positive impact of using thick walls might be limited. You can fight monsters under doors, and probably some related things, which means in real-time games it's good. It's also more convenient for the dev to draw the map, which is the only reason why I use thick walls. However the downside that with the same size map your dungeon is "smaller" is significant and most turn-based games have no reason to use thick walls.

A double-sided wall system obviously is strictly better than not, yet
you indeed make a game where all you have is floor/wall/door, you can make simple thick wall system where it's one object per grid cell, but such game would be so extremely primitive it makes no practical sense to attempt doing so
Be careful when you're mentioning primitive when talking about RPGs. The complexity available in Dragon Wars, a game with only text, and potentially an image (often it's only text), popping when you enter the corresponding tile is the kind I'm looking for. I prefer encounters and a different combat layer, once again popping when you enter a tile (or room), such as in Pools of Radiance and to a smaller extent, in Wizardry and early Might & Magic to the roamming monsters of Dungeon Master and later Might & Magic. I've always liked a good atmospheric text description (and image) popping when you enter a tile (or room) the same way a GM would provide it. Many deep games are supported by a simple tile system and things happening on a different layer when entering a relevant tile (or room).
 
Last edited:

Norfleet

Moderator
Joined
Jun 3, 2005
Messages
12,250
What I'm trying to say is that thick wall system is not 1 thing per square but actually 1 thing + thin wall system per tile. So, thick wall system can always emulate thin wall and is always more sophisticated technically.
That's just plain codswallop. A thinwall system allows you to produce any map where walls do not take up tile width, as well as maps where walls are at least one tile thick simply by walling off the tile and leaving it inaccessible. A thickwall system can ONLY produce this. It has NO ability to emulate two adjacent tiles separated by a wall that doesn't occupy a tile. You're clearly confusing the two concepts as the description you give is exactly the opposite of how it works.
 

Grauken

Gourd vibes only
Patron
Joined
Mar 22, 2013
Messages
12,803
Chris actually did build his own blobber, so he knows a bit of what he is talking about, though the thing is, even games that look similar from a player perspective, say Dungeon Master or Eye of the Beholder, may have entirely different ways how walls are implemented internally, there's no universal way to do it, so until we start to actually compare code, we only have anecdotal dev evidence (Chris, CryptRat and zz) on how they implemented walls
 

Krice

Arcane
Developer
Joined
May 29, 2010
Messages
1,333
I think thin wall is just a thick wall with walls at the edges of the tiles. But thick wall also has wall surface at the edge of the tile. Wait a minute...
 

Krice

Arcane
Developer
Joined
May 29, 2010
Messages
1,333
Does anyone know a simple and easy 3D engine you could use to create a crawler? I don't think 2D would be a smart solution, because it's just more work, but then again most 3D engines are way too huge and complex for old school crawler. I guess you could create a 3D engine...
 

Butter

Arcane
Patron
Joined
Oct 1, 2018
Messages
7,698
Does anyone know a simple and easy 3D engine you could use to create a crawler? I don't think 2D would be a smart solution, because it's just more work, but then again most 3D engines are way too huge and complex for old school crawler. I guess you could create a 3D engine...
Godot.
 

RobotSquirrel

Arcane
Developer
Joined
Aug 9, 2020
Messages
1,961
Location
Adelaide

This shows how to do the basics.

My approach though would be use a 2D tilemap for Collision detection and Map design, using a ray for this is a tad overkill because you can just predict the X,Y in front of the player to determine if they can move forward or not its much cheaper this way than a ray.
The cube approach is solid but it has a draw back in that you can't runtime load and save maps out of box, a 2DTilemap you can. This is why I recommend using a 2DTilemap and then interpreting that map using a loop with meshes representing each tile visually then that way you've got full control over your map saves, you can load it in and modify it at runtime (for random maps), and it should be pretty fast. I don't think you need his plugin if you know what you're doing on the asset side. Also with my approach you can do full PBS Textures if you wanted.

*sorry I think Gridmaps work the same way as 2D Tilemaps but with meshes, I'm thinking maybe that's the way to go, I've only used 2DTilemaps in Godot so far still getting the hang of the engine.
 
Last edited:

Butter

Arcane
Patron
Joined
Oct 1, 2018
Messages
7,698

This shows how to do the basics.

My approach though would be use a 2D tilemap for Collision detection and Map design, using a ray for this is a tad overkill because you can just predict the X,Y in front of the player to determine if they can move forward or not its much cheaper this way than a ray.
The cube approach is solid but it has a draw back in that you can't runtime load and save maps out of box, a 2DTilemap you can. This is why I recommend using a 2DTilemap and then interpreting that map using a loop with meshes representing each tile visually then that way you've got full control over your map saves, you can load it in and modify it at runtime (for random maps), and it should be pretty fast. I don't think you need his plugin if you know what you're doing on the asset side. Also with my approach you can do full PBS Textures if you wanted.

*sorry I think Gridmaps work the same way as 2D Tilemaps but with meshes, I'm thinking maybe that's the way to go, I've only used 2DTilemaps in Godot so far still getting the hang of the engine.

I think Gridmaps were removed in Godot 4 for some reason, so using 3.5/3.6 might be best for this.

edit: They might still be a thing in Godot 4. There was talk before its release of removing them, but they still show in the documentation: https://docs.godotengine.org/en/stable/classes/class_gridmap.html
 

Glop_dweller

Prophet
Joined
Sep 29, 2007
Messages
1,167
...I don't think 2D would be a smart solution, because it's just more work, but then again most 3D engines are way too huge and complex for old school crawler. I guess you could create a 3D engine...
Petri Häkkinen did just that for Legend of Grimrock 1 & 2.

http://www.grimrock.net/2012/03/30/legend-of-grimrock-build-001/




With the Built-in editor that they included with each game, anyone can make a functional map in minutes; and it's all shockingly customizable, and with full Lua 5.1 scripting support.

It is presently possible to add new level geometry and even new animated monsters for those interested in doing it.

*It's just not for making a commercial product. However... it's a fantastic tool to prototype a dungeon crawler with, if not just making mods for fun.
 
Last edited:

RobotSquirrel

Arcane
Developer
Joined
Aug 9, 2020
Messages
1,961
Location
Adelaide

edit: They might still be a thing in Godot 4. There was talk before its release of removing them, but they still show in the documentation: https://docs.godotengine.org/en/stable/classes/class_gridmap.html
In any case the method I suggested will work around that if they indeed removed it. Otherwise Gridmaps skip 1 step in the process which is loading the tilemap as a loop, with gridmaps you could just load the file directly and it should show up no problems.
 

Krice

Arcane
Developer
Joined
May 29, 2010
Messages
1,333
I tried to watch some Directx 12 tutorial videos. Jesus that stuff it boring. Maybe watch some more and try to set up a project. How hard could it be.
 

Krice

Arcane
Developer
Joined
May 29, 2010
Messages
1,333
Godot is way too big. If only there was a simple 3D library that had the basics in human readable source code, but we only seem to have huge engines like Godot and Unity, and then raw DirectX libraries. Which I guess is understandable, because you wouldn't just want to give away a great engine/library for free.
 

RobotSquirrel

Arcane
Developer
Joined
Aug 9, 2020
Messages
1,961
Location
Adelaide
Godot is way too big. If only there was a simple 3D library that had the basics in human readable source code, but we only seem to have huge engines like Godot and Unity, and then raw DirectX libraries. Which I guess is understandable, because you wouldn't just want to give away a great engine/library for free.
Here's the problem, if you start messing around with things like SDL or SFML you're essentially writing everything from scratch which is significantly harder to do plus you don't get an editor, you're having to build everything yourself which is harder.
I mean if it were easy everyone would be doing it. There's a reason why majority of indies don't make 3D games because its difficult to find reliable easy to use engines that have the performance you're looking for.
I've found that the more simplistic the engine though the harder time you're going to have, normally the simpler engines have performance bottlenecks and your ideas will exceed the simplicity of the engine. This is why Unity, Godot and Unreal became the gotos.
 

Hirato

Purse-Owner
Patron
Joined
Oct 16, 2010
Messages
3,959
Location
Australia
Codex 2012 Codex USB, 2014 Shadorwun: Hong Kong
The big difference between the two comes down to data structures, and what the designs allow.

A "thick-wall" type is the easiest to implement, if you've got a 32x32 map, then all you need is an array of 1024 bytes (so it's light on memory), and a bunch of different tile types.
It would be more accurate to call it a 'tile based' engine rather than a 'thick wall based engine' however.
Your tile types will then include a wall tile, a floor tile, stair tiles, door tiles, shortcut tiles, water tiles, lava tiles, trap tiles, warp tiles, etc.
If you then want to make combos, you will be required to explicitly define each of these as a new tile type.
And if 256 varieties is too few for you, then you can always expand that array to 2kb for 65536 varieties.


For what you call the 'thin-wall' type, each tile is no longer just a simple tile Id, but rather a full data structure.
Viata mentioned some of it on the first page.
You will instead need to store which sides have walls, which special effects are active (space requirements also go up if you want combinations), what kind of floor does it have, what's inside the tile, giving it some sort of unique tag (e.g. so you can disable the darkness effect in an area if someone found the light switch), etc.
It's significantly more constrained than doing it on a tile basis like above, but you also get to have far more direct control, and construct far more dense dungeons.
At minimum you're looking at 4x the memory compared to a tiled approach for the same map size.

While that might not seem like much, memory and disk size was at a premium when a lot of these games were originally made and developed.
 

negator2vc

Scholar
Joined
May 1, 2017
Messages
314
Location
Greece
Godot is way too big. If only there was a simple 3D library that had the basics in human readable source code, but we only seem to have huge engines like Godot and Unity, and then raw DirectX libraries. Which I guess is understandable, because you wouldn't just want to give away a great engine/library for free.
Godot is too big???????
Godot is extremely light as far as game engines goes + you also get an excellent editor that can really speed up game dev.
While even a solo dev can easily make a 2D engine, a 3D engine is quite more difficult to create.
 

Dr1f7

Scholar
Joined
Jan 25, 2022
Messages
1,037
what kind of fucking walls do you want then, jackass??
wanna tell me the exact number of centimeteres preferable for your fucking wall?
or better yet, why don't you make your own damn game with walls that are just thick enough BUT NOT TOO THICK nor too thin

who named you Lord Grauken , Arbiter of Walls
 

ind33d

Educated
Joined
Jun 23, 2020
Messages
986
The lack of destructible environments and walls in fantasy RPGs is quite disappointing. An XCOM-like cover system in a fantasy setting would be really cool. Casting fireball to destroy chest-high walls and remove someone's bonus to AC, etc.
 

Krice

Arcane
Developer
Joined
May 29, 2010
Messages
1,333
Godot is too big?
And I don't like that kind of editors, it feels so restricting in game development. So I tried to download and use Microsoft's own DirectX12 examples and after installing the game development thing in Visual Studio I still get an error message that the main library (directx..lib) is not a valid Win32 application. Good job Microsoft! The GDK version was even worse, it's just missing some headers I should have? Maybe those examples are for Windows 11 (I have Windows 10), who knows. I think there are directx examples in github written by other dudes, might still try one of those.
 

vlzvl

Arcane
Developer
Joined
Aug 7, 2017
Messages
195
Location
Athens
Does anyone know a simple and easy 3D engine you could use to create a crawler? I don't think 2D would be a smart solution, because it's just more work, but then again most 3D engines are way too huge and complex for old school crawler. I guess you could create a 3D engine...
There are plenty of "simpler" 3D game engines out there, merely containing an API or, if you like, they dont come with an kick ass editor thing which seems to be the standard these days. The majority of people involved today are messing up these two (2) things, forgetting or simply were not born back then when game engines were but an API.

Simpler on what level? Be single-header and single-library file? Have a simple API to follow? Not having a kissass stuffed UI and bazzilions of libs to satisfy everybody out there? Sure, just skip the #5 first choices of any "best engines 2023" google search out there. There are plenty of plenty of them. Trust only yourself, your research and what do you really want. As far as I know, there's no "dungeon crawler" engine out there but there's a bazzillion of crawler plugins on X top-5 stuffed-up engine. Your choice.
 

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