寻路 2d java 游戏进一步问题
我前段时间问了一个关于java 2d寻路的问题...... 探路 2D Java 游戏？
我正在开发的游戏是基于主题医院的理念。 从我的问题中选择的答案，A* 寻路，链接非常棒，而且非常有帮助。 我最终将其应用到我的游戏中，但是我还有一些与之相关的进一步问题/问题。
在我的游戏中，地图会改变。 本教程假设地图是静态的（我认为）。 我一直在查看代码，据我所知，我只需要创建一个方法来调用以在寻路代码中更新游戏地图。
其次，我看到 GameMap 类。 我有自己的类，称为 Board，其中包含所有瓷砖。 我相信我可以将 GameMap 上的方法集成到我的 Board 类中。 正确的？
第三，我一直在研究任何房间都将被视为被封锁的推理。 我的意思是，房间覆盖的任何方块都被视为被阻挡。 我正在提前考虑人们将从哪里进入房间。 然后他们将不得不在这些房间内移动以到达不同的地方。 我想我只是反转每个方块的 Blocked 布尔值，但这不起作用，原因有两个。 1，房间可能有相邻的墙壁，并且可能会扰乱寻路。 2、如果只是将阻塞状态倒置，那么房间内的任何固体物品在倒置回来时都会被视为非固体，这在接触墙壁时可能会出现问题。
想想看，如果你能把一个正方形的边挡住，而不是真正的整个正方形，那就更好了。 这一定是可能的，但我只是通过使用上一个问题中的教程，不确定是否应该尝试更改 A* 来执行此操作，或者研究房间项目问题的解决方法。
对这些问题有什么想法或建议吗？ 我今天正在实现简单的路径查找，但只是超前思考。
I asked a question some time ago on java 2d pathfinding...
Pathfinding 2D Java game?
The game im developing is based on the idea of theme hospital.
The chosen answer from my question, A* pathfinding, the link was awesome, and very helpful.
I'm eventually getting to implement this into my game, however I have some further questions/issues regarding it.
In my game, the map will change. The tutorial assumes that the map is static (I think). I have been looking at the code, and as far as I can work out, I just need to create a method to call to update the game map in the pathfinding code.
Second, I see the class GameMap. I have my own class called Board which houses all the tiles. I believe I could integrate the methods on GameMap into my Board class. Right?
Third, I have been working on the reasoning that any rooms would be counted as blocked. I mean as in, any squares the room is covering are counted as blocked. I was thinking ahead to where the people will enter the rooms. They will then have to move around these rooms to get to various places. I was thinking I would just invert the Blocked boolean for each square, but this would not work for 2 reasons. 1, rooms could have ajoining walls, and potentially muck up pathfinding. 2, if the blocked status is simply inverted, then any solid items in the room would be seen as not solid when inverted back, which could cause problems when they are touching a wall.
Thinking about it, it would be better if you could make sides of a square blocked rather than actual whole squares. This must be possible, but I am just getting by using the tutorial in the previous question, and not sure if I should try and change A* to do this, or work on workarounds for the room items issue.
Any thoughts or suggestions on any of these issues?
I'm implementing the simple path finding today, but just thinking ahead of myself.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
快速浏览一下， isValidLocation(mover,sx,sy,xp,yp) 方法定义了从点（sx,sy）移动到点（xp,yp）是否是有效的移动。
如果此方法考虑到移动的方向，您可以阻止特定方向进出某个方块，而不会使该方块完全无法穿透。 这样，您就可以拥有两个相邻的可访问块，并且它们之间有坚实的边界。
这种方法有一些有趣的副作用，例如创建单向边界的能力（方块 A 可以访问方块 B，但反之亦然。）可能是一种有用的游戏机制，可以让 A* 采取单向门（火）逃逸？）考虑在内。
有一种称为 Adaptive A* 的算法，它可以重新计算路径的一部分，例如，如果有人站在您面前。 我首先会专注于普通的 A*，如果您发现之前的有效路径被阻止，您总是可以从该点开始计算一条新路径。
这看起来很有趣：Real-Time Adaptive A* [PDF]
From a quick look, it looks like the isValidLocation(mover,sx,sy,xp,yp) method defines if moving from point(sx,sy) to point(xp,yp) is a valid move.
If this method took into consideration the direction of the move, you could block specific directions out of / into a block without making the block entirely impenetrable. This way, you could have 2 accessible blocks next to each other with a solid boundary between them.
This approach has some interesting side-effects such as the ability to create one-way boundaries (block A has access to block B, but not vice versa.) Could be a useful game mechanic in letting the A* take one way doors (fire escapes?) into account.
There is an algorithm called Adaptive A* which can recalculate a portion of a path say, if someone stands in front of you. I would concentrate on the vanilla A* first, you could always calculate a new path from that point on if you found half way through that a previously valid path was blocked.
This looks like interesting reading: Real-Time Adaptive A* [PDF]
如果游戏地图发生变化，您确实需要重新计算路径，但是您不一定需要根据更改的内容重新计算所有路径。
您应该将 GameMap 的方法集成到 Board 类中（对 GameMap 类进行修改）。
要阻挡正方形的边，您可以将每个图块视为九个独立的图块（3X3）。
例如，对于具有阻挡水平墙的瓷砖，
您可以将图块（对于您的 a* 算法）表示为：
垂直和水平图块被阻挡的图块：
您必须将附加边缘信息与游戏地图一起存储，而不是单个正方形。
希望这可以帮助。
If the game map changes you do need to recalculate paths, however you don't necessarily need to recalculate all paths depending on what changed.
You should integrate the methods of GameMap into your Board class (with modifications to the GameMap class).
To block sides of a square you could think of each tile as nine separate ones instead (3X3).
For example for a tile with blocked horizontal walls,
instead of a single square you can represent the tile (to your a* algorithm) as:
A tile with a vertical and horizontal tile blocked:
You would have to store the additional edge information with your game map.
Hope this helps.
对于路径问题：
一个简单的解决方案是当且仅当当前路径中的下一个移动被视为无效（地图上放置了新元素、添加了新房间、门已被打开）时，才重新计算路径。搬家了……）。 当然，你从当前位置重新计算。
如果阻挡元件是另一个移动元件，则问题会更加复杂。 在这种情况下，两个对象之一必须等待几个周期，另一个必须根据优先级重新路径。 然而，这可能会导致多路径碰撞的问题（门的一侧各有两个高优先级的物体，门内有一个低优先级的物体：它不能移动，高优先级的物体会等待很长时间
）房间问题：
通常将房间定义为一组图块而不是一个图块。 因此，您可以为一个房间定义子瓷砖是否可以通过。 如果您的模型允许，您甚至可以描述不同图块上存在的对象并将其设置为不可通行：等候室（6 个图块 x 4 个图块的房间）如果完全可以通过，但包含一组椅子和一个小房间喷泉使一些子瓷砖无法通行。
希望这对
纪尧姆有帮助
For the path question :
A simple solution is to recalculate the path if and only if the next move in the current path is considered as invalid (a new element has been put on the map, a new room has been added, a door has been moved...). Of course, you recalculate from the current position.
The problem is more complex if the blocking element is another moving one. In this case, one of the two objet has to wait a few cycle, and the other has to re-path, depending on a priority. however, this may lead to problems with multiple path collision (two high priority objec each one one side of the door, and a low priority object in the door : it can not move, and the high priority will wait a long time)
For the room problem :
It is common to define a room as a set of tiles instead of one tile. Thus, you can define for one room, the subtiles are passable, and those that are not. if your model allows it, you can even describe the objets that are present one the different tiles and set them as impassable : the waiting room ( a 6 tiles x 4 tiles room) if fully passable, but contains a set of chairs and a small water fountain that render some subtiles impassables.
Hope this helps
Guillaume