在花了一些时间写下有关在我的基于图块的游戏中实现墙壁的一些注释之后，我突然意识到它不会像我以前想象的那样简单。虽然我的工作的当前阶段甚至还不能真正完成与墙相关的代码，但我已经提出了三种不同的方法。现在，我不确定哪一个想法最有效，以及我是否错过了什么。
重要提示：一个字符CAN站在那个有墙，无论其形式的区块。
所有这三个变体的共同点是：瓦片映射将被“保留”在基于一维std :: vector（或类似形式）的容器中。对此的原因（非常）在回答另一个问题时得到了解释。
回到墙壁。
A）简单的方法。
这里没什么好看的。每个图块容器不仅可以容纳角色，而且还可以容纳一个或多个贴在图块内部边缘的Wall对象。
优点：易于实现，引擎没有任何变化。缺点：两件事。一个-可能只是在我脑海中，但有些组合看起来很丑。第二-这种方法可以用两个相邻的瓷砖制作双层墙。建筑物将是游戏的重要组成部分，而双层墙允许建造者放弃通过游戏方式升级墙的材料，而只是通过将现有墙加倍来提高耐用性。那是不可取的。当然，我可以包括一个禁止双壁的程序，但是会对它造成不良影响。
B）聪明（？）方法。
我不会让玩家把整个地图都塞满，而是要击败他们。每堵墙都有两半，从内侧连接到瓷砖的边缘。因此，要制作一个“墙单元”，我必须在两个相邻的图块中创建两个“半墙”对象。
优点：它是对称的！同样，不需要对当前发动机规格进行重大更改。缺点：比较麻烦，对象更多，当然还有“帽子”。如您在图片中看到的，拐角基本上会为“盖帽”对象哭泣。我真的很酷，添加起来并不难。嘿，我已经有一个计划，计划由四个连接的盖子制成的细柱。甜。不过，我仍然对可能的视野和视线问题感到担忧。
C）总检修款。
或者，我可以将边框和角创建为游戏对象的单独容器。就这样
优点：甚至不确定。好吧，这很简单。绝对是 缺点：需要大修。幸运的是，这不是代码，而是当前的游戏机制心态-可以肯定。好处不是那么明显。此外，该aprroach需要多少比前两者更容器。索引数学也会有些痛苦。
因此，在这里我们有了它-在瓷砖之间制作墙的三种不同方法。如果有其他选择-我们将很乐意将其检查出来。如果我没有看到的任何方法都有任何优点/缺点，请指出。