Coordinated Unit Movement
by Dave Pottinger
原文地址：https://www.gamasutra.com/view/feature/131720/coordinated_unit_movement.php
找到一篇譯文 [譯] 協調的單位運動 Dalton’s Dev Blog
在該篇譯文的評論區 找到了原文刊登物的PDF版本
http://twvideo01.ubm-us.net/o1/vault/GD_Mag_Archives/GDM_January_1999.pdf
Page 42 開始
正文
概述 Overview
Paragraph 1
How many times have you been sitting in rush-hour traffic thinking, “Hey, I know where I want to go. And I’m sure everyone around me knows where they want to go, too. If we could just work together, I’ll bet we would all get where we wanted to go a lot easier, faster, and without rear-ending each other”? As your frustration rises, you realize that impatient commuters aren’t the most cooperative people. However, if you’re a game player, uncooperative resource gatherers and infantry are probably even more frustrating than a real-life traffic jam.
有多少次，當你身處在在交通擁堵之中想：“我其實知道自己想要去哪，也確定自己身邊的人們知道他們各自的目的地。如過能互相協助，我打賭我們各自可以更快、更簡單並且不發生追尾的的情況下到達目的地。”然後你會挫折的意識到，這些不耐煩的通勤人並不是最合作的人。但是當你作爲一個玩家，不合作的資源採集者和步兵可能比交通擁堵更讓人心煩。
Paragraph 2
Figuring out how to get hundreds of units moving around a complex game map in real time - commonly referred to as pathfinding - is a tough task. While pathfinding is a hot industry buzzword, it’s only half of the solution. Movement, the execution of a given path, is the other half of the solution. For real-time strategy games, this movement goes hand in hand with pathfinding. An axeman certainly needs a plan (as in, a path) for how he’s going to get from one side of his town to the other to help stave off the enemy invasion. If he doesn’t execute that plan using a good movement system, however, all may be lost.
找出如何讓成千上百的單位在一個複雜的遊戲地圖上實時的移動（通常被稱作尋路）是一個困難的任務。“尋路”是一個非常熱門的業內詞彙，但只是解決方案的一半。“移動”即完成既定路線，是這個解決方案的另外一半。對於實施戰略遊戲（RTS）“移動”和“尋路”是齊頭並進的。當一個戰士想要阻止敵人的入侵，需要從鎮子的一邊走到另外一邊，必然需要一個計劃（比如：一個路徑）。然而如果他不能用一個好的移動系統來執行這個計劃，一切都可能失去。
Paragraph 3
Game Developer has already visited the topic of pathfinding in such past articles as “Smart Move: Path-Finding” by Brian Stout (October/November 1996) and “Real-Time Pathfinding for Multiple Objects” by Swen Vincke (June 1997). Rather than go over the same material, I’ll approach the problem from the other side by examining the ways to execute a path that’s already been found. In this article, I’ll cover the basic components of an effective movement system. In a companion article in next month’s Game Developer, I’ll extend these basic concepts to cover higher-order movement and implementation. Though the examples in these articles focus mainly on a real-time strategy game, the methods I’ll describe can easily be applied to other genres.
遊戲開發者們已經瞭解過一些尋路上面論文，比如Brian Stout (October/November 1996)《Smart Move: Path-Finding》以及Swen Vincke (June 1997).《Real-Time Pathfinding for Multiple Objects》相比於重複這些同樣的內容，這篇文章將會更加側重於討論對於一個已經找到的路徑的檢測，將會介紹一個有效的運動系統的基本構成。也將會在在下個月的GameDeveloper上的論文對這些高階的運動和實現進行擴展。儘管文章中的粒子主要針對於RTS遊戲，但是也可以很容易的應用到其他遊戲上面去。
基本定義 Basic Definitions
Basic DefinitionsMovement. The execution of a path. Simple movement algorithms move a unit along a path, while more complex systems check collisions and coordinate unit movement to avoid collisions and allow otherwise stuck units to move.
運動的基本定義。路徑的執行。簡單的運動算法將運動個體沿着路徑移動，而複雜的系統檢測碰撞，協調運動個體之間的運動來避免碰撞，使得被卡住的運動個體迴歸運動。
Pathfinding. The act of finding a path (a planned route for a unit to get from point A to point B). The algorithm used can be anything from a simple exhaustive search to an optimized A* implementation.
尋路。 尋找一個路徑（一個運動單位從A點到B點的計劃路線）的行爲。使用的算法可以是簡單的窮舉搜索，也可以是優化過的A*算法。
Waypoint. A point on a path that a unit must go through to execute the path. Each path, by definition, has one waypoint at the start and one waypoint at the end.
路點。 一個運動單元在執行路徑時必經的路徑上的點。根據定義，任何路徑至少在開始點擁有一個路點，結束時擁有一個路點。
Unit. A game entity that has the ability to move around the game map.
單位個體（運動個體）。 在遊戲地圖中擁有移動能力的遊戲實體。
Group. A general collection of units that have been grouped together by the user for convenience (usually to issue the same order to all of the units in the group). Most games try to keep all of the units in a group together during movement.
組。 用戶爲了方便組合在一起單元個體的一般集合（通常給組內的所有個體發出相同的指令）。大多數遊戲在移動的過程中保持所有組內的個體集合的狀態。
Formation. A more complex group. A formation has facing (a front, a back, and two flanks). Each unit in the formation tries to maintain a unique relative position inside the formation. More complex models provide an individualized unit facing inside of the overall formation and support for wheeling during movement.
編隊。 一個更加複雜組結構。編隊擁有面向（前、後、兩側）。編隊中的每一個單位個體都嘗試在編隊內保持一個編隊內獨特的相對位置。更加複雜的模式中，提供一個個性化的單位在運動中根據整體的隊形做出面向的旋轉。
Hard Movement Radius. A measure of the volume of a unit with which we absolutely do not allow other units to collide.
“硬質”移動半徑。 我們絕對不容許其他單位碰撞到的體積的大小。
Soft Movement Radius. A measure of the volume of a unit with which we would prefer not to collide.
“軟性”移動半徑。 我們不想被其他單位碰撞到的體積的大小。
Movement Prediction. Using the movement algorithms to predict where a unit will be at some point in the future. A good prediction system will take acceleration and deceleration into account.
移動預測。 使用運動算法預測運動個體在將來將會到達的某個位置，一個好的預測系統將會把加速度和減速列入考慮的範圍。
Turn Radius. The radius of the tightest circle a unit can turn on at a given speed.
旋轉半徑。 在給定速度下可以進行轉向的最貼近的圓的半徑。
開發者面對的移動問題 Movement Issues Facing Game Developers
Paragraph 1
Before we dive into coordinated unit movement, let’s take a look at some of the movement issues facing game developers today. Most of these have to do with minimizing CPU load versus maximizing the accuracy and intelligence of the movement.
在我們深入討論協調遊戲單位的運動之前，我們先來看一下當今開發者面對的一些運動問題。大部分都需要在減少CPU的負載和提高運動的準確性和智能性之間做出權衡。
Paragraph 2
Moving one unit versus moving multiple units. Moving one unit is generally pretty simple, but methods that work well for one unit rarely scale up effortlessly for application to hundreds of units. If you’re designing a system for hundreds of units, it will need to be very conservative in its CPU use.
移動單一個體和移動多數個體的對比。 單獨個體的移動十分簡單，但是對於單獨個體很合適的方法很少能直接擴展到數百個個體上面去。如果爲數百個體設計系統，在CPU的使用上面將會十分保守。
Paragraph 3
Some movement features are CPU intensive. Very few games that move hundreds of units support advanced behavior such as modeling the acceleration and deceleration of these units. The movement of large ships and heavily armored units has a lot more realism with acceleration and deceleration, but that realism comes at a high cost in terms of extra CPU usage. The actual movement calculation becomes more complicated because you have to apply the time differential to the acceleration to create the new velocity. As we extend our movement system to handle prediction, we’ll see that acceleration and deceleration complicate these calculations as well. Modeling a turn radius is also difficult because many pathfinding algorithms are not able to take turn radii into account at all. Thus, even though a unit can find a path, it may not be able to follow that path because of turn radius restrictions. Most systems overcome this deficiency by slowing the unit down to make a sharp turn, but this involves an extra set of calculations.
一些運動的特性是CPU的劇烈消耗。 只有非常少的遊戲在移動上百個單位時，支持這些單位的加速和減速，對於大型的船隻和重型武裝的單位來說需要更多擬真的加速和減速的模擬，但是大量的擬真會增加CPU的負荷。因爲必須考慮到不同時間片之間加速度計算產生新的速度。當我們給移動系統擴展了預測的功能，我們將會發現加速和減速也會使得計算更加複雜化。模擬一個轉彎的半徑也十分複雜，因爲很多尋路不能完全的計算到轉彎半徑。因此，儘管單個單位可以找到路徑，但是這個單位並不能遵從他的路徑來移動，因爲轉彎半徑的限制。大多數的系統通過減緩遊戲單位的速度來做出一個急轉彎，來克服這樣的缺陷，但是仍舊涉及到了一組額外的計算。
Paragraph 4
Different lengths for the main game update loop. Most games use the length of the last pass through update loop as some indication of how much time to simulate during the next update pass. But such a solution creates a problem for unit movement systems because these lengths vary from one update to the next (see Figure 1 below). Unit movement algorithms work much better with nice, consistent simulation intervals. A good update smoothing system can alleviate this problem quite a bit.
Figure 1. Varied update lengths cause units to move differing distances each update.
遊戲內的Update循環長度並不一致（時間片長度不一致）。 大多數遊戲使用的是上一次經過的Update循環的長度來作爲下一個Update的模擬時常。但是這樣的解決方案會給移動系統提出一個問題，從一個Update到下一個Update之間的不同（見下圖）。在一致的時間間隔下，單元移動算法的工作將會更好。所以一個好的Update平滑系統可以很好的緩解這個問題。
圖1：每次Update的長度不同導致距離上移動的不同
Paragraph 5
Sorting out unit collisions. Once units come into contact with one another, how do you get them apart again? The naïve solution is just never to allow units to collide in the first place. In practice, though, this requirement enforces exacting code that is difficult to write. No matter how much code you write, your units will always find a way to overlap. More importantly, this solution simply isn’t practical for good game play; in many cases, units should be allowed to overlap a little. Hand-to-hand combat in Ensemble Studios’ recent title Age of Empires should have been just such a case. The restriction for zero collision overlap often makes units walk well out of their way to fight other units, exposing them to needless (not to mention frustrating) additional damage. You’ll have to decide how much collision overlap is acceptable for your game and resolve accordingly.
整理遊戲個體的碰撞。 一旦遊戲單位與其他的遊戲單位有了接觸的發生，我們要如何把他們再次分割開來？一個天真的解決辦法，是從一開始就不容許兩個遊戲單位互相碰撞。然而在實踐之中，這樣的要求需要嚴格執行代碼，然而這樣的代碼又是難以編寫的。不管多少代碼約束，遊戲單位都將有重疊。更加重要的是，這樣的解決方案在遊戲中並不適用，大多數的情況下，遊戲單位都需要容許小部分的部分重疊。全效工作室（Ensemble Studios）開發的帝國時代（Age of Empires）中的肉搏戰就是這樣的一個情況。限制一種零重疊的碰撞，經常使得遊戲單位離開自己的路線來和敵人做出戰鬥，這使得他們暴露在不必要（和令人沮喪的）額外傷害上。所以不得不決定出對於你自己的遊戲來說，多少重疊度纔是可以接受的。
Paragraph 6
Map complexity. The more complex the map is, the more complicated and difficult good movement will be to create. As game worlds and maps are only getting more intricate and realistic, the requirement for movement that can handle those worlds goes up, too.
地圖的複雜度。 地圖越是複雜，得出一個良好的移動將越複雜和困難。隨着遊戲內的世界和地圖變得越來越複雜和真實，對於處理好這些地圖上面的運動的需求也在增加。
Paragraph 7
Random maps or controlled scenarios? Because you can’t hard-code feasible paths, random maps are obviously more difficult to deal with in many cases, including pathfinding. When pathfinding becomes too CPU intensive, the only choice (aside from reducing map complexity or removing random maps) is to decrease the quality of the pathfinding. As the quality of the pathfinding decreases, the quality of the movement system needs to increase to pick up the slack.
隨機地圖和固定場景的選擇。 因爲硬編碼可行路徑並可可能，所以隨機地圖將會面對更多的問題，包括尋路。當尋路佔據了太多的CPU負載，唯一的選擇將會是（不考慮移除隨機地圖或者減少地圖的複雜度）降低尋路的質量。如果降低了尋路的質量，那麼需要更高質量的移動系統來彌補尋路上面的漏洞。
Paragraph 8
Maximum object density. This issue, more than anything, dictates how accurate the movement system must be. If your game has only a handful of moving objects that never really come into contact with one another (as is the case with most any first-person shooter), then you can get away with a relatively simple movement system. However, if you have hundreds of moving objects that need to have collision and movement resolution on the scale of the smallest object (for example, a unit can walk through a small gap between two other units), then the quality and accuracy requirements of your movement system are dramatically raised.
物體最大密度。 這一點比其他的問題更加重要，決定了運動系統的必要精度。如果你的遊戲只有很少數的可移動物體，並且這些物體不會互相接觸（比如大多數第一人稱射擊），那麼可以使用一個相對簡單的運動系統來解決問題。如果你需要上百個可移動的物體，需要有碰撞，可以在細小的物體間隔中找到移動的解決方案（比如一個運動單位可以通過另外兩個運動單位形成的間隙），那麼運動系統的精度和質量需求將會大幅度的被拉高。
簡單的運動算法 Simple Movement Algorithm
Paragraph 1
Let’s start with some pseudo code for a simple, state-based movement algorithm (Listing 1). While this algorithm doesn’t do much more than follow a path and decide to find a new path when a collision is found, it does work equally well for both 2D and 3D games. We’ll start in a given state and iterate until we can find a waypoint to move towards. Once we find that point, we break out of the loop and do the movement.
讓我們從一些簡單的僞代碼開始，基於狀態的運動算法（列表1）。雖然這個算法只是跟隨路徑，並且在遭到碰撞的時候尋找新的路徑，但是這個在2D和3D的遊戲中都是通用的。我們將會從一個給定的狀態開始迭代，直到尋找到移動的目標路點。一旦找到這個點，就打破循環開始做出移動。
Paragraph 2
There are three states: WaitingForPath, ReachedGoal, and IncrementWaypoint. The movement state for a unit is preserved across game updates in order to allow us to set future events, such as the “automatic” waypoint increment on a future game update. By preserving a unit’s movement state, we lessen the chance that a unit will make a decision on the next game update that counters a decision made during the current update. This is the first of several planning steps that we’ll introduce.
運動狀態一共包含有三個：WaitingForPath等待路徑，ReachedGoal到達終點，以及IncrementWaypoint路點遞增【額外說明】個人理解此處的“遞增”並不是數量上面的描述，而是依照計算好的waypoint的順序依次向後進行移動的“遞增”。在遊戲Update過程中運動個體的運動狀態將會被記錄，用作設置未來發生的事件，例如在未來的遊戲Update中“自動的”路點遞增。通過保存運動狀態，減少了在下個Update中做出重複決策計算的可能性。這是我們計劃介紹的步驟中的第一條。
Paragraph 3
We assume that we’ll be given a path to follow and that the path is accurate and viable (meaning, no collisions) at the time it was given to us. Because most strategy games have relatively large maps, a unit may take several minutes to get all the way across the map. During this time, the map can change in ways that can invalidate the path. So, we do a simple collision check during the state loop. At this point, if we find a collision, we’ll just repath. Later on, we’ll cover several ways to avoid repathing.
我們假設，已經被給定一條路徑，這條路徑在給定的時候是正確並且可行的（意爲路徑上沒有碰撞）。大多數戰略類的遊戲都有一個相對很大的地圖，一個單位跑動橫穿地圖都需要數分鐘才能完成。在這個時間中，地圖可能發生各種變化使得給定的路徑無效。所以，我們要在狀態的循環當中做一個簡單的碰撞體檢測。在這一點上，當找到碰撞體，就會重新規劃路徑repath。稍後我們將提出幾種方法來避免repath。
列表1. 移動算法的僞代碼 Listing 1. Movement Algorithm in Pseudocode.
【額外說明】下面僞代碼的折行情況已經參照原文刊物上面的印刷做過訂正
Top of movement state loop:
{
If we're in IncrementWaypoint state:
Increment our waypoint.
If we're on a patrol
Grab the next waypoint as defined by the patrol direction.
Set state to WaitingForPath.
Else
If we're out of waypoints
Set state to ReachedGoal.
Else
Set state to WaitingForPath.
If we're in ReachedGoal state:
Make the appropriate notifications (if any).
We're done. Stop the walking animation. Exit function.
If we're in WaitingForPath state:
Find a path and save it.
If we could not find one
We've failed. Exit function.
Calculate the direction we need to head in to get to our desired waypoint.
Modify that direction by any limitations such as turn radius.
Using that new direction, calculate where we'll end up after this move.
If that new position causes a collision
Set state to WaitingForPath.
Jump back to the top of the loop.
Using the current and future position:
If we're closer to the waypoint before moving
Set state to IncrementWaypoint
Go back to top of loop.
If we're going to jump over the waypoint during this move
Set state to IncrementWaypoint.
Break out of loop.
}
Set the accelerations accordingly.
Do the actual move.
Set or update any animation hooks that we might have.
Update our predicted positions【額外說明】變量關鍵詞保留未做翻譯
運動循環的開始：
{
If 正在IncrementWaypoint（路點遞增）狀態下：
路點遞增。
If 正在進行巡邏
獲取下一個路點作爲巡邏目標點。
將狀態設置爲WaitingForPath（等待路徑）。
Else
If 所有路點已經使用
將狀態設置爲ReachedGoal（抵達終點）。
Else
將狀態設置爲WaitingForPath（等待路徑）。
If 正在ReachedGoal（抵達終點）狀態下：
發出適當的通知 (如果有的話)。
完成。停止行走動畫。退出方法。
If 正在WaitingForPath（等待路徑）狀態下：
尋找到一個路徑並保存它。
If 找不到任意一條路徑
失敗。退出方法。
計算出我們想要走到期望的路點所需的direction（方向）。
在各種限制條件之下，比如轉彎半徑，修改direction（方向）。
使用新得出的direction（方向）, 計算出這次移動的結束點位置。
If 新的位置點會觸發碰撞
將狀態設置爲WaitingForPath（等待路徑）。
跳回到循環的最開始。
使用當前點和未來到達點：
If 移動前的位置距離路點比較近
將狀態設置爲IncrementWaypoint（路點遞增）狀態
跳回到循環的最開始。
If 移動過程中將會跳過路點
將狀態設置爲IncrementWaypoint（路點遞增）狀態。
跳出循環。
}
設置相應的加速度。
做出移動。
設置、更新可能存在的animation hooks（動畫鉤子）。
更新預測位置。碰撞檢測 Collision Determination
Paragraph 1
The basic goal of any collision determination system is to find out if two units have collided. For the time being, we’ll represent all collisions as two-entity collisions. We’ll cover compound collisions (collisions involving three or more entities) next month. Once a collision is found, each entity needs to know about the collision in order to make appropriate movement decisions.
任何碰撞系統的基本目的就是檢測出兩個單位是否發生了碰撞。我們暫時將所有的碰撞問題簡化爲兩個實體的碰撞。我們將會在下個月論及符合碰撞（三個或者更多實體的碰撞）。如果檢測到了碰撞，每一個實體都需要知道碰撞的情況，用來做出適當的運動決策。
Paragraph 2
Basic collision determination for most strategy games consists of treating all units as spheres (circles in 2D) and doing a simple spherical collision check. Whether or not such a system is sufficient depends on the specific requirements of a game. Even if a game implements more complex collision - such as oriented bounding boxes or even low-level polygon to polygon intersection tests - maintaining a total bounding sphere for quick potential collision elimination will usually improve performance.
大多數的策略遊戲的基礎碰撞系統，是將所有的單位個體視作球體（2D中爲圓）並且進行簡單的球形碰撞檢測。這樣的系統是否足夠取決於遊戲具體的情況。即使一個遊戲中有更多複雜的碰撞比如：定向的包圍盒、各種多邊形的碰撞，使用一個包圍的球體做快速的潛在碰撞檢測通常會提高性能。
Paragraph 3
There are three distinct entity types to take into account when designing a collision system: the single unit, a group of units, and a formation (see Figure 2 below). Each of these types can work well using a single sphere for quick collision culling (elimination of further collision checks). In fact, the single unit simply uses a sphere for all of its collision checking. The group and the formation require a bit more work, though.
Figure 2. Collision entities.
在設計碰撞系統時，需要考慮三種不同的實體類型：單個個體，一組個體以及一個編隊（見下圖）。每一種類型都可以使用球體進行快速的碰撞剔除（避免更多的碰撞檢測）。儘管事實上，單個單位只是用一個球體進行全部的碰撞檢測。一組個體和編隊都需要做更多的功課。
圖2：碰撞實體類型
Paragraph 4
For a group of units, the acceptable minimum is to check each unit in the group for a collision. By itself, this method will allow a non-grouped unit to sit happily in the middle of your group. For our purposes, we can overlook this discrepancy, because formations will provide the additional, more rigid collision checking. Groups also have the ability to be reshaped at any time to accommodate tight quarters, so it’s actually a good idea to keep group collision checking as simple as possible.
對於“一組單位”而言，可接受的最低條件是檢測組內單位互相碰撞的情況。對於這組單位本身來講，將可以容許一個非組內的單位在愉快的待在羣組內。站在我們的的角度來看，我們可以忽略這種差異，因爲“一組單位”將會額外提供更加嚴格的碰撞檢測。“一組單位”還擁有任意時間調整形狀來適應擁擠空間的能力，所以將“一組單位”儘可能簡化來做碰撞檢測是一個好主意。
Paragraph 5
A formation requires the same checks as a group, but these check must further ensure that there are no internal collisions within the formation. If a formation has space between some of its units, it is unacceptable for a non-formed unit to occupy that space. Additionally, formations generally don’t have the option to reshape or break. However, it’s probably a good idea to implement some game rules that allow formations to break and reform on the other side of an obstacle if no path around the obstacle can be found.
“編隊”要求和“一組單位”同樣的檢測，但是需要更進一步檢測保證編隊中的個體之間沒有碰撞。如果編隊的某些個體之間存在空間，這些空間不容許非編隊的個體佔用。此外“編隊”不具有重新調整或者打破的選項。然而，找不到障礙路周圍路徑的時候，實現一些遊戲規則，讓“編隊”打破，並在障礙物另外一側重組可能是一個好的主意。
Paragraph 6
For our system, we’ll also keep track of the timing of the collision. Immediate collisions represent collisions currently existing between two objects. Future collisions will happen at a specified point in the future (assuming neither of the objects changes its predicted movement behavior). In all cases, immediate collisions have a higher resolution priority than future collisions. We’ll also track the state of each collision as unresolved, resolving, or resolved.
在我們的系統中，將會追蹤碰撞的時間點。現有碰撞Immediate collisions代表當前存的碰撞的兩個對象。將要發生的碰撞Future collisions是將要發生碰撞的某個點（在兩個對象都不改變自己的運動行爲的條件下）。在所有的例子中，現有碰撞Immediate collisions的處理優先級都高於將要發生的碰撞Future collisions。我們也將會使用未解決unresolved， 解決中resolving,，以及已經解決resolved來記錄每一個碰撞的處理狀態。
離散模擬 VS 連續模擬 Discrete vs. Continuous Simulation
Paragraph 1
Most movement algorithms are discrete in nature. That is, they move the unit from point A to point B without considering what might be between those two points, whereas a continuous simulation would consider the volume between the two points as well. In a lag-ridden Internet game, fast moving units can move quite a distance in a single game update. When discrete simulations are coupled with these long updates, units can actually hop over other objects with which they should have collided. In the case of a resource gathering unit, no one really minds too much. But players rarely want enemy units to be able to walk through a wall. While most games work around this problem by limiting the length of a unit’s move, this discrete simulation problem is relatively easy to solve (see Figure 3 below).
Figure 3. Solving the problem with discrete movement simulation.
大多數移動的算法都是離散的，也就是說，把個體從A運動到B，不考慮這兩個點之間可能存在的狀況，而連續的模擬將會把中間的因素也加入模擬。在一個充滿延遲的網絡遊戲之中，快速移動的單位在單次更新（Update）中可能移動相當遠的距離。當離散模擬遇到這些產距離的更新（Update）時，單位將會跳過路徑上可能遭遇的碰撞。這一點在資源收集單位上，沒人會太在意。但是玩家並不想看到敵人穿過牆壁。雖然大多數的遊戲通過限制個體的移動步長來解決這個問題，但是這個離散模擬的問題比較容易解決（參見下圖3）
圖3：離散移動模擬問題的求解
Paragraph 2
One way to solve the problem is to sub-sample each move into a series of several smaller moves. Taking the size of the moving unit into account, we make the sampling interval small enough to guarantee that no other unit can fit between two of the sample points. We then run each of those points through the collision determination system. Calculating all of those points and collisions may seem overly expensive, but later on we’ll see a potential way to offset most of that cost.
其中一個方法是將移動採樣成爲一連串連續的移動。根據移動單位的尺寸，我們將採樣間隔定的足夠小，來保證兩個採樣點之間無法插入任何單位。然後我們隊每一個點進行碰撞的判定。進行所有這些點的碰撞判定看起來消耗過大，但是我們稍後將會提供一種潛在方法抵消大部分成本。
Paragraph 3
Another method is to create what we’ll call a move line. A move line represents the unit’s move as a line segment starting at point A and ending at point B. This system creates no extra data, but the collision check does have an increase in complexity; we must convert from a simple spherical collision check to a more expensive calculation that involves finding the distance from a point to a line segment. Most 3D games have already implemented a fast hierarchical system for visible object culling, so we can reuse that for collision culling. By quickly narrowing down the number of potential collisions, we can afford to spend more time checking collisions against a small set of objects.
另一種解決方法是創建一種名叫移動線（move line）的東西。移動線可以表現出個體從A作爲起點，B爲重點的移動。這個系統並不會增加額外的數據，但是在碰撞檢測上增加了複雜度。我們必須把簡單的球形碰撞檢測轉化爲更加“昂貴”的點到線段的計算。大部分的3D遊戲已經實現了分層系統，可以快速的進行可見剔除，我們可以重用它來做碰撞剔除。通過快速縮小潛在碰撞的數量，我們可以承擔花費更多時間來進行一小部分物體的碰撞檢測。
寫在最後
下半篇請見【喵喵丸的博客】【翻譯搬運】協調運動單元的移動 Coordinated Unit Movement【二】
（https://blog.csdn.net/u011643833/article/details/79680425）
本篇已經根據原文在雜誌中的刊登格式重新作出了排版。
最後，歡迎各位留言指正~
轉載請註明，出自喵喵丸的博客 （https://blog.csdn.net/u011643833/article/details/79680419）