Making walls in tile-based games: what am I missing?

Question

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.

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.

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.

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.

Answer 1

I'd use your method 'B'.

To avoid needing 'caps', just extend each wall "1/2 wall thickness" in both directions. This will create overlapping walls where they meet, but your diagrams already suggests this is not a problem.

So, in Method 'B', Pic #3, the horizontal wall would extend to the left a bit, and the vertical wall would extend up a bit.

[I'm new here, just registered. Am I missing something, as I can't see an 'Add Comment' button to your original post. Is that a privilege of people with higher reputations? Or am I overlooking the obvious? Sorry for adding this as an 'answer'.]

Answer 2

You noted that a character can stand on a tile containing a wall but have you considered treating each tile as wall itself? Even half a tile as a wall in a horizontal or Vertical fashion?

Pros: Calculations and placements are trivial, collision is trivial where all calculations and collisions are just based on the coordinates of the walls placement.

Cons: It could impact your entire implementation, code and graphics. You don't want to totally abandon your method either, you still want special cases where only part of a tile is wall (Link to the Past with cliffs).

This is how I would I have based my implementation, going forward, knowing that I can always reference a tile and perform a calculation on it depending on my characters location and what kind of tile it is.

A castle wall I could just perform a calculation from the center drawing a box that I could not pass through or if its a round rock I could do the same calculation from the center but as a circle so my character can move around in like it was rounded.

Answer 3

Sorry to say but the third way is really the way to think, well, you already have the ability to do that so lets move on and think about the other two!

The thing is that a wall is a zero width, two dimentional (height*length, in a 3D world) square partitioning two Boxes. You should consider them as such but you might use a simpler solution as when to build your dungeon (especially if other people might build parts).

It seems it is a Top-Down 2D game where walls have "a width" so they need that corner (your 'cap' object). This is exclusively 'graphics' though so I'd go with some sort of:

A 2D map with the tiles (ie. type of tile and such).

A 2D map with 2 walls, ex. bottom and right (the left wall will be the 'right wall' in the tile left from this one).

+ a Logic that draws all the walls and 'caps' etc.

Thus separating logic and graphics. You might do an "interface" taking care of things like SetWall(ThisTile, LEFT, NOWALL) -> setting the right wall of the tile left of ThisTile to "NOWALL"...

Maybe this seems blurry but the thing is that you should always try to have at one side the logic (the actual data, without redundancy) and on the other side the 'drawing of the data' which calculates if there is need for a 'cap' etc.

++