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
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'.]
No comments:
Post a Comment