我們需要怎樣的遊戲編輯器

我當技術策劃（也叫TD）也有一陣子了，參與過一些大型專案，經手的業務型別和工作流也各種各樣。恰逢最近面臨一些變動，便整理一些工作心得。

從我個人視角看，目前TD的工作可以分成以下三類：

• 快速產出原型玩法
• 設計大型複雜系統
• 設計並維護工作流
  

第一點，快速產出原型玩法，其實不太算是TD的專職工作，而應該是每個策劃崗位都需要的基本技能，而且這裡面其實也沒什麼門道，至少熟練掌握商業引擎或者一些其他的原型工具，就不是什麼大問題。

關於第二點，大型複雜系統設計，會包括技能、AI、任務、關卡、對話、過場等等，是多數遊戲的主體內容，業務邏輯深度大，而且需求多變，每一項具體業務都牽扯很多細節，不便在此一一展開。

至於第三點，設計並維護工作流，和上一條其實是互為表裡的工作，TD需要基於對業務的理解，設計好一個製作流程中需要在什麼模組引入哪些工種，每個環節交付什麼內容，最後整合得到最終的產品。相比於具體的業務，編輯器作為一個話題就不那麼龐大，本文就圍繞編輯器展開好了。

1. Gameplay的編輯環境

根據以往的專案經驗，策劃需要使用到的編輯環境，兩隻手數得過來，無妨窮舉一遍。

1.1. 文字

文字是最基本、最直接、最自由的格式，而優秀的文字的編輯工具則非常普遍，如

• VSCode
• SublimeText
• Notepad++
  

文字最大的優勢，還是在於它一般是最終的資料格式。如果沒有加密或者壓縮，執行時讀取的配置檔案最終是文字，這表示用文字表示的內容是最接近執行時資料的，因此透過修改文字造成改動需要經過的步驟最少，修改起來效率最高。

直接編輯文字還有以下優勢：

• 是最容易比對與合併的格式，多人同時編輯沒有壓力
• 不依賴引擎，可以直接使用文字編輯器開啟，複製貼上撤銷，批次查詢與替換等基礎編輯功能健全
• 沒有圖形介面的渲染壓力，資料量很大也不會造成卡頓
• 沒有編輯介面的遮蔽，編輯者更接近資料的最終結果
• 可以自定義格式，從而自定義可讀性和資訊密度
  

實際上，文字編輯的優勢是如此明顯，以至於我一度暴言，一個大型專案的開發效率取決於有多少配置可以直接走文字。關於這個暴言面臨的實際挑戰，我們留到後文再聊。這裡先簡單列舉一下文字格式存在的缺陷：

• 非常容易出現格式錯誤，難以排查，因此必備良好的輔助工具，例如自動補全，格式校驗等
• 如果格式設計失當，容易導致資訊密度過低或者語境過高，難以閱讀
  

適合文字直接編輯的格式的內容有：

• 劇情臺本
• 自定義指令碼語言
• 有良好輔助工具的json，xml等配置檔案，這裡良好的輔助工具是必要前提
  

1.2. 引數皮膚

引數皮膚是一個把引數都平鋪開的皮膚，一般來說屬於引擎白給的功能，典型例子如：

• Unity的Inspector介面（尤其是在有了Odin外掛加持之後）
• Unreal的Details介面
  

引數皮膚能夠比較清晰地顯示出當前有哪些可配置項，以及每一項的具體資訊。一般來說引數皮膚都高度可擴充套件，可以很方便地實現下列功能：

• 最佳化排版，控制複合結構的摺疊和展開
• 在欄位數量大時提供搜尋功能
• 控制每一個欄位的型別、值域
• 提供互動邏輯友好的提示
• 根據合法性或相關性控制特定欄位的顯示或隱藏
• 在引擎內可以支援拖動互動
• 提供搜尋功能
  

在引數皮膚的輔助下，配置的條理性和安全性都可以得到相當大的提升。另外，引數皮膚的序列化也比較友好，所以相關的配置檔案很多時候可以不用開啟引擎就能編輯，在比對與合併的時候也比較好操作。

不過引數皮膚也有一些問題，例如：

• 在欄位數量大的時候導航困難
• 不方便檢視、比對較大量的資料
  

引數皮膚主要適合編輯能夠便捷地以樹形展開，且沒有複雜引用關係的資料結構，例如簡單的鍵值對映、列表與字典


1.3. 表格

表格是一個典型的根據鍵來索引值的結構，不過受到展示方式的限制，能夠直觀呈現出來的僅有二維表格。

表格的優勢在於：

• 可以非常直觀地透過單鍵或者雙鍵索引一個值，在巢狀使用的情況下具備非常強大的描述能力
• 便於批次預覽
• 有一套白給的工具集，如Excel和GoogleSheet，在繪製格式、資料篩選、公式計算、功能開發等方面都有非常強大的功能和可擴充套件性
  

然而表格的問題也有很多，例如：

• 要求配置的格式高度統一，對於存在多型的資料支援不友好，容易增加資料和操作的冗餘，例如
  

• 欄位A依賴欄位B的配置才生效時，對應的依賴關係很難在表中體現
• 一些極少數情況才使用的欄位在表格中需要佔一列
  

• 無法逐級展開，涉及到多層級結構時只能巢狀，不便於編輯陣列、字典欄位
• 在列多的時候導航困難
• 編輯器環境和編輯環境經常不夠隔離，即Excel本身是一個集格式、公式、匯出於一體的工具，難以比對與合併，導致表格原檔案在多人協作時比較不友好
• Excel原始檔的資料絕大多數情況不能直接使用，需要走一套匯出流程，迭代流程可能因此變得繁瑣
  

二維表最適合描述的是大量簡單的內容，用簡單的一維或者二維鍵值對映就可以完全描述的資料。一旦超出這個範疇，繼續使用表格就需要：

• 把多個層級的資料強制鋪在一張二維表中，造成配置欄位的冗餘
• 多張表巢狀使用，增加導航的難度
  

一旦上述配置方式在專案中開始蔓延，表格的編輯效率就會開始下降。


1.4. 時間軸

時間軸是用來精確地調整時機的工具，主要優勢在於能夠快速預覽一段時間中某個精確時刻的狀態，因此一般也需要配合一個視窗使用。

如果沿用Unity Timeline的術語，一個時間軸會包括多個Track，Track上面可以裝載Event和Clip；Event對應一個時刻，而Clip由起止時間標記出一個時間段，這些都是為了精確描述邏輯觸發的時間。

目前商業引擎一般都有較為成熟的時間軸工具，如Unreal的Sequence，Unity的Timeline，不過實際專案中依然會有大量需要自定義時間軸的需求。

時間軸的優勢

• 能夠直觀地看到某個事件的發生時間，以及不同事件的先後關係
  

時間軸容易遇到的問題

• 由於和表現強相關，因此比較容易涉及到邏輯和表現的協作部分，協作的需求比較大；然而一般時間軸編輯後儲存下來的資料格式相對複雜，比對與合併的工作略顯繁瑣，協作性不是特別好（在Unreal中可以靠合理設計巢狀規則解決）
  

適合時間軸工具編輯的業務

• 動作打擊，需要精確地配合角色動作調整攻擊判定、特效、音效以及一些邏輯區間（如無敵幀、霸體幀）的時機
• 過場動畫，需要快速地預覽攝像機、場景和角色之間的位置關係，調整運動的節奏
  

1.5. 曲線

時間軸工具的另一個版本是曲線編輯器。曲線主要描述的是兩個值的對映關係，並且將值的變化繪製出來。如果輸入值是時間的話， 那麼曲線就可以是時間軸上的一部分。

曲線主要適合難以精確定量地描述變化過程的時機，例如：

• 角色身上某些邏輯掛點的位置如何隨著動畫變化
• 相機的某些引數如何隨著角色運動變化
  

實際開發過程中，尤其是表現強相關的部分，我們很多時候是基於直觀在調整，這時的需求都是類似於：如果這裡再怎樣一點點就好了，這樣子的。用數值來擬合這樣的描述效率相當低，因此曲線工具可以較好地輔助解決這類問題。


1.6. 節點圖

近幾年來透過節點圖編寫邏輯的方式開始盛行。節點圖是由節點（Node）和連線（Link）組成的結構，其中節點和連線表示的含義可以各有不同。節點圖的特點如下：

優勢：

• 直觀，上手難度低
• 節點型別、引腳的型別、連線數量的約束都可嚴可寬，能夠適配各種不同的業務型別
• 可以透過巢狀實現更加複雜的邏輯
• 與編輯器深度結合後還可以執行斷點等操作，迭代效率高
  

劣勢：

• 資訊密度低，邏輯一旦複雜起來會變得極難維護
• 節點數量大了之後或許會面臨渲染效率的問題
• 涉及到編輯器到執行時資料的轉換
• 編輯節點圖的操作在物理上有些許不便，因為涉及到滑鼠和鍵盤操作的頻繁轉換
  

在設計得當的情況下，節點圖能夠提供符合直覺的編輯方式，只要搭配合適的事件和變數機制，可以大幅提高開發效率。下面介紹幾種不同的節點圖型別。

1.6.1. 流

流是一種用節點表示執行邏輯，連線表示資料流向和執行順序的節點圖，典型的流節點圖例如Unreal的藍圖和材質編輯器等。

流和其他的節點圖相比的特性如下：

• 節點型別自由，可以用於表示資料或者邏輯，也可以有流程控制節點，如Sequence和ForLoop
• 引腳數量與連線型別自由，允許連出網狀結構
• 可以用於表示資料輸入輸出關係或者執行順序
• 不擅長表示結構
  

典型的適合由流來編輯的內容包括：

• 涉及到資料流和執行流混編的複雜業務，例如關卡流程，技能流程，對話流程
• 函式，可複用的邏輯片段
  

1.6.2. 樹

樹是用節點表示邏輯或資料單元，連線表示從屬關係的一種特化的節點圖，典型的例子如Unreal的行為樹和狀態樹

樹相比於流有更強的結構性：

• 要求嚴格按照樹形結構展開，每一個子節點擁有唯一確定的父節點，且根節點只有一個，連線用於指示節點之間的父子關係
• 如果涉及到執行，會根據節點執行後的返回資訊決定接下來的導航方式（一般來說是成功和失敗）
  

需要指定執行時在樹中的導航方式，例如：

• 行為樹，顯式地使用Composite節點來指定一個父節點下的子節點以怎樣的規則執行，以及透過主動Interrupt或者Decorator型別節點來控制打斷
• UE狀態樹，隱式地規定了從父狀態進入和跳出子狀態的規則
  

基於以上特性，我們也可以找到適合用樹表述的業務特性

• 有逐級細化的特徵，支援多分支，末梢有多出口，例如對話樹
• 有統一的導航邏輯，例如AI的行為樹或者決策樹
  

1.6.3. 狀態機

狀態機是由節點表示狀態，連線表示跳轉關係的圖，典型的狀態機工具包括：

• Unity Animator
• Unreal Logic Driver外掛
  

狀態機圖有以下特性：

• 節點表示狀態，連線用於指示狀態之間的跳轉關係，由於每一個跳轉都有對應的圖形化的連線表示，因此建立、預覽、編輯一條跳轉都可以非常直觀
• 狀態之間互斥，如果需要狀態共存的話，需要多層並行的狀態機，不像流或者樹可以同時有多個節點在執行
  

因此狀態機的優勢也非常明顯：

• 適合表示多個互斥狀態之間以及之間的跳轉關係，尤其是在可以不增加狀態的情況下透過編輯跳轉來更細緻地定製多個狀態之間的流轉關係。例如，如果有狀態A和狀態B，狀態A有子狀態A1和A2，他們都可以跳轉到B，如果希望從A1到B觸發某邏輯，但A2到B不觸發，這樣的事情在狀態機裡可以簡單增加一條跳轉來表示，比其他的圖簡單直接得多
• 可以便捷地基於狀態來控制一些功能的生命週期，例如當一個單位進入擊飛狀態時，就關閉邊緣保護（即允許被從邊緣擊落）
  

適合使用狀態機的業務包括

• 互動物件，例如門、寶箱、有特定身份的NPC等
• AI狀態，一般來說遊戲AI最上層是由一些互斥的狀態表示的，如待機，搜尋，戰鬥，關卡指令等；還有一些更具體的行為狀態，例如一個在休息室休息->走到工作間工作->回到休息室休息這樣的簡單迴圈狀態
• 動畫狀態切換，如在UE動畫藍圖和UnityAnimator中的表示方式
  

1.7. 公式

公式是一類特化出來的配置型別，專門服務於數值運算。

公式比較少被作為單獨的編輯格式，主要有以下原因：

• 多數遊戲沒有太複雜的數值計算過程，多數數值配置是在公式中已經預留好的位置填入引數
• 簡單的公式往往可以由執行流直接拼湊而成，如UE藍圖提供的數學運算節點
• 一些現成工具提供的計算解決方案已經能夠滿足需求，例如Excel自帶的公式
  

但是，實際開發中，依賴比較複雜的數值計算的需求其實並不罕見，例如：

• Dota中死靈法的大招，敵方每損失1點生命值就額外受到X點傷害
• 金剷剷之戰S9比爾吉沃特羈絆的效果，將受到的傷害累計下來並且在一定時間後造成該累計傷害百分比的傷害
• 星穹鐵道角色刃的普攻，造成攻擊力百分比加上最大血量百分比的傷害
  

此外，在實際數值平衡操作中，僅僅調節數字是不夠的，往往需要修改到參與計算的因子。這時，如果有快速自定義整個計算過程的方式，對開發迭代效率可以有較大提升。


1.8. 視窗

視窗本身並不負責資料儲存，主要是預覽位置關係，同時也是便捷地編輯位置資訊的介面。

視窗可以作為輔助皮膚，配合各種需要視覺預覽的編輯環境使用，例如編輯時間軸（如對話），也可以作為編輯位置強相關的資訊的主要介面，如果關卡中物體的靜態位置，或者環境筆刷。

對於這類位置敏感的資訊，有視窗可預覽的編輯體驗會完勝無視窗。


典型的適合由視窗編輯的資訊包括：

• 關卡中物件的位置資訊和材質資訊（如用筆刷
• 角色身上特定掛點的位置資訊
  

2. 編輯器的使用

2.1. 編輯環境的巢狀

在理解了以上可用的編輯方式後，我們只要理解每一項業務的具體特性，做一些簡單的排列組合，就可以很方便地構建出任何一個複雜業務需要使用的編輯工具。

拿一個對話舉例：

• 在最上層是流或樹，表示選擇支和對應的跳轉關係，例如此處選A觸發分支對話，選B返回上一級，選C完成任務退出對話
• 流或樹內部可以維護一些變數，透過引數皮膚定義和編輯，管理一些分支走向，例如當角色智力大於16時會開啟特殊對話選項
• 流或樹中的執行節點可以是時間軸，表示一段順序播放的遊戲內對話，在時間軸上有角色和相機的軌道，記錄了每一個時刻角色的表情動作語音，以及相機機位，在玩家做出對應選擇時，播放時間軸。
  

再拿一個環境互動物舉例：

• 最上層是一個狀態機，表示了互動物可能有的狀態，以及狀態之間的可能的跳轉規則
• 狀態機的每一個狀態，以及每一個跳轉，都可以展開為一個或者多個流，流裡記錄的是進入該狀態或者該跳轉狀態時，需要執行的邏輯
• 流中可以巢狀時間軸，用於觸發動畫，或者表示在精確的時刻需要發生的事情；時間軸裡也透過事件再巢狀流，用於複用一些流的片段，執行一些較為複雜的邏輯。
• 透過視窗預覽和編輯物件、子物件位置，透過引數皮膚來編輯簡單的屬性，這些基本的需求就不再展開說了
  

（實際上，這基本可以理解為一個Unreal的Actor藍圖加上一個LogicDriver外掛，這也從側面說明了UE的原生工作流是相當優秀的）

2.2. 配置方式之間的相互轉換

另外，不同的配置方式之間不僅能夠互相巢狀，也是可以互相轉化的。

絕大多數的表格編輯器，最終匯出時會去掉公式和格式，變成僅有值的文字；絕大多數節點編輯器的最終的編輯產物也會被序列化成文字。不過相比於這種偏底層的序列化，更值得討論的是，在不破壞原有配置格式的特性並保證邏輯同構的前提下，配置方式之間的互相轉化，例如：

• UE5引入的StateTree，其實是用樹形結構表示的狀態機
• UE藍圖中可以寫數學函式，其實是用流表示的公式
• 曲線編輯器儲存的實際結果，等價於一個公式
  

可以看到，同樣的內容被用不同的配置格式描述，是很常見的事情。只要邏輯上同構，幾乎任何配置方式之間都可以互相轉化。這種可轉化性可以衍生出兩種不同的工具開發思路：

第一種，保證工具的統一性，將盡可能多的結構使用同一種配置方式來描述，這樣工具開發的工作量小，策劃需要掌握的工具集少，專案的穩定性高，但是無可避免地有很多資料無法用符合直覺的方式配置，在執行側會造成比較大的損耗，未來擴充套件時也會面臨更大負擔。

第二種，保證配置的便捷性，儘可能為每一項業務提供符合直觀的編輯方式，這樣工具開發的工作量大，策劃需要掌握的工具集多，在工作流正式運轉起來之後可以比較大地提升效率，但是前期需要投入比較大的工程開發成本，策劃也需要付出一定的學習成本。而且這裡的便捷其實並不意味著穩定性差，因為合適的工具會提供足夠好的查錯機制，減少格式錯誤，對策劃來說會比較友好。

在實際開發中，每個專案都是在這兩種思路之間做權衡。套用兩個簡單的判斷維度，一個是苦一苦開發還是苦一苦策劃的問題，另一個是維持短期的穩定高效還是長期的靈活可擴充套件。

行業早期的專案，整體上會更偏向工具的統一，因為當時的專案規模比較小，裡面的複雜內容也比較少，在表格工具足夠成熟的情況下，大量專案會統一使用Excel來搭建策劃的配置環境。Excel先天功能強大，不行的話還可以上VBA，對於一些小型專案基本夠用。因此很多策劃的工具技能也都圍繞著Excel展開。不過相應的問題是，當你手上有個錘子，就容易看什麼都是釘子。於是會衍生出大量的Excel配置的技能、對話、關卡等，其中不乏一些非常複雜的流程，需要依賴層層疊疊的巢狀來完成，變得難以維護。

另一個與此非常接近的思路，是我前面提到的，能走文字就走文字。常用的文字編輯器能提供比較方便的跨檔案導航，全域性搜尋和批次修改，儘管可能需要花較長時間來培養策劃學習專案的文字格式，但是一旦掌握之後效率便完全不輸Excel。

所以，如果簡單的工具鏈也完全能夠勝任，為什麼還要開發複雜的工具呢？一個東西，只要邏輯上同構，就可以用任何配置格式表示出來，那隻要策劃想清楚，用什麼配置格式不都一樣嗎？以及，在開始動手之前想清楚，難道不是策劃的本職工作嗎？

道理上是這樣，但是實際情況卻未必這麼理想。因為實際上很多策劃其實是想不清楚的，至少一開始很可能是還沒想清楚的。專案從來不會是完全想清楚怎麼做才開始的，所以開發需要花時間來理解需求，而策劃也需要花時間把需求想清楚。在此之上，做過研發的朋友都有一個廣泛的共識，其實想清楚才最花時間。

所以，提升發開發效率的關鍵路徑，在於如何幫助大家更快地想清楚，而這正是綜合性的工具集體現優勢的地方。

舉個例子，在手上只有表格工具的時候，想要從中抽象出來一個狀態機，並且人為地在這兩種格式之間翻譯，不會是一件十分輕鬆的事情，尤其是如果此時來了一個新人，讓他從0開始理解這一套配置結構，就會有相當高的成本。相比之下，面對一個已經有對應的圖形介面的狀態機，可以指著一個節點說這是一個狀態，指著一條連線說這是一個跳轉，就能夠比較輕鬆地建立起一套關於狀態機的直觀。而且，當狀態機的編輯器可以複用的時候，對應的執行時也是可以複用的，因此也不必每次根據策劃的需求重新抽象一個近似的功能。

當然，在工具集複雜，且支援互相巢狀的時候，執行時有可能造成一些效能問題，此時往往會觸到一些技術大佬的雷區。執行時效率，尤其在關係到後端時，確實是個不容忽視的問題，只是最佳化工作也需要計算價效比。最佳化的本質，是讓人多解決一些問題，從而讓機器少解決一些，其實是把執行的成本轉嫁到開發頭上。所以最後要算的賬，是為了節省執行時成本，額外增加了多少開發成本。尤其是，為了確保執行時效率而複雜化了開發的流程，增加了人員溝通上的損耗，影響了開發效率，是有可能更加得不償失的。更何況，規劃得當的話，過度複雜的巢狀本是可以避免的。

再說到配置格式的互相轉化問題。如果一個專案的工具集做得複雜了，使用的時候該如何判定哪些內容應用哪些格式配置呢？答案是小孩子才做選擇，大人全都要。UE的PropertyMatrix提供了一個非常優秀的範例。他本質上是一個表格工具，將不同物件的不同欄位平鋪在一張二維表裡，提供了相當大一部分表格編輯的體驗，例如能夠便捷地對比多個條目中同一個欄位的值，而編輯之後還是儲存在原本的檔案中。


所以，實際編輯的需求會來自各種不同的視角。如果工具集能夠服務於不同視角的編輯體驗，便有益於開發效率的提升。當然，每個專案都有自己的實際情況，這裡主要說的是大型團隊研發，並且上線之後會長線運營的專案，在工具集上多花一些功夫，從長遠來看一定是更具價效比的方式。

3. 編輯器的未來

聊到這裡，我們不妨進一步問，編輯器的本質的功能是什麼？

我給出的答案是這樣的，編輯器是一套把策劃腦內的設計，翻譯成遊戲可讀的資料（或者源資料）的翻譯工具。只是因為這部分資料要求特定的格式，而在編輯器的輔助下，產出符合格式的內容會更容易。

不過這個翻譯器能做的工作非常有限，因為他產出的內容僅僅能夠支援遊戲執行時的讀寫，還有大量的翻譯其實是靠人自身來完成的。例如，我用流編輯了一個技能，我需要在開發環境中有一個技能描述，同時專案裡還需要一個面向玩家的技能描述文案，這個文案會有不同的多語言版本。這三份資料實際上描述的是同一個東西，而開發者需要把他翻譯成三份不同格式的資料，存放在專案中的不同位置，如果有一個地方發生了修改，其他的地方也得相應修改。再舉一個例子，策劃會撰寫一個需求，程式相應地開發了一個功能，程式需要在程式碼中新增註釋，或者專案的知識庫中描述功能的實現，而策劃還需要維護一份配置檔案的使用手冊。這裡，我們也可以認為，需求+功能程式碼+配置檔案+使用手冊，最終共同描述了同一個東西，只是被從不同的角度和粒度翻譯了若干遍。

所以，我們是否可以期待一個翻譯工具，能夠在自然語言描述的需求，和符合格式的遊戲資料之間任意轉換，幫我們省去在不同格式中來回翻譯的時間？換一個更時髦的說法，我們能否期待一個擁有多模態能力的工具？到這裡，是不是就很自然地聯想到生成式AI了。現階段我們依然有充分的理由懷疑AI能否勝任第一創作者的工作，但是如果已經有一份符合設計要求也符合格式規範的內容，希望AI工具把它轉換成別的格式，這聽起來就不像一個那麼難以實現的事情。他不需要知道為什麼有A，但是他會知道A=B。換個柏拉圖主義的說法，我們的工具不需要理解什麼是理念，而只需要識別不同的形式可以表達相同的理念（插一句，柏拉圖哲學中理念一詞的希臘文是Eidos，其實也是古墓麗影早期開發商的名字）。

舉個例子，當我們要製作一段任務的時候，不免需要經過劇情大綱、臺本、對話與演出配置、任務配置等等環節，每一個環節要交付的內容和側重點都不盡相同，但其實他們背後的邏輯是很相近的。我是不是可以設想，在工具的合理輔助下，我只需要給其中的一部分足夠充分的描述，而其他的部分可以先由工具代勞做到一半甚至更高的完成度？

如果再激進一些，在傳統的工作流裡，資料流向都是單向的，如果下游遇到了問題，一般是反饋到上游修改。我們是否可以設想，這許許多多的中間環節的交付的成果，其實都依賴同一套整合性的描述，以至於即便我在下游直接修改，他也可以將改動直接同步到上游？這一設想乍一看有些離經叛道，畢竟從一般的認知上來說，保證工作流簡單穩定，而靈活協調的事情都交給人來處理，是更合理的思路。但是人類組織其實並不能夠保證永遠比程式更靈活，尤其是隨著規模的擴大，人類組織的效率折損遠大於程式。據此我們可以認為，面向未來的開發方式不是定製組織級別的流程以讓更多人協作，而是透過對工具的最佳化和人的培養，讓個人可以完成更多的工作。如果原本分屬上下游的工作被合併為一環，上下游之間即便有再複雜的互相影響，也成為了個人決策範圍內的事，省去了溝通與協作的損耗。這裡我們看到，提升個人效率和縮減組織規模帶來的效率提升是可以互相促進的。

那麼，如果技術進步的速度沒有那麼快，又該如何呢？如果在未來的一個產品周期（大約3-5年）依然還是由人類主導設計，技術作為生產的輔助手段的話，我們應該如何期待一個更好的，面向策劃的遊戲編輯環境？以下幾個點或許可供參考

• 更好的型別定義，以及對不同型別資料的更有效的區分。遊戲引擎會把美術用的資料型別分得乾乾淨淨，模型，材質，貼圖，動畫，燈光；而IDE會嚴格地幫助程式區分好每個不同的資料型別，而策劃配表的時候無論什麼型別的資料都是一個單元格，無論什麼型別的引用都是一個ID，出錯的機率自然會高很多。一般商業引擎的編輯器都提供了穩定的型別約束的控制元件，透過拖動和點選的操作來減少手誤，是非常值得借鑑的。
• 更好的導航。目前任何一款面向人類的產品幾乎都會提供基礎的導航功能，例如後退與前進。網頁瀏覽器可以，APP可以，IDE可以，但策劃的工作環境變化比較大，經常需要在多個不同型別的檔案，多個不同的視窗，甚至多個獨立的軟體中來回切換，在這些彼此獨立的環境中導航就成為了一個純粹消耗精力的事情。如果有一個一站式的入口，能夠透過簡單的切換子視窗的操作，完整瀏覽要編輯的全部內容，而對於外部引用的內容都能提供快捷的跳轉，那麼編輯者的心智負擔又可以降低許多。
• 儘可能短的驗證流程。每當完成編輯一個內容的時候，可以在儘可能短的時間內驗證這次編輯的效果。如果校驗和數值釋出花費的時間不能縮短，那就給一個能夠繞過校驗的途徑；如果每次啟動遊戲花費的時間不能縮短，那就提供一個能夠不重啟遊戲就看到修改生效的方式。人的注意力是一種非常稀缺的資源，一旦散了就很難找回來，千萬不能浪費在等待上。
• 儘可能簡單的檔案管理。一些編輯器工具，在編輯測基本做到了比較友好的互動，但是在編輯器UI背後，實際操作的內容可能非常複雜，導致策劃在提交的時候總是不確定哪些是自己有意的修改，哪些是自己無意動到的，或者編輯器的隱含規則操作到，實際上需要提交的。如果編輯器操作和實際修改的檔案之間的對映規則簡單直觀，那麼使用者也會花更少的時間甄選自己的實際的工作。
  

實際上，上述這些特性對於任意一款商業引擎而言都是互動體驗的及格線，因此對於一個熟悉引擎基礎功能的朋友，都會覺得拿原生功能做個Demo不是什麼困難的事情。然而遺憾的是，大家總覺得做Demo的方法未必能夠直接做專案，做專案總需要一些額外的條條框框，這些條條框框當然能夠提升專案的穩定性，但是如果沒有經過足夠好的修飾，它們也會對效率造成不必要的損害。那麼，為什麼不能像做Demo一樣做專案呢？明明不是那麼難以做到的事情，為什麼效率和穩定不能全都要呢？

最後再借題發揮一下。表面上看，編輯器和工作流的問題，處理的是每一項開發業務到對應的工具鏈的對映，是一個靜態的問題；但是實際上這更是一個如何理解人和組織的問題，是一個面向有發生與發展過程的動態的問題。

前面提到過，所有的想法都不是一蹴而就的。想清楚需要時間，傳達想法需要時間，執行想法也需要時間，而人和組織的都是有限的。編輯器和工作流透過提高個人的效率，可以在單位時間內做到更多的事情。更重要的是，效率提高意味著試錯成本降低，一些失敗的探索變得可以承擔，也不會過度挫傷團隊的信任和積極性。畢竟一個團隊最不容透支的是士氣。

此外，更高的效率意味著更多的試錯機會，更意味著一套在錯誤中學習和自我糾正的機制有存在的空間，以及旁逸斜出的想法有機會得到驗證與支援。做過遊戲設計的都知道，一個好結果，尤其是可持續的好結果，都不應該依靠某次靈光乍現，而是靠一個擁有可靠的反饋迴圈的系統，在一次一次迭代中漸進地產生的。工具的進步，實際上給了組織機會，來形成這樣的反饋迴圈的機制。

念在國內大多是在做長線運營的專案，除了關注專案是怎麼做出來的，也要關注他該怎麼繼續做下去。目前許多的大型專案，是透過建立流程，讓20個專業不同的人得以協作，然而這些人可能一進來就被困死在這個1/20的空間裡，而且充滿了互相損耗。而我們期望的更好的流程，是給這些大家各自發展的空間，比如漸漸地覆蓋5/20的工作，這樣組織的效率得到了提升，而對於尋求進步的人都可以得到個人的發展，而不是在重複的工作中變得麻木而失去熱情。

所有人類的創造，無論是具體的事物還是組織，都遵循著這樣一個過程。它起初只是一個想法，這個想法在不斷塑形，不斷向外傳播，不斷變得更加具體，從而能號召更多的人，在一遍一遍這樣的迴圈中，最終積累到足夠的讓自己誕生的力量。這個是個令人著迷的過程，像極了基督教裡說的道成肉身。如果我們依然相信人類的創造，那讓就我們尊重這個生長的過程，並給予聖子降臨的土壤，直到有一天，也許有一天，我們的創造再也不直接依賴人的思考。


來源：七八五十萬
原文：https://mp.weixin.qq.com/s/_G6RjgfHlpNmhWBHwhaTYg