代码之家 › 专栏 › 技术社区 › Ape-inago

建议在基于图块的系统中处理自由移动的逻辑

language-agnostic

2

Ape-inago · 技术社区 · 16 年前

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

我有一个基本的基于瓦片的系统,但想以连续的方式在地形上移动单位。现在,它们正在从一个瓷砖“传送”到另一个瓷砖。

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

我的第一个猜测是,它有一个浮点x/y偏移,偏离单元的中心和图块的中心,0.0在中心,1.0在边缘。这将是一个单元重叠的每个图块。然后,我可以计算出该单元在哪个图块上“最多”,并将该图块用于路径查找逻辑。

为了让它更漂亮,当单元移动时,我会让它调整ofset,这样他就会逐渐用瓷砖线定位自己,而不是做一堆90*的转弯来击中路径上的瓷砖。然后,我可以做一些花哨的事情,让他在拐角处优雅地弯曲。

对于wepon距离之类的东西,我可以使用x/y平铺距离,然后减去x/y偏移量,得到一个简单的pathagoreas距离。

有什么方法可以成功地将运动与瓷砖分离,同时仍然能够将单元“链接”到瓷砖?

4 回复 | 直到 16 年前

1

3

Joe Ludwig 16 年前

从你的问题中还不清楚,但我会使用的方法会根据你的游戏是2D还是3D而有所不同。

对于2D游戏,最好使用像素作为坐标。这样你就可以使用整数来存储它们,让事情变得简单明了。通过将坐标除以图块大小,您可以很容易地找出一个单位所在的图块。

对于使用方块的3D游戏,只需使用浮点数作为坐标系。如果你这样看待武器靶场之类的事情,那么将单位放在“瓷砖”里可能是最容易的。

无论你使用什么系统,帮自己一个忙,把从位置到瓷砖编号的转换放进去 一个人 放在你的代码中。如果你仅仅因为你目前的瓷砖尺寸是100,就到处乱扔/100和*100,它最终会回来咬你。仅仅用一个名为TILE_SIZE的常数替换“100”可能也不是最好的方法,因为在未来的某个地方,你完全有可能希望为两个坐标系使用不同的原点。

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

2

1

Zekaric Zekaric 16 年前

您还可以指定一个具有特定整数大小的图块。假设每个图块是100x100。所以你坚持使用整数而不是浮点数。找到你/玩家所在的瓷砖同样微不足道,而且仍然是基于整数的。

3

1

Markus Jarderot 16 年前

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

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

要获得正方形内的像素位置,您只需将坐标的分数部分与图块大小相乘,并四舍五入到最接近的整数:(假设100x100个图块)

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

4

0

Dalin Seivewright 16 年前

为什么不让玩家移动到瓷砖上呢? 当他们想从图块A移动到图块B时,开始向图块的方向移动玩家。当它们与互动程序的中心相距合理距离时,就游戏逻辑而言,您可以切换玩家所在的互动程序。

所以。。。

玩家开始从图块A移动到图块B。如果对图块A造成伤害,则大多数(如果不是全部)与图块相关的游戏逻辑(如效果区域武器伤害)仍将影响玩家。当玩家到达图块A和图块B中心之间的一半时,将玩家的实际图块位置切换到图块B。