再谈编辑器 打造编辑器对一个技术人来讲是很杰出的成就。打造了一个编辑器，意思是可以让企划或 美术人员透过此编辑器来撰写复杂的游戏内容，达到快速开发游戏内容的目的。 但这是事後诸葛，也就是编辑器的好处是从完成他之後开始。 我对於编辑器的态度一向都是：适度的执行，尤其是在完成了第一版的游戏核心并确认没 问题（不会再改）之後。 编辑器所需制作的成本大约等同於一个游戏。因此在游戏核心还没确定（尤其是新系列新 类型的专案）之前，绝对不要轻易开始编辑器。那会完全消耗一个程式的人力。 通常（这里的通常是百分之百），游戏专案都是会延迟的。它延迟的原因一般来讲不会是 因为没有开发工具。通常是：做出来不好玩（所以要改），发现没有预料到的素材制作， 素材制作时间过长。很少因为程式的关系导致延期，因为程式通常是火车头，都会在团队 的前面。 若游戏核心还没确定，要修改的可能性是相当之大，这时编辑器也可能会大幅修改。也就 是说编辑器还没大量使用前，就被逼着修改。这件事情造成很大的影响，一项开发还没测 试就改变规格，会带来倍数的臭虫。也就是说开发编辑器的时间＋除错编辑器的时间会完 全卡住程式的人力，甚至会卡住使用编辑器人员的工作：因为编辑器还没好，所以有藉口 可以等待。 从我的经验，我都会训练（恐吓）企划人员必须要有使用记事本（或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)