遊戲框架核心科技與面試精粹 (樊松陽著)

綁定響應的方式有兩種: 在組件中添加和在代碼中添加. 它們的核心相同, 都是經過代理來回調本身的函數. 組件綁定的操做更友好,但容易被人更改. 代碼綁定的優勢是更穩定,並且能更靈活地控制監聽的事件點,缺點是邏輯編譯在代碼中, 最好有健全的框架支持, 以防止出現使用問題.例如, 重複綁定的處理函數, 忘記移除的綁定,等等

[擴展問題]

　　1. 有沒有辦法克服代碼綁定的缺點?

　　2. 既然你們都傾向於使用代碼綁定, 那麼組件綁定的存在有意義嗎?

　　1.2 事件傳遞流程

請從結構的角度概述,控件的消息模型包含哪些部分, 並解釋UGUI中點擊事件與響應調用是如何關聯在一塊兒的

[事件體系]

首先說明, 事件體系的基礎是設計模式中的觀察者模式, 所以按照標準的Subject和Observer來解讀沒有任何問題. 但在這裏, 筆者更但願以功能爲導向, 將事件體系劃分紅更易於理解的模塊. 按這種劃分方式, 事件體系由四部分組成, 分別是:

　　監測器(Monitor)

　　採集器(Collector)

　　派發器(Dispathcer)

　　響應器(Receiver)

其中用戶的操做被監視器驅動的採集器捕獲, 接着監視器將反饋的信息通知到派發器中,最後經過派發器將事件傳播出去

[Unity3D 實現]

在Unity3D中, 功能模塊的每一個部分都有對應的實現類

　　監測器 (Monitor) 對應的實現類爲EventSystem. 它重寫了MonoBehavior的Update方法, 會在每一幀更新掛載在同一個GameObject上的採集器組件狀態, 並判斷是否應該激活派發器. 若是是, 則調用各個派發器中的派發函數Process

　　採集器 (Collector) 由兩部分組成, 對應的實現類分別爲BaseInputModule和BaseRaycaster, 在UGUI中默認使用的是它們的子類StandaloneInputModule和GraphicRaycaster. 當用戶操做時, 會由BaseInputModule激活模塊, 而後發出一個射線點觸, 返回在BaseRayCaster中能點到的物體並返回信息, 交由派發器進行過濾. 因此採集器有兩端,鏈接它們要靠EventSystem.整個過程當中還有一個靜態內部的管理類RaycasterManager, 用來作鏈接採集器和監測器的數據橋樑

　　派發器 (Dispatcher) 對應的實現類也爲BaseInputModule, 最經常使用的是它的子類StandaloneInputModule, 該類的角色於採集器混在一塊兒.派發器完成了實際的事件生成, 包括且不限於: 事件類型的肯定, 事件內容的提取, 派發對象的過濾. 其中對派發對象的獲取須要藉助採集器, 但須要經過監測器來驅動. 這種設計能夠帶來效率上的優點, 便可以合併採集操做, 以達到下降事件頻率的目的

　　響應器 (Receiver) 對應的實現類爲IEventSystemHandler及其子類, 例如最經常使用的IPointerClickHandler, 它的做用是處理點擊事件. 經過ExecuteEvents類, 能夠將發生事件的對象上的全部響應器都獲取到並調用其響應邏輯. 以點擊爲例, 事件最終會被派發到OnClick的代理上, 完成邏輯的執行

[類圖]

[總結]

[擴展問題]

　　1. 請結合設計模式中的觀察者模式, 分析Unity事件框架的優劣

　　2. 如何利用EventSystem來下降事件的頻率

控制能夠控制採集器中的採集頻率，或派發器中派發事件的頻率。理論上StandaloneInputModule組件中有InputActionPreSecond這個變量可用來控制消息輸入，但查閱源碼，只發現它對導航按鈕作了限制，未實現其餘類型的控制，代碼版本爲5.5。

　　1.3 事件響應接口

一般對於事件傳遞, 綁定消息處理時都要些不少相同的框架級別方法,例如:

m_btn1.onClick.AddListener(OnBtnClick1);
m_btn2.onClick.AddListener(OnBtnClick2);
m_btn3.onClick.AddListener(OnBtnClick3);

public void OnBtnClick1() { }
public void OnBtnClick2() { }
public void OnBtnClick3() { }

View Code

請問是否有方法對其簡化, 減輕開發編碼量?

[擴展問題]

　　1. 有辦法對各類控件添加統一的響應接口嗎?

　　2. 有時候界面中會有大量不顯示的按鈕, 這會影響咱們的封裝嗎?

若是存在大量的隱藏按鈕，會致使界面中加載不少無用監聽，下降遊戲運行效率。爲了解決這個問題，能夠將綁定函數放到OnEnable中，並在OnDisable中解綁

第2章玩法底層

　　2.1 遊戲循環

請簡述Unity 3D中經常使用的生命週期函數, 並以此爲基礎簡述遊戲循環的設計要點

[問題分析]

通常來講, 在大型商業項目中, 咱們須要自制一套遊戲循環, 來知足多變的遊戲玩法, 那些現有的聲明周期函數可使用?那些須要被替換掉?這些取捨貫穿了整個遊戲開發過程

[生命週期]

深刻理解這張圖, 能夠應對大多數的時序問題. 在Initialization, Disable/enable, Decommissioning區域的函數只會調用有限次數, 而其餘部分都是受控重複或循環調用, 其中

　　Awake函數在構造腳本對象時調用

　　OnEnable/OnDisable在每次激活對象時調用

　　Start在第一次觸發腳本時調用

　　OnDestroy在銷燬對象時調用

主循環分爲物理模擬, 遊戲邏輯, 渲染繪製三個子循環. 從Unity實現的方式來看, 這三個循環是在同一個線程中. 不過自Unity 3D的5.x版本中, 引擎加入了多線程渲染的選項, 即把第三步循環放在另外一個線程中進行, 這樣就能夠在固定幀率降低低邏輯循環的壓力, 減小掉幀現象的發生. 至於物理模擬循環, 筆者以爲不必拆出到另外一個線程.畢竟線程間通訊也須要性能,而物理模擬循環運行的速度通常要快於遊戲邏輯, 若是出現數據訪問衝突時還須要加鎖,就得不償失了

[重寫模板腳本]

using UnityEngine;
using System.Collections;

public class #SCRIPTNAME#: MonoBehavior {
    #region Public Attributes
    #endregion
    #region Private Attributes
    #endregion
    #region Unity Message
//  void Awake() {
//  }
//  void OnEanble() {
//  }
//  void Start() {
//  }
//  void Update() {
//  }
//  void OnDisable() {
//  }
//  void OnDestroy() {
//  }
    #endregion
    #region Public Methods
    #endregion
    #region Override Methods
    #endregion
    #region Private Methods
    #endregion
    #region Inner
    #endregion
}

View Code

[遊戲循環]

while (true) {
    Input();
    Update();
    Render();
}

View Code

從這個層面看, 遊戲循環由三部分組成, 分別是

　　1. 非阻塞的用戶輸入

　　2. 更新遊戲邏輯狀態

　　3. 渲染遊戲畫面

每次循環完成後, 會更新一次畫面的繪製, 這個過程也被稱爲幀(Frame). 幀率(FPS)能夠標定遊戲循環的速率與真實時間的映射關係. 幀率值越小, 意味着遊戲越"卡". 遊戲在PC上, 一般爲60幀/秒, 在手機上爲30幀/秒. 另外一方面,幀率的倒數即爲每幀所佔用的時長, 單位一般爲毫秒. 影響幀率的主要因素是每幀須要作的工做. 例如, 複雜的物理計算, 遊戲邏輯的處理, 圖形細節控制等, 這些都會佔據CPU與GPU. 若是處理操做的時長超過幀率的倒數,那麼就會拖慢幀率,這種現象稱爲"掉幀"

[固定幀率模式]

while (true) {
    double start = getCurrentTime();

    Input();
    Update();
    Render();

    sleep(start + 1/FPS - getCurrentTime());
}

Application.targetFrameRate = FPS;

View Code

[追趕模式]

double preFrameTime = getCurrentTime();
double lag = 0.0;

while (true) {
    double current = getCurrentTime();
    double elapsed = current - preFrameTime;
    preFrameTiem = current;
    lag += elapsed;

    Input();

    while (lag >= 1/FPS) {
        Update();
        lag -= 1/FPS;
    }

    Render();
}

View Code

[總結]

Unity 3D做爲完整的引擎, 常見的生命週期函數與遊戲循環模式都已具有. 但做爲特定的遊戲, 一般有本身的特色. 例如, 競速類遊戲與MMO網遊在遊戲循環的設計上就有很大的差異. 競速類遊戲對實時反饋的要求很高, 若是採用追趕模式, 則抽幀形成的體驗就會不好. 在掉幀方面, MMO網遊面臨的則是角色在場景中漫遊時, 其餘玩家的模型加載與位置同步形成的卡頓. 在這種狀況下, 可能會使用分幀加載, AOI(Area Of Interset)等處理方法來保障遊戲的流暢

[擴展問題]

　　1. 請嘗試分析多線程渲染的實現原理

在執行Render時，會在另一個專門的線程中進行。好處就是能夠利用多核的優點，減小了等待時間

　　2.2 時間記錄

請問在Unity 3D中常見的時間分爲哪幾類, 獲取和記錄它們的方法有哪些? 它們的適用場景分別是什麼?

[真實時間線]

真實時間線指的是, 以真實時間的流逝做爲標準,進行時間統計的時間線.從重要程度上講, 它表明着絕對的時間流逝, 是一切時間的參考,不一樣設備獲得的結果必定是相同的,這也是整個時間記錄的基石

Time.realtimeSinceStartup

View Code

[遊戲時間線]

遊戲時間線是應用更普遍的時間計量方式.它以遊戲世界的時間流逝速度做爲標準度量時間.不少狀況下,它與真實時間線不一樣.

[間隔時間]

間隔時間的計算方法爲計算兩幀之間的差時.

Time.timeScale
Time.deltaTime
Time.unscaledDeltaTime
Time.smoothDeltaTime

View Code

[擴展問題]

　　1. 如今有兩種狀況引發遊戲間隔時間變長: 一種是目標機器性能差, 須要追趕補償效果; 另外一種是斷點調試, 不但願影響邏輯. 請問有沒有辦法在設計時間線時, 過濾掉斷點調試的狀況

通常說來，目標機器卡頓與斷點調試的延遲不是一個數量級的，能夠經過時長的判斷，例如是否大於0.1s，來區分這兩種狀況

　　2.3 動畫事件

請簡述動畫事件的製做與邏輯處理方法, 若是有多種備選方案, 請對比它們的優劣

[問題分析]

所謂動畫事件, 指的是動畫進行到某個時刻觸發的事件

[基於動畫的事件]

編輯器裏編輯

[基於時間的事件]

另外一種常見的事件是邏輯型事件. 雖然它也與動畫的狀態緊密相關, 但這些事件種包含着邏輯處理. 例如, 角色在攻擊動做的過程種觸發傷害: 或者在攻擊出拳的動做過程當中向前移動,遇到敵人就中止移動. 這些事件與邏輯緊密相關, 不只取決於美術的表現效果,更多的是數值與邏輯的合理性

對於這種事件, 採用基於時間的動畫事件就更爲合理. 在製做事件時, 咱們記錄的是局部時間線的偏移值, 並將它以獨立文件的形式存儲. 在上一節中, 咱們知道遊戲會存在一條遊戲時間線. 當動做開始時, 咱們會將這些事件時間偏移量併入遊戲時間, 並在遊戲時間線的對應時間添加觸發事件的回調, 這樣事件觸發就徹底脫離了模型動畫

這樣作的另外一個優點是顯示與邏輯的分離. 在同屏多人的遊戲中, 有時會不播放角色動畫, 只產生技能觸發的需求. 在這種事件框架下, 就能夠只運行基於時間的事件而不去加載模型與動畫. 由於傷害觸發與計算不須要依賴於動畫, 因此一切邏輯均可以正常運行. 另外, 在有異步數據影響的場景中, 這種事件控制方法也有優點, 它能夠預先作好邏輯計算, 再對動畫作插值處理, 數據優先於動畫直接進行同步, 將網絡延遲對遊戲的影響降到最低

[擴展問題]

　　1. 在後期優化時發現同屏特效過多, 在處理基於動畫的特效事件時存在性能瓶頸, 請問該如何優化

對於這種狀況，製做流程能夠保持不變。但在播放特效時，調用統一的代碼接口，在接口函數中根據場景中的特效數量進行抉擇與控制

　　2.4 遊戲同步

請問在遊戲同步方面有哪些分類方式?幀同步與狀態同步有何優劣?

[遊戲模式]

根據遊戲中玩家之間的互動方式, 能夠將多人交互類型的遊戲大致上分爲兩個類別: MO與MMO. 這兩種典型的模式有着徹底不一樣的側重點和技術架構

多人在線遊戲(Multiplayer Online, MO) 指的是少許玩家彙集在一塊兒的競技遊戲, 它的側重點是實時對戰的戰鬥樂趣, 所以遊戲追求告訴的響應時間, 以及頻繁的交互操做. 相對應的, 遊戲時間一般在幾分鐘到幾十分鐘不等, 一般採用房間或副本的形式進行遊戲, 玩家數量控制在20人之內. 常見的類型爲 ARPG, FPS, 格鬥, RTS, 競速等

大型多人在線遊戲(Massively Multiplayer Online, MMO) 則是指望大量玩家進行長期的社交性遊戲.它追求的是一種在虛擬社區中的存在感, 所以遊戲週期一般幾個月以上.因爲要處理大量的玩家數據, 不免會犧牲響應時間, 所以在MMO遊戲中, 一般不會有高速的交互.爲了能長期運行, 系統的穩定性與可維護性也是框架的重中之重

MO與MMO在遊戲內容上有很大差異, 所需的技術也大相徑庭, 但一個遊戲重同時存在兩種模式並不衝突. 常見的作法是, 將MO類型的遊戲以副本的形式嵌到MMO中, 並分別採用獨立架構對遊戲邏輯提供支持. 這樣就能夠兼顧MMO的玩法多樣性與MO對戰的樂趣性. 在WoW中, 野外戰鬥與大部分副本都是以MMO架構實現的,而少數在短期內須要玩家緊密配合, 歷盡艱難才能通關的副本則是經過響應更快的MO架構實現的

[通訊方式]

　　1. C/S架構

從通訊結構上看, 同步能夠分爲C/S與P2P兩種. C/S是Client/Server的縮寫,指的是客戶端與服務器鏈接的消息傳遞方式. 在這種框架下, 全部消息都經過服務器轉發.它的遊戲在於能夠很好地控制非法行爲. 服務器知道一切數據, 一般也會對數據進行模擬計算, 所以, 做弊行爲很難出現, 另外一方面客戶端也能夠只作表現, 徹底由服務器的數據驅動. 這種方式經常使用在不須要, 或不多須要預表現的遊戲中

這種結構的最主要弊端是網絡延遲較大, 一般會控制在200ms如下. 另外一方面, 中央服務器上大量的運算也會增長服務器的設備成本. 在商業項目上線以前,一般會進行壓力測試, 主要關注點在帶寬, 鏈接數, 響應速度等. 經過模擬大量玩家的操做, 來測試服務器硬件是否可以應付預期數量的玩家

　　2. P2P架構

與C/S架構不一樣, P2P架構是兩個客戶端之間直接鏈接. 它與C/S結構的優劣正好徹底倒置, 它有低延遲的優勢, 也能夠節省大量的服務器運算, 卻很難避免做弊的行爲. 例如, DOTA中的全圖外掛沒法禁掉, 根本緣由就是客戶端擁有其餘玩家的數據

[數據模式]

　　1. 全網狀數據模式

全網狀數據模式指的是, 每一個客戶端須要給網絡中的每一個設備廣播本身的數據. 所以每一個設備上有完整的數據, 各個終端之間傳遞的只是控制設備的輸入信息. 能夠預想到, 隨着網絡中終端數量的增長, 信息量會急劇增加. 因爲消息量大, 所以不一樣客戶端之間一般只會傳遞用戶輸入的信息, 這就須要保證每一個客戶端的初始數據與每次操做的運算結果必須徹底相同, 不然就會表現不一致

　　2. 星型數據模式

另外一種狀況是網絡中的成員並不平等, 全部終端都要依從中央終端的數據. 這個終端在C/S架構中被稱爲中央服務器, 在P2P架構中被稱爲主機, 這裏爲了方便說明, 暫稱爲服務器. 在標準的星型結構中, 服務器在收集完全部設備發送的數據以前, 一直處於等待狀態, 接收完成後再將數據廣播出去, 所以它是將輸入數據暫時集中到服務器上, 這一點與全網狀數據模式徹底不一樣.這種結構避免了終端過多致使的數據暴漲, 但也會引發數據傳輸速度的降低, 有利有弊, 須要根據本身項目的實際狀況作取捨

[同步方式]

　　1. 狀態同步

　　本節中提到的狀態同步和幀同步都是廣義上的, 雖然它們的底層實現均可以基於上面提到的模式, 但從廣義講, 它們的同步思路不一樣

　　狀態同步指的是將其餘玩家的狀態行爲同步, 例如, 怪物的AI控制, 角色技能釋放, 戰鬥傷害計算等等. 純粹的狀態同步模式下, 這些內容都由服務器運算, 只是將結果下發給客戶端, 客戶端根據獲得的數據驅動顯示而已. 這種模式的缺點是流量消耗比較大, 消耗的流量取決於場景中須要轉發數據的人數和內容. 另外, 先天的結構致使響應速度存在問題, 沒法作到高頻交互的流暢體驗. 最明顯的特色就是"拉扯"現象. 它表現爲某個角色會忽然出如今某個位置, 或某個技能效果忽然出現, 甚至角色突然死亡等. 引起這個現象的緣由是, 網絡波動致使數據未能及時送達, 而客戶端進行了某種程度的預表現或航位推測

　　對於大多數實時性要求不高, 交互簡單的遊戲, 通常會使用狀態同步. 一般來講, 常規MMO類型的遊戲只能使用狀態同步

　　2. 幀同步

幀同步是指客戶端只同步用戶的輸入指令, 例如, 向前走, 按下哪些技能等, 不一樣的客戶端各自計算本身的結果. 因爲消耗的流量只取決於指令數, 所以會大大減小消息. 另外因爲消息結構的緣由, 幀同步的速度要比狀態同步更快, 所以適用於一些高頻交互的遊戲

不過因爲每一個客戶端都要獨立計算, 所以須要保證計算結果的一致性. 理論上講, 相同的時機, 輸入相同的內容, 會獲得相同的結果. 不過從實際狀況看, 作到徹底相同仍是有些難度的. 以Unity 引擎爲例, 一方面, 各個腳本之間Start, Update等生命週期函數的調用順序不肯定: 另外一方面, 使用Physic物理系統也不保證是肯定性模擬. 好比一個單位的座標誤差了0.01致使技能未能命中目標, 那麼這個目標的血量判斷就會受到影響. 若是這個目標的行爲受到血量的影響, 那麼最終的結果會徹底不一樣. 所以讓每一個客戶端計算結果徹底相同不是一件容易的事, 一些常見的注意事項以下:

　　1. 不使用浮點數, 用整數代替　　

　　2. 不一樣客戶的同步頻率要保證一致

　　3. 隨機種子相同, 並自定義接口防止其餘公用系統干擾

　　4. 使用排序容器, 保證遍歷順序

　　5. 邏輯顯示分離

　　6. 使用補間過渡, 調整速率, 掩蓋卡頓

除了一致性的難點, 幀同步還須要解決流暢度的問題, 因爲經過網絡傳輸過來的數據必定會慢於本地, 而咱們又但願在相同的時刻輸入信息, 所以就會引起等待, 反映到用戶體驗就是不流暢

優化方法有不少, 例如, 在幀同步遊戲中, 因爲廣播的頻率很是高, 所以每次廣播的數據就要足夠小, 這樣能夠節省不少消息處理的時間. 對於消息, 能夠將須要全部客戶端同時發生的內容提早廣播給其餘用戶, 採用時鐘同步. 客戶端邏輯先行, 顯示經過平滑追趕的方式處理. 不少改進是體驗優化的範疇, 須要結合具體遊戲進行

在傳輸層, 移動端的同步建議使用UDP做爲傳輸協議. TCP爲了保證傳輸的可信性, 不少機制不太適合波動較大的移動網絡. 在弱網絡環境下, UDP的RTT幾乎不受影響, 而TCP的RTT波動比較大, 特別是在丟包重發時影響比較明顯. 雖然使用UDP會引入丟包,丟包的問題.但能夠經過冗餘的方式來解決這個問題. 好比每幀三個數據包, 其實是包含了過去兩幀的數據,也就是每次發三幀的數據來對抗丟包

[擴展問題]

　　1. 請問幀同步中的鎖幀(Lockstep)是指什麼?

鎖幀指的是若是未收到消息，就不該該繼續向下執行的同步模式，它是幀同步能同步執行的核心。但鎖幀會影響流暢性，所以一般會作些定製化的更改。

第3章輔助系統

　　3.1 有限狀態機

　　3.2 腳本系統

第4章資源分類

　　4.1 貼圖種類

　　4.2 材質效果

　　4.3 動畫分類

　　4.4 流動效果

第5章後處理效果