作者﹔NDark 时间﹔201001 前言 事实上前言写得有点多，简而言之，这几篇文章写下一些我个人的经验。 但不见得是"正确的"。读者必须自己判断什麽是适合的，什麽是有用的。 这不是最佳解，不要把这些内容当作圭臬。 因为游戏设计的多样性，很难找到一套固定的公式可以一劳永逸。 往往只要平台一切换，以前作好的东西就要重新作。 你能留下来的是： 越来越好的设计概念，这几篇主要的内容； 除错技巧，这几篇不会提到； 以及电脑里的工具程式，这里指的是 Photoshop，转档，文字编辑等让你日常工作顺利的程式。 而非开发的编辑器。 这些都只是我的经验，一定曾经有人这样作。现在也一定有人作的比我更好。 已经在业界的朋友每间公司都有自己的解决方式。没有必要比出优劣高下。 这样可以work并不代表你的专案可以这样套。 软体工作常常必须小心不要有硬体厂的思维－东西有了兜起来就能用。 某笑话是这样的："(人家的)code都有啦，很简单吧！！" 别人有的东西移植到自己的专案时常常比自己开发一个相同功能的元件花更多时间。 EPIC的投影片也讲：如果一项设计造成你开发时间(周期)变长，那就是一个坏的设计。 优秀设计的元件通常不是极度方便就是极度不方便。 （很松到只是个小类别） （很紧到你完全抽不出来只好陷下去） 我着重的方向在游戏层。而非引擎层（图学）或平台（如XNA或iPhone）。 因此你不会看到讨论的内容造成什麽很炫的特殊画面。 我很了解图学人最喜欢的就是一个小设定产生画面变成很漂亮的特效。 但是我更注重的是这个设计是不是使用频繁，是不是减少其他开发周期的时间。 因此不会看到什麽跟平台有关的奇淫绝技。更不会在使用特定软体功力大进。 相反的。我所讨论的内容是你在各个平台开发时都能套用的大概念。 在每个游戏软体上都可以有帮助的设计。 学习与成长是持续的，我们会一直看到更好的设计，工具，或平台。 但并不代表旧的（已开发的）东西就必须全部都丢到垃圾筒。 某id强者曾说："如果要变强，就把code重写一遍"。从变强的角度来讲我同意。 但Joel也说过，开发一个专案，当发现设计不完美，切记千万不要把专案全删掉。 因为一重来，进度就又归零了，这时落後再多的对手都立即变成超前你。 两件事都正确，只是分别从技术者与专案开发者的角度来看事情。 专案是有延续性的，工具是有延续性的，同时支援旧与新的规格是同样重要。 有时候即使是删掉一个已经不用的函式都可能会造成未来的风险。 一个人写作时常常可以即兴地依据设计／功力进步而修改架构。 但是在多人同时配合的时候有些改进最好都经过其他人的思考与背书。 以及进而思考这个问题：这个改进是否这麽重要，值得放下其他工作。（优先度） 世界充满着不完美，能接受这些不完美也是一种雅量。 因此我总是认为，能work就是好code。 开发时程及内容简介 在继续之前，我必须先讲一下我近一年多在进行的东西－ Flash游戏Caravaneer（沙漠商旅）的移植（Clone），简称为沙漠商旅Ｃ。 自2008九月开始到2009十二月为止，利用每天下班後的一或二个小时进行。 周末可以进行比较多。但是偶尔会因为工作繁忙而中断。 （本段强调没有占用到本业工作时间） 前面三个月（2008/9~12）大概是进行核心类别的开发。这时都在win32 console上。 接着的日子是平台与系统的建立。绘图平台转换到windows form。 还有大部分时间花在开发编辑器，或是说熟悉介面开发的一些工具。 （譬如说.net的一些元件要怎麽用） 所以整个成果看起来并不丰硕（大部分进度是在开发＝看不到的地方） 最後的三个月大部分的编辑器都已经整理完毕，比较多时间在扩充游戏的事件。 撰写那些比较重要的部分。（因为看来是写不完了XD） 原先目标：希望一般状态下完成交易与商业的运作，再加上基本的战斗状态。 完成度： 一般状态下只填了三个城市的市场资料（很多商店还没开门，也买不到武器跟装备） 战斗状态下移动与电脑AI未完成（因此敌人只好呆呆的让你打死） 运输工具与动物连接的板车系统未完成。 碰撞系统是最低限度。 不过流程上都有准备了空间，届时要继续扩充都没问题。 因此我打算先回头来整理沙漠商旅Ｃ的心得。 另一个比较欠缺的部就是图形部分，人物都先用几何代替。 整体看来大概像是我曾说过"一个丑陋无比只有方块的游戏"。 不过皮相的部分本来就不是我所擅长且预定要进行的，这些後述。 为什麽我要移植 沙漠商旅(Caravaneer) 沙漠商旅游戏连结：http://freegame.com.tw/flash/slg/slg_p_057.htm 作者官网：http://www.d-mah.com/ 我的工作虽然与图学有关，但是大部分是新技术系统原型的建置， 开发常常没有延续性，原型开发出来之後就专案终结。 常常使用新的技术来作系统整合，成果虽然有突破， 但却没时间调整到好就被逼着进行其他的方向。 因此我自前年(2008)九月开始打算利用工作空闲对游戏设计再进行一些磨练， 利用一些以前的经验反覆修正我的想法。 主要专注在游戏层上，如下游戏分层架构图： __ ／　＼ ／游戏层＼ ／　引擎层　＼ ／　　图学层　　＼ ／　　　硬体层　　　＼ －－－－－－－－－－－ 以三大领域来论（美术，程式，企划） 我并不打算学美术，也不打算去设计一个新的游戏架构。 所以最後的方案想当然尔就是去抄一个现成有的游戏。 这样我就可以借用（剽窃）他的骨（设计）与皮（图像）。 我选择沙漠商旅的原因是 他麻雀虽小五脏俱全，有剧情－甚至还有隐藏分歧。 有经营（商业）－城市的物资与经济会因为现实而改变， 玩家买卖的东西也会反馈到市场价格中。 有战斗－各式武器及弹药。 有成长－可以培养主角的能力及雇用佣兵来作战。 因此正好可以让我尝试游戏层的概念。 另外则是他图像部分是平面（2D）的，我借用（偷）起来比较容易。 他是Flash游戏移植到视窗介面整个系统必须重新建立。 顺带一题，虽然我口口声声说借用，但其实我很愿意与原作者分享我的成果。 然而几次的发信似乎都没有回应，略感遗憾。 我仅能作到在游戏开始的时候注明这只是个实验性与研究性专案绝对不会侵害原作权益。 我透过沙漠商旅要进行的主要目标是尝试撰写一个"通用可扩充性的游戏层架构"。 这个架构套用到任何游戏应该都是没问题的。（反过来说是每个游戏设计上重叠的部分） 不只是游戏系统，而是包含整个开发的过程。 这几篇文章主要设定的读者群是那些Programmer(PG) a.写过第一个游戏，对於系统架构或是开发流程不甚满意。 b.有丰富的程式设计经验，却对於游戏设计很陌生。 c.目前使用一个不完全或简陋的游戏引擎，有需要撰写一些额外的元件架构。 难度由1至5大概在2。不会牵涉到程式技巧与函式库使用。 但有些流程用C++或其他语言的片段来说明。 在cook到"沙漠商旅Ｃ的游戏设计"的主题前，我想先讨论这个主题： "容易被遗忘的游戏设计模组"。 原因是比较有趣，对读者比较有用。 然後之後再谈我的沙漠商旅移植作品，避免开始就是自顾自的讲古，老王卖瓜。 容易被遗忘的游戏设计模组，依我的经验，列出了四项，分别是 1.FPS counter 2.Event Creating/Handling/Reporting 3.Resource/Stage Paragraphing 4.Update data by first time/change once/every frame 这几项并不是什麽了不起的设计概念， 甚至只要有点经验的开发者都会在开发时自然领悟到这些元件。 但就因为太不起眼了，所以入门到进阶的开发者常常会把优先度排到後面，以致遗忘。 遗忘这些元件对於原型的开发不会有什麽影响。 确实如同Gary所说"有些重要的重要的元件必须优先把他完成， 让整个游戏能跑起来，再去搞其他次要的部分。" 但是它对於游戏的完成度或是扩充性却是相当重要的一环。 好像少了它，牛肉面只有牛肉跟面一样，就是差人一截。（好饿） -- "May the Balance be with U"(愿平衡与你同在) 视窗介面游戏设计教学( http://0rz.tw/V28It )，讨论，分享。欢迎来信。 视窗程式设计（Windows CLR Form）游戏架构设计（Game Application Framework） 游戏工具设计（Game App. Tool Design ） 电脑图学架构及研究（Computer Graphics）论文代读(含投影片制作) --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 140.96.77.176 ※ 编辑: NDark 来自: 140.96.77.176 (01/25 10:38)