[程式] 再談編輯器
再談編輯器
打造編輯器對一個技術人來講是很傑出的成就。打造了一個編輯器，意思是可以讓企劃或
美術人員透過此編輯器來撰寫複雜的遊戲內容，達到快速開發遊戲內容的目的。
但這是事後諸葛，也就是編輯器的好處是從完成他之後開始。
我對於編輯器的態度一向都是：適度的執行，尤其是在完成了第一版的遊戲核心並確認沒
問題（不會再改）之後。
編輯器所需製作的成本大約等同於一個遊戲。因此在遊戲核心還沒確定（尤其是新系列新
類型的專案）之前，絕對不要輕易開始編輯器。那會完全消耗一個程式的人力。
通常（這裡的通常是百分之百），遊戲專案都是會延遲的。它延遲的原因一般來講不會是
因為沒有開發工具。通常是：做出來不好玩（所以要改），發現沒有預料到的素材製作，
素材製作時間過長。很少因為程式的關係導致延期，因為程式通常是火車頭，都會在團隊
的前面。
若遊戲核心還沒確定，要修改的可能性是相當之大，這時編輯器也可能會大幅修改。也就
是說編輯器還沒大量使用前，就被逼著修改。這件事情造成很大的影響，一項開發還沒測
試就改變規格，會帶來倍數的臭蟲。也就是說開發編輯器的時間＋除錯編輯器的時間會完
全卡住程式的人力，甚至會卡住使用編輯器人員的工作：因為編輯器還沒好，所以有藉口
可以等待。
從我的經驗，我都會訓練（恐嚇）企劃人員必須要有使用記事本（或Notepad++）就能改
參數與關卡的能力。沒道理程式人員在打死板板的程式碼，死命擔任火車頭的角色時，還
要分力出來幫企劃或美術開發工具，同時還要負責除錯，接受使用者的責難。
在專案的核心系統建立並確認不需要大改之後的量產確實需要編輯器（通常此時都已經到
了專案的結尾，如果沒有續作，也不需要另外再製作編輯器了）。此時由於遊戲核心已經
不需要大改（後面都是維護），這時才真正可以將原先製作遊戲核心的程式人力導入開始
製作編輯器。在這種情形下，第一版的核心所使用的參數檔與腳本一定是CSV，XML，JSON
，或其他可用記事本就能進行撰寫的格式。在編輯器設計時，當然需要預料到資料格式的
相容與轉換問題。
另外，Unreal/Unity這種In-Game Editor的導入改變了遊戲開發的生態，它們使用的是腳
本語言，還提供了大量不用寫程式（只需填值）就能修改遊戲內容的介面，這其實意味者
企劃與美術人員必須自己學著進入製程，自己為自己開發編輯器，自己為自己負責。（如
果沒有體悟到這一層的團隊，我認為導入Unity的時機也許太早）
最後，程式人員也許聽過TDD或是DDD的概念，這與我前面所說延遲開發編輯器的時機的論
述並不相衝突，因為透過簡單的參數文件檔也可以做到DDD，透過一個簡單的資料顯示工
具一樣可以做到TDD。若是需要一個華麗，可用滑鼠操作，還沒有臭蟲的編輯器才能證明
做到TDD與DDD，那就只是一種虛榮而已。
--
"May the Balance be with U"(願平衡與你同在)
視窗介面遊戲設計教學，討論，分享。歡迎來信。
視窗程式設計（Windows CLR Form）遊戲架構設計（Game Application Framework）
遊戲工具設計（Game App. Tool Design ）
電腦圖學架構及研究（Computer Graphics）
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 219.68.22.188
※ 編輯: NDark 來自: 219.68.22.188 (05/05 18:25)
推
05/05 21:27, , 1F
05/05 21:27, 1F
推
05/05 21:50, , 2F
05/05 21:50, 2F
→
05/06 00:44, , 3F
05/06 00:44, 3F
→
05/06 00:44, , 4F
05/06 00:44, 4F
推
05/07 00:03, , 5F
05/07 00:03, 5F
→
05/07 00:04, , 6F
05/07 00:04, 6F
→
05/07 00:05, , 7F
05/07 00:05, 7F
→
05/07 00:06, , 8F
05/07 00:06, 8F
討論串 (同標題文章)