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

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

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

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.

  • 2
    A.2: As A, only that just two sides - for example, North and West - can have a wall. That's the approach X-Com uses. – Martin Sojka Aug 3 '11 at 20:08
  • @Martin Sojka That leaves a hole at south-east corners. Still, it may be useful to consider model C in this fashion, each tile can have a combination of three different wall elements, noth, west and north-west corner. – aaaaaaaaaaaa Aug 3 '11 at 20:25
  • So the walls are visible, I take it? Not just blocking edges of tiles. Why do you need two halves in option B? Why not just a single wall, half-offset onto the other tile? – Richard Marskell - Drackir Aug 3 '11 at 20:36
  • @eBusiness, if you just allow walls in the north and west, you can simulate walls in the south and east by just putting walls in the north and west of the tiles below them. – Tetrad Aug 3 '11 at 21:20
  • I'd suggest going with C. It's what I'm doing in this and it works pretty well. The only problem is the very south/east edge of the map. You'll have to do something about that. – Blecki Aug 4 '11 at 0:42
up vote 13 down vote accepted

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'.]

  • 1
    This is an answer, and I believe it's a 100 (?) reputation level to comment. Welcome to the Gamedev SE! :) – The Communist Duck Aug 4 '11 at 9:08

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.

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.


Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.