2.1 核心思想

這種方案的核心指導思想是，盡可能地通過旋轉和推近來找到可以看到主角的最佳位置，并通過預先設定，完成全自動的鏡頭跟蹤過程。

您可能會問，什么是最佳位置呢？因為它直接關乎到玩家的體驗，我們首先就來定義它：在3D游戲中，玩家對于鏡頭的運動是比較敏感的，當運動過快或者幅度過大時，都容易造成眩暈感。那么在盡可能能看到主角的情況下，相機運動幅度越小，眩暈感也就越少，那么此時的相機位置也就是“最佳位置”了。

依著這個思路，我們把最佳體驗從上到下做一個排列：

1. 相機沒有任何轉動或推近

2. 相機僅僅是為了避免進入模型內部而進行的推近，沒有任何轉動

3. 相機有一定的旋轉和推近（因為結合了兩個因素而可能有無數多個解，我們需要根據轉動最少的策略以及限制推近的取值范圍來確定唯一解）

4. 相機進行變化量幾乎不受限地推近嘗試直至看到主角，沒有任何轉動

5. 看不到主角，只能通過標志提示之類的輔助手段告知玩家主角位置

這些體驗當中，1和5都是比較容易理解的，2、3、4我來詳細闡述一下：
先來分析第2條，因為我們的目標是為了看到主角，而相機避免進入模型內部僅僅是一個“修正”行為，當我們在tick中逐幀處理此類“修正”行為時，大多數情況下相機的運動幅度是很小的，所以“僅僅通過修正行為就可以看到主角了”。因此這一條是有較高體驗價值的。

那么第2條和第4條的區別是什么呢？從算法上來看，當第2條成立時，那么它們是等價的。但是當第2條不成立時，第4條也是可能成立的，只是這個推近已經不是“修正”不正常位置的行為了，而是為了“看到主角”而進行的推近嘗試，屬于“主動策略”，其幅度可能會非常大，所以第4條和第2條雖然都是純推近，但是將這兩種情況分開處理，可以讓第4條這種情況作為第2條不成立后的補充策略，其價值排在其后。

再來看看第3條，前面說到第2條屬于“修正”行為，而第3條與第4條一樣都屬于“主動策略”，都是為了看到主角而做出的主動調整相機的行為。為了要區分出第3條與第4條的體驗價值高低，那么我們就要從一些具體的實例入手，這樣會更容易理解一些。

我們想象在一般的游戲情況下，主角在特定的場景中移動，通常會被一些石頭、木桶、樹木、墻壁拐角等遮擋。當主角試圖向此類遮擋物后方移動時，由于第三人稱視角下鏡頭與遮擋物是有一段距離的，遮擋物也有一定的體積，使用第4條的策略來調整，鏡頭推近的距離至少是大于遮擋物體積的（往往會大得多），相對調整成本就會很大。

使用第3條的策略來調整，調整成本往往與主角從可以被看見到被遮擋時的移動量呈正相關。比如主角在墻角轉彎，鏡頭只需要水平轉動一點即可再次見到主角，而且在逐幀處理時，這種策略帶來的調整成本通常都是不大的（特別是鏡頭與搖桿本身就已經有符合直覺的配合了，這個對于第3條策略也是有幫助的）。

由此，我們就得到了從1到5這樣的體驗排序，以盡可能提供更好的玩家體驗。

2.2 實現方案

談到鏡頭的跟蹤，主要解決以下三個問題：

• 鏡頭對主角的跟隨
• 如何能夠讓鏡頭進行符合直覺的轉動
• 主角被遮掩時的處理

2.2.1 如何讓鏡頭跟隨主角

原理很簡單，只要設定一個偏移量就可以了，或者最直接能夠想到的就是下面這個公式：

camera.transform.position = player.transform.position + offset; 

效果可以通過在update中執行代碼看到。
你會立即發現兩個問題：

問題1：必須要先把鏡頭的朝向確認好，并且不能改變

問題2：跟隨過程是瞬時的，體驗生硬

針對問題1，想要鏡頭無論在哪個朝向，都能讓主角在鏡頭里固定位置，我們可以使用Camera的一個接口：ViewportToWorldPoint(Vector3 viewport) 。

通過viewport，可以獲得指定的屏幕位置以及與相機距離的世界坐標點。利用這個接口，我們就可以根據主角的世界坐標與viewport換算后的世界坐標之間的相對位置，來找到使得兩個坐標重合的相機位置。

camera.transform.position = camera.transform.position + (player.transform.position - camera.ViewportToWorldPoint(viewport));  

針對問題2，獲得相機新的位置之后，不直接設置到transform上，而是通過緩動算法計算后則可以讓體驗更為平滑。

camera.transform.position = Vector3.SmoothDamp(current_p, target_p, ref follow_current_velocity, follow_smooth_time, float.MaxValue, delta_time); 

在下面的視頻中，可以看到實現效果。

2.2.2 如何能夠讓鏡頭進行符合直覺的轉動

這種需求，經常出現在需要通過遙感來控制主角行動的游戲中。什么是符合直覺的轉動呢？我們可以思考一個問題，當我們通過遙感控制主角往左行走時，我們是否是希望看到左側的景象？（這里并不考慮鎖定敵人進行戰術移動這種特定情形）答案顯然是肯定的，通常情況下，角色往那邊走，我們就希望看到更多的那邊的景象。

這里我們將行為簡單的分成：搖桿前后左右，分別調整相機的俯仰（pitch）和左右旋轉（yaw）。

 //當搖桿往左時，鏡頭也轉來看向左邊 
var delta_yaw = 0 < joystick.x ? yaw_speed * delta_time : -yaw_speed * delta_time; 
 //當搖桿往右時，鏡頭也轉來看向右邊 
var delta_pitch = 0 < joystick.y ? -pitch_speed * delta_time : pitch_speed * delta_time; 
 

同樣，也有一些細節需要處理和優化：
調整yaw過于靈敏會導致很難進行直線的前進和后退（因為相機會自動調整yaw值）。針對這個問題，可以設置一個角度高通值，只允許搖桿指針與垂直線角度大于此值時才開始調整yaw值。

如果調整度隨搖桿移動進行相對應的變化，體驗會更自然一些：比如搖桿指針與垂直線夾角越大，則調整度越大，反之越小。這能讓玩家體驗到越是偏向左右，相機左右轉動就會越快，越是偏向前后，相機左右轉動會越慢，甚至是不轉動（通過上面提到的角度高通值實現）。

由于鏡頭跟隨主角的實現方式是不受鏡頭朝向限制的，所以響應搖桿調整鏡頭朝向與跟隨主角能夠完美地配合起來，形成比較符合直覺的體驗。

在下面的視頻中，可以看到實現效果。

2.2.3 主角被遮掩時的處理

在主角被遮擋時，要怎么處理呢？鏡頭移動過程中，陷入了模型內部，要怎么修正？

常見的做法：半透（全透）+ 推近，將場景中的物體分為兩類，第一類用半透（全透）進行處理，這類物體通常較小，往往分布在行動路線上，常見的有樹木，小型裝飾物等；第二類則通過從主角向攝像機發射線，如果遇到此類物體阻擋，那么則將相機推進到碰撞點位置，這類物體往往較大，常見的有墻壁、大型裝飾物等。

本文介紹一種不太一樣的做法，這種做法不會將場景中的物體分類，而是全部都用同一種方式來處理。

在面對場景中任何遮擋物時，都用統一的一種方式進行處理，減少了場景編輯師的編輯工作，工程師無需特意實現半透（或隱藏）的效果。對玩家來說也能保持一致的體驗，理解成本低。

總體的邏輯思路如下：

 // 保持與主相機參數一致性
tick_camera(config, time, delta_time);
 // 處理搖桿對yaw和pitch的影響
var can_see = tick_joystick(config, time, delta_time);
if (!can_see)
{
     // 通過調整yaw或者pitc以及viewport_z，找到可以看到目標的位置
    tick_see(config, time, delta_time);
}
 // 根據fvp調整相機位置
tick_follow(config, time, delta_time);

這里重點說一下tick_see的邏輯：

 // 1. 嘗試正常的viewport
var see_ret = canSee(config, source_p, target_p, out Vector3 collision_p, out float collision_distance);
if (SeeResult.CAN_SEE == see_ret)
{
   // 恢復到正常viewport_z
  viewport_z = 0;
  return;
}
else if (SeeResult.CAN_SEE_SINGLE == see_ret)
{
  viewport_z = collision_distance;
  return;
}

上面這一段代碼是為了完成體驗價值排序里的第一條：相機沒有任何轉動和推近，以及第二條：相機僅僅是為了避免進入模型內部而進行的推近。

 // 找到可以看見目標的位置所需要的角度偏移值
private static float findOutCanSeeAngleOffset(
    CameraController config,
    float offset_delta,
    float offset_limit,
    System.Func<float, Vector3> vec_rotate_func,
    Vector3 source_p, Vector3 target_p, bool negative_rotate,
    out float collision_distance)

然后再通過上面這個接口，從鏡頭的四個不同旋轉方向來找到可以看到主角的相機位置，并記錄相應的旋轉量和推近量，并通過下面這個計算測試值的方法，得到四個方向的鏡頭調整成本測試值，測試值越低，代表成本越小。這樣就完成了體驗價值排序里的第三條：相機有一定的旋轉和推近。

// 計算選項的測試值（結合角度偏移值和zoom值，以及它們各自設定的權值）
private static float calcChooseTest(CameraController config, float angle_offset, float viewport_z_offset)
{
    var choose_test = float.MaxValue;
    if (360 > angle_offset)
    {
        choose_test = angle_offset * config.choose_angle_test_scale + viewport_z_offset * config.choose_viewport_z_test_scale;
    }
    return choose_test;
}

完成第四條體驗價值相對來說比較簡單了，這里直接使用了前面的策略計算后留下的一個值即可。

 // 沒有任何旋轉調整選項的話，如果僅zoom便可見且zoom值在設定的最小值以上，則使用zoom
if (config.viewport_z_min < collision_distance)
{
    viewport_z = collision_distance;
} 

至于第五條體驗價值，先賣個關子，文末揭曉。

2.3 代碼的適配和調整方案

根據以上操作，全自動的跟隨方案就實現了。比如，讀者在游戲開發中，可能會有一些不一樣的需求，大家根據附贈的代碼（可在第三節文末下載），可以做出符合自己的設置。

本文提供的方案代碼是可以直接用于游戲的，使用時根據自己游戲的特點去配置各項參數，以調試出最佳體驗。當然也可以將方案的幾個處理模塊拆出來單獨使用：僅跟隨、與搖桿配合、處理遮擋物，或者添加更多的鏡頭控制方案，切換使用，以適應不同的場合。

// 沒有任何旋轉調整選項的話，如果僅zoom便可見且zoom值在設定的最小值以上，則使用zoom，否則不可見
if (config.viewport_z_min < collision_distance)
{
    viewport_z = collision_distance;
}
else
{
    // TODO 需要處理相機陷入模型的情況（兩次射線找到修正位置），同時還可以通過屏幕指示來告知玩家
    Debug.Log("can't see");
}