Language agnostic 建议在基于瓷砖的系统上处理自由形式移动的逻辑

我没有这方面的经验，所以我怀疑我的逻辑过于复杂，或者可能不够完整，无法完成我想做的事情

我有一个基本的基于瓷砖的系统，但我想以圆锥形的方式在地形上移动单位。现在他们正在从一个地砖“传送”到另一个地砖

我已经在tile系统上设置了很多游戏逻辑，比如路径查找、覆盖、地形类型等

我的第一个猜测是，它有一个浮点x/y偏移量，从单元的中心到平铺的中心，0.0在中心，1.0在边上。这将是一个单位重叠的每个瓷砖。然后我可以做数学运算，找出单元“最”在哪个磁贴上，并使用该磁贴进行路径查找逻辑

为了使它更美观，当装置移动时，我会让它调整ofset，这样它会逐渐用瓷砖线定位自己，而不是做一系列90*的旋转来击中路径上的瓷砖。然后，我可以做一些花哨的事情，让他优雅地转弯

对于像wepon距离这样的东西，我可以使用x/y平铺距离，然后细分出x/y偏移，得到一个简单的pathagorean距离

---

怎样才能成功地将移动与磁贴分离，并且仍然能够将单元“链接”到磁贴

您还可以指定具有特定整数大小的磁贴。假设每个瓷砖是100x100。这样你就可以使用整数而不是浮点数。查找您/玩家所在的磁贴同样很简单，仍然是基于整数的。

最简单的方法是使用浮点坐标，然后四舍五入到最接近的整数以获得平方

(3.141592, 2.718282) -> (3, 3)

要获得正方形内的像素位置，只需将坐标的分数部分乘以平铺大小，然后四舍五入到最接近的整数：（假设为100x100平铺）

---

为什么不让玩家移动到地砖上呢？ 当他们想从磁贴A移动到磁贴B时，开始沿磁贴的方向移动播放器。当他们在一个合理的距离内从瓷砖的中心，你可以切换瓷砖的球员是在游戏逻辑方面

所以

---

玩家开始从磁贴A移动到磁贴B。如果对磁贴A造成伤害，大多数（如果不是所有的话）依赖于磁贴的游戏逻辑（如影响范围武器伤害）仍然会影响玩家。当玩家到达磁贴A和磁贴B中心的中间时，将玩家的实际平铺位置切换到平铺B。

您的问题不清楚，但我将使用的方法不同，这取决于您的游戏是2D还是3D

对于2D游戏来说，最好使用像素作为坐标。这样你就可以使用整数来存储它们，让事情变得简单明了。通过将单元的坐标除以平铺大小，可以很容易地确定单元所在的平铺

对于使用平铺的3D游戏，只需使用浮动作为坐标系。如果你这么想武器射程的话，让单位保持“平铺”状态可能是最容易的

无论你使用什么系统，帮你自己一个忙，把从位置到磁贴编号的转换放在代码中的one位置。如果你到处乱扔/100和*100仅仅因为你现在的瓷砖大小是100，它最终会回来咬你。仅仅用一个称为TILE_SIZE的常量替换“100”可能也不是最好的方法，因为完全有可能在将来的某个地方，您会希望为两个坐标系使用不同的原点

---

一旦你的单位可以在一块瓷砖内移动，你的寻路问题就会变得更加复杂。即使你所有的单位都是相同的大小，当相邻的瓷砖无法通行时，你可能需要确保它们不会太靠近边缘。我建议您将所有路径保留在平铺空间中，并对路径进行后期处理，以平滑所有不必要的45度转弯。

这样考虑会使装置看起来局部具有高平铺分辨率，但在全球范围内，它有一个较小的单元。因此，在像素14,72处，它将是瓦片3,2？其想法是将较大的瓦片与较小的单元运动分离。。。我可以这样做，通过为单位移动设置一个较小的平铺，在较小的平铺之间实现它。谢谢你的想法。你会有一层更大的瓷砖，在每个瓷砖中会有一层更小的瓷砖，这样玩家可以在瓷砖中移动更平稳？您可以很容易地将相同的概念应用于此。您是在使用某种路径查找算法，还是只是在dir中。关于瓷砖？我有一个定制的a*实现，它考虑了瓷砖的未来状态。。。这样，单位将“移动”其他单位（按照移动命令的顺序），谢谢你的好建议。到目前为止，我对代码进行了很好的封装，我正在为将来的扩展做计划，我一直在考虑这类事情。至于pahtfinding，我的一些Unit占用了多个Tile，所以我已经有一些代码来决定一条路径是否真的可以通过。。。我相信我可以稍微调整一下，看看这个单元如何穿过瓦片的可能变化。我已经有一些后期处理了。知道它是基于回合的，还是实时的可能会有帮助。

(3.141592, 2.718282) -> (0.141592, 0.718282) -> (14, 72)