【翻译搬运】协调多个运动单元的移动 Coordinated Unit Movement【一】

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）