After spending time today to jot down some notes regarding the implementation of walls into my tile-based game, I've suddenly realized it's not going to be as simple as I imagined before. While the current stage of my work is not even close to actually making the wall-related code, I've come up with three different ways to do it. Right now I'm unsure which one of my ideas will work best, and whether I missed something or not.

Important: a character CAN stand on a tile that has walls, regardless of their form.

The common thing for all the three variants: the tilemap will be "kept" in an single-dimension std::vector (or similar) based container. The reasons for that are (awesomely) explained in answers to a different question.

Container classes in tile-based games.

Back to walls.

A) The simple approach.

Nothing fancy here. Each tile-container can hold not only characters, but one or several Wall objects, which are attached to the edge inside the tile.

![First approach] (https://i.sstatic.net/IA1H6.jpg)

Pros: easy to implement, nothing to change in the engine. Cons: Two things. One - it might be just in my head, but some combinations just look ugly. Second - this approach allows to make a double-wall from two adjacent tiles. Building will be an important part of the game, and double-walls allow the builders to possibly forego upgrading the material of the walls through game means, and just achieve increased durability with doubling the existing wall. That's not desirable. Sure, I could include a procedure that forbids double-walling, but it will have a bad feel to it.

B)The smart(?) approach.

Instead of letting the players double-wall the whole map, I'm going to beat them to it. Every wall has two halves that are attached to the edge of the tile from inside. So, to make a single "Wall unit" I'll have to create two Half-Wall objects in two adjacent tiles.

![Second approach] (https://i.sstatic.net/YUVh9.jpg)

Pros: It's symmetrical!!! Also, no significant change of current engine specs is needed. Cons: More hassle, more objects, and, of course, the "caps". As you can see in the picture, a corner will basically cry for a "cap" object. I'm actually cool with it, it's not so hard to add. Hey, I already have a plan for thin columns made out of four connected caps. Sweet. Still, I have some worries regarding possible Field of View and Line of Sight issues.

C) The total overhaul variant.

Or, I could just create borders and corners as separate containers for game objects. Just like that.

![Third approach] (https://i.sstatic.net/gQsW6.jpg)

Pros: Not even sure. Well, it's straightforward. Definitely. Cons: It will require an overhaul. Not of code, thankfully, but of the current game mechanic mentality - that's for sure. The benefits are not so obvious. Also, this aprroach requires much more containers than the two previous ones. The indexing math will also be a bit of pain.

So here we have it - three distinct ways of making walls between tiles. If there are any alternatives out there - I'll be happy to check them out. If there are any benefits/downfalls to any of the approaches that I didn't see - please point them out.

After spending time today to jot down some notes regarding the implementation of walls into my tile-based game, I've suddenly realized it's not going to be as simple as I imagined before. While the current stage of my work is not even close to actually making the wall-related code, I've come up with three different ways to do it. Right now I'm unsure which one of my ideas will work best, and whether I missed something or not.

Important: a character CAN stand on a tile that has walls, regardless of their form.

The common thing for all the three variants: the tilemap will be "kept" in an single-dimension std::vector (or similar) based container. The reasons for that are (awesomely) explained in answers to a different question.

Container classes in tile-based games.

Back to walls.

A) The simple approach.

Nothing fancy here. Each tile-container can hold not only characters, but one or several Wall objects, which are attached to the edge inside the tile.

![First approach] (https://i.sstatic.net/IA1H6.jpg)

Pros: easy to implement, nothing to change in the engine. Cons: Two things. One - it might be just in my head, but some combinations just look ugly. Second - this approach allows to make a double-wall from two adjacent tiles. Building will be an important part of the game, and double-walls allow the builders to possibly forego upgrading the material of the walls through game means, and just achieve increased durability with doubling the existing wall. That's not desirable. Sure, I could include a procedure that forbids double-walling, but it will have a bad feel to it.

B)The smart(?) approach.

Instead of letting the players double-wall the whole map, I'm going to beat them to it. Every wall has two halves that are attached to the edge of the tile from inside. So, to make a single "Wall unit" I'll have to create two Half-Wall objects in two adjacent tiles.

![Second approach] (https://i.sstatic.net/YUVh9.jpg)

Pros: It's symmetrical!!! Also, no significant change of current engine specs is needed. Cons: More hassle, more objects, and, of course, the "caps". As you can see in the picture, a corner will basically cry for a "cap" object. I'm actually cool with it, it's not so hard to add. Hey, I already have a plan for thin columns made out of four connected caps. Sweet. Still, I have some worries regarding possible Field of View and Line of Sight issues.

C) The total overhaul variant.

Or, I could just create borders and corners as separate containers for game objects. Just like that.

![Third approach] (https://i.sstatic.net/gQsW6.jpg)

Pros: Not even sure. Well, it's straightforward. Definitely. Cons: It will require an overhaul. Not of code, thankfully, but of the current game mechanic mentality - that's for sure. The benefits are not so obvious. Also, this aprroach requires much more containers than the two previous ones. The indexing math will also be a bit of pain.

So here we have it - three distinct ways of making walls between tiles. If there are any alternatives out there - I'll be happy to check them out. If there are any benefits/downfalls to any of the approaches that I didn't see - please point them out.