1
\$\begingroup\$

This question already has an answer here:

On a tile based strategy game I'm working on the player may select an area in which a room is placed. To do so the player selects the tiles. Either by clicking on each individual tile or dragging from one point to another. An algorithm kicks in and decides how and where the pre-made tiles should be placed. My concern is getting this algorithm working for more complex shapes than a single rectangle.

My first approach was to check whether or not the tiles around each selected tile is selected. Using this "signature" the algorithm chooses what tile matches that description and places it accordingly. With this setup I would need 7 models:

  • floor tile
  • tile with single wall & floor
  • tile with two walls (placed opposite of eachother) & floor
  • tile with three walls & floor
  • tile with four walls & floor
  • corner tile & floor
  • "cap" for inverted corners (as shown in blue below)

This seems like a viable option without too much work for the modellers. I have however had some problems recognising the tiles where an cap should be placed. And for situations as shown on the right-hand room would require a near endless combination of caps and walls.

A solution to discard the caps would be to make walls with a 45 degree cut on the end. This way there would be a lot more flexibility in placing the tiles and it would allow for special cases found in T-junctions. I believe the current pattern recognition algorithm would not suffice here. In order for it to work I think each tile had to check what kind of tile is around it, not only whether or not it's selected. I fear that this option would require too much computing power as the surrounding tiles may change recursively.

Now, the question is what option should I go for? One of the two proposed, or an third option? enter image description here

Any help, tip or solution is greatly appreciated.

\$\endgroup\$

marked as duplicate by Seth Battin, Community Jul 27 '15 at 9:03

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • \$\begingroup\$ About my close vote: the important part is the technique in the accepted answer. You essentially want your tiles to be selected based on the adjacent tiles' properties, a bit representing in-room or outside-room. So a bitset that maps to a set of tiles for each combination seems apt. \$\endgroup\$ – Seth Battin Jul 26 '15 at 14:31
  • \$\begingroup\$ The post confirms that my initial way of thinking was right, but fails to address the issue on having too many models. I think I'll make a script that takes a few basic tiles and pieces them together into all the combinations. \$\endgroup\$ – larsekje Jul 27 '15 at 9:03
  • \$\begingroup\$ I think the goal of fewer assets through clever design may be misguided. In the end, if you have a game with lots of variety that can be combined in lots of ways, that game will require a lot of assets. I can totally understand the intent, but it may not be achievable. Or at least, the asset count may not be minimizable further than you have already calculated. \$\endgroup\$ – Seth Battin Jul 27 '15 at 21:47

Browse other questions tagged or ask your own question.