原文刊载於独立游戏开发者分享会 blog: http://blog.igdshare.org/?p=225 == * How to program independent games 原网址：http://the-witness.net/news/?p=1004 Braid 作者 Jonathan Blow 日前在他目前正在开发中的 The Witness 开发 部落格上，发表了一篇他在今年四月份回 UC Berkeley 对他的学弟妹们演讲 的内容。演讲的核心议题在「如何有效率地进行游戏程式开发」，特别是针 对独立游戏相关的开发。原网址上可下载 audio track 与 slide，但是 Jon 在 comments 中提到不知为何影片不见了 … XD 所以 Q&A 时段有一个 The Witness 的 preview 很可惜大家只能用「听」的 XD .. 下面我针对 talk 内容做一个翻译与整理，但是在进入正题之前，有些前题 希望大家先了解，不然可能会觉得「他为什麽要讲这些」。 1.整个演讲内容是 Jon 长年累积经验归纳的心得，里面也有些许举例，但是 这些举例也有其时空背景环境，请不要太过着重於他所举的例子字面上的 意义。（或是可以怪我整理的不通顺 :~） 2.Jon 演讲的对象是一群 UC Berkeley 的 Computer Science 学生，这些学生 的性质、经验、能力导向也许与你、我不同。而 Jon 真正的目的是要让学生 了解「学术」与「生产/开发」间明确的差异。 3.这场 talk 真的非常、非常 focus 在「独立游戏开发」，简单的说就是通常 只有一个人写程式的状态。 ※　※　※ 我粗略将演讲内容分为以下几大段落： 1.个人开发经验与背景交待。 2.关於程式效率最佳化 … 3.关於使用资料结构 … 4.到底要最佳化什麽？ 5.关於泛用化程式设计 … 6.总结：对於独立游戏开发来说，什麽叫「好的程式设计师」？ 7.Q&A (包括部份原网址文章回应的整理) ※　※　※ Jonathan Blow 本人从事游戏程式开发长达 16 年，在这段时间中，实战经验的 累积让他对程式设计的「美学」定义产生不少改变，而很多都与他当年念 Computer Science 时所认知的、老师所教导的，甚至一般程式开发上普遍认同 的习惯或常识相悖离。 他在一开始先提到 Braid 当初开发的一些背景。Braid 从 2005 年开发到 2008 年上市历时三年半，程式由一人撰写，最後总共包括了 221 个 C++ source，238 个 C++ header，3 个 C source，20 个 HLSL source，约 12k 行的注解与 90k 行的程式码，其中大约有 75k 行是完全新写的，没有使用任何「协助产生程式码」 的工具。The Witness 离目标发行时间可能还有将近一年，它的程式码量也已经 超过了 Braid 一些（但没有到两倍就是了），虽然有其他程式员帮忙，不过好像 也只有一个人。另外，考量到很多程式会不断反复修正，实际上当然是写了更多 东西（只是後来删掉了）。 虽然单纯看这些数字很难表达什麽很切实的东西，但不论从何种角度来说，这样 的程式大概已经远远超过一个 Computer Science 学生在学时期，或刚毕业的时 候会碰到的规模。而 Jon 指出，统计调查的结果，程式员产量如果用秤斤两的 方式来算的话，每年每人约是 3250 行（虽然我不知道这个 study 资料哪来的， 另外容易 google 到的叙述是程式员平均一天写十行程式），当然我想这是指「 有留下来的程式」。然而粗略的概算，也知道用这种速度来开发如同 Braid 一 样规模的游戏程式的话，十几年也写不完。 就算完全不管品质的疯狂乱写，但也总要到「一定的堪用程度」，不可能无止境 地用品质换速度；再考量 Braid 当初是在 Xbox Live Arcade 上推出的作品， Jon 也描述了在 Xbox 360 上开发作品一般人不太会知道的困难处： 1. 512 MB RAM 而且不能全用；它的 3 核 CPU 是 in-order 架构的； File System 因为安全性设计，速度也不快。 2.游戏审核 fps drop 容忍范围很小；不能有 crash，读取时间也设限。 3."Soak Test"，游戏要跑满整整 3 天（以 60fps 换算成 frame 数的话要跑 超过 15M 幅），简单说你每个 frame 有 4 Bytes 的 memory leak 的话就 绝对无法通过游戏审核。 简单说，能通过审核程序的游戏程式几乎肯定是要有相当品质的。 但别忘了，身为独立游戏开发者，游戏设计、关卡设计、美术协调、 音效音乐协调、商业营运、行销推广、财务管理没有一项是可以漏掉不做的！ 「必须以极端的效率来完成事情」是最困难的挑战。 ※　※　※ 第一个关於「程式效率最佳化」的议题，当然其实讲的是老生常谈了，不过 不晓得有多少人在还在学生时期就有老师教过「未成年就这麽优是万恶根源」， 所以我想在此还是重复提醒一下大家 Jon 是在对一群还没毕业的学生讲话。 我们也常听过 80/20 法则被套用在这里：八成的程式与最後的效率影响几乎 微乎其微，剩下两成的程式则会影响八成的效率。Jon 提到的比例更极端些， Braid 中 90k 行的程式大约只有 6k 行是 performance-sensitive 的。 所以不要去想「这边怎麽写跑起来会比较快」，平铺直叙地写过去就好，否则 相当容易造成真正时间上的浪费。对於 Computer Science 出身的学生，也许 不去做最佳化可能是很违反直觉的，但是要学会尽量克制。另一点是，针对效 率最佳化的程式通常都比较难修改，或比较不直觉，若未来程式需要修改时， 往往会造成麻烦。 ※　※　※ 延续第一个议题，学生在学校通常也被教导各种「资料结构」的使用时机， 他的存取时间复杂度等等问题。Jon 说，这就已经隐含了「最佳化」的意义在 里面，而我们从前面知道最佳化通常是不好的， 所以，使用「正确」的资料结构通常是不好的。 不过我个人猜想这应该是在需要自行土炮资料结构的情况下，才会有这个 concern。譬如说确实看过不少例子是虽然用 C++ 写引擎，但是在资料结构 上都舍 STL 的不用，不过这已经超过本篇范畴，就先不谈了。 Jon 在这段举的例子是，他以前曾跑到 DOOM 的 mailing list 上说 DOOM 的场景资源管理的程式写得不好，那一段程式在应该可以用 hash 或 b-tree based 资料结构的地方居然用 array，结果和 John Romero 互呛了起来 XD 他事後回想，确实在这边使用了比较高级的资料结构的话，只是花了更多时间写、 要花更长时间 compile、然後程式执行时会吃掉更多记忆体，不过实际上根本 对效率没有多大的影响，因为这个片段并不是整体程式执行效率的主导因素。 Jon 也对学生提了一个观念，就是当看到被公认为「高手」的人做了一些 你觉得（技术上）「见面不如闻名」的事的时候，不妨多想想，也许你没抓到 重点或没看到整体成果；况且，若对方有实绩而自己没有，似乎也该谦逊一点， 毕竟很多临场智慧，是没实际走过一趟不知道的。 Jon 说他现在几乎所有资料结构都是单纯的 arrays of structs (in C/C++)。 ※　※　※ 开头两段其实主要都是在讲与 optimization 有关的议题，那到底有没有该 最佳化的东西呢？ Jon 提出，比起最佳化程式执行的时间与耗用的记忆体空间，真的该最佳化的 是「你在每个程式实作上所耗用的生命」，这才是真正有效益的最佳化考量。 资料结构与复杂的演算法没办法最佳化你所耗费的生命，花时间在这些东西 上面只会把更重要的事务（确实把东西做完）边缘化而已；除非，你确定 非这麽做不可，或是确定这麽做的效益非常非常明显。 提到效益问题，Jon 很排斥一些实际上根本只是为了发表而发表的应用计算机 科学（Applied Computer Science）的相关论文，他说几乎所有这类论文都是 不好的，往往提出了一个虽然有少许效益，但过度复杂的方法，无法被广泛 应用而且统计数字只挑好听的来讲。 ※　※　※ 再来提到泛用（generalized）程式设计，他认为「通常」泛用化的实作最终 导致的结果会比几个针对性、写死的实作要来得差。譬如说未考量过到底真的 有需求的是哪些功能/可能性，往往做出来的泛用性会包含了很多到最後也 用不上的功能，中间掺杂了多余的抽象层（abstraction），而且每当系统 需求产生改变的时候，这样的泛用设计反而比写死的还难更动。他认为泛用 系统的另一个缺点是，实际上真正的操作反而变得不明显了。（讲到这有点 Linus Torvalds 的感觉… ） 在 Q&A 时 Jon 有提到，当然也有许多状况下，泛用程式很明显是优於各别 写死的系统，比起「不要太早最佳化」这点来说，泛用系统到底何时该用、 何时不该用是一个比较难以明确界定的问题，他认为除了多写多做、经验累积 之外没有什麽直接的方法。 另外对於在既有程式上添加/撰写新系统也必需格外小心，该考量的是如何 删除程式码而能不影响任何程式功能，而非增加程式的复杂度；若把整个程式 中的每个模组、类别、物件、函数等等当成一个节点，然後整个程式就是把 节点连起来所组成的一张图（这里指 graph，不是 image）来看的话，每多 一个节点也代表整张图的连线复杂度，会以至少线性，至多平方关系的速率 成长，也更易造成藕合。这也是《人月神话》（the Mythical Man-Month） 中所提到当程式专案变大时它是如何越来越变得难以控制。 其实这对有一点程式开发经验的人不难理解，而且应该也都听过类似说法； 不过 Jon 在此提到的例子是，有时候我们会倾向为了让每一个 function/ method 内容看起来尽量简洁，所以常常为此重构（refactor）程式码，抽出 一些看起来让 function 内容变乱的东西，把它整理成另一个 function， 所以我们可能会把一个很长的 function 抽成好几段，变成好几个不同的小 function。但是 Jon 说，他宁可让那个很长的 function 就长那个样子， 如果这整段程式确实只做一件事而且只出现在这里的话。 因为他不希望原本一目了然的操作，变成把实际操作的内容隐藏到其他地方去， 就算那段程式可能长达一千行，那就一千行又如何呢？ （注：举例用的程式片段在 Jon 的演讲投影片第 28 页， 我这边就不额外贴 code 了。） ※　※　※ 所以到底对独立游戏开发来说，怎样叫做一个好的程式员？ 迅速、脚踏实地、会确实把事情做完，对於各种进阶的程式技术与知识有广泛 的了解，但是只在这些技术真的非常非常有帮助时才去用它们。Jon 觉得当然 各种程式设计的进阶议题是一定要知道的，这确实是基础，不过这不代表 「有机会就该用上」；当人们学到一个新东西的时候，往往看到的只有这个 新东西的好处，但是好处背後所隐含的一些不利因素，却很难在当下就马上 有办法衡量，而经验上来说通常坏处都会大过好处。程式技术、软体开发的 方法、名词琳琅满目，从「知道」到「真的了解」是漫长的过程，而且常常 使人犯下「明知故犯」、「知行不一」的毛病。 ※　※　※ 後面 Q&A 有部份是针对 Braid 或 Jon 本人提的问题，和前面整篇文章的 主旨关联不大，整理起来不太顺，包括有人问它 Humble Indie Bundle 和 Steam 比较的话哪个通路卖得比较好，或是 Braid 的一些设计理念，觉得 DLC 重不重要之类的。所以对於这几点有兴趣的话可以自行稍微听一下演讲 录音档後半段 Q&A。 Q&A 中 Jon 有提到的几个重点： 把握「现在够好就好了」的原则很重要，不过，确实永远都有某些片段你 到最後非最佳化不可，譬如说对於 Braid 的话，就是「时间倒转」系统的设计。 印象没错的话 Jon 在 2010 年的 GDC 有讲这个主题，我有机会会把这个主题 略作研读并写写笔记。 有人提问 Braid 会不会 open source，Jon 的回答是「也许」。不过他觉得 现在网路上资源这麽多，而且开发的时空环境背景不同，就算释出 Braid 的 source code 其实对大家没有什麽帮助，除非有人想做和 Braid 几乎一模 一样的游戏；而且他又还找不到时间做这些额外的工作。 Jon 对 C++ 的看法是，业界很多人使用 C++ 是因为逼不得已，也有人问那 C# 与 XNA 呢？Jon 说就他了解绝大多数 XBLA 游戏仍主要靠 C++ 来写， 因为审核规定实在太严格，C# 与 XNA 主要都被用在 XBLIG，这些是没有技术 审查的（他在此没就现在的 PC Game 或其他 Mobile Game 部份做太多描述， 在原网址回应中他也说他并不熟悉 Unity 之类的技术，他只说不对 Unity 做大改写的话，大概也做不出 The Witness，原因我就不推敲了 :p）。 他和他认识的很多朋友其实只把 C++ 当成「可以在 struct 里面放 function 的 C」；而 C++0x 他更是觉得太疯狂了，虽然有少数功能确实是大家希望的 改变。他提到很多语言本身拥有的功能、程式设计的技巧、程式架构上的准则， 其实都是为了多人合作而存在的。如果你今天就是一个人写程式，或最多两、 三个人，那些功能、技巧、架构其实都是多余的，特别 indie game 的重点是 如何用少数人在相对短的时间内完成一个中～大型的专案。 Jon 在此讲了一句话，我引用原句： "Optimize the game development process to produce the highest quality game in a reasonable amount of time" 当然 quality 和 reasonable 这两个字眼在缺乏背景设定的情况下，是很 模糊的，但至少我们可以确定 the highest quality game 当然不等同於 the highest quality program（此指我们通常认知的「程式设计」）。 不要过早最佳化、不要过度设计、不要过度blahblah，这些字眼听在一般 写程式的人耳里是理所当然的，因为字眼上本来就存在「过度」两个字， 所以甚至连不写程式的人都知道这不好。但是在整个 talk 中 Jon 很明显 是认为，对於 Computer Science 出身的学生，这些台词必需要反复强调。 Jon 也指出他不论在 Braid 或 The Witness 中，没用过超过三层的继承树； 只在 Array 上使用 C++ Template（前面也提到他几乎只用 arrays of structs 来当资料结构）。 另外，Jon 提到在 Braid 之前他也是有不少不怎麽成功的开发过程，而归纳 起来当初设定的目标很多都是错的，或规模与技术难度太高的，譬如说用电脑 视觉的技术想衍生出一个好玩的游戏，结果最後却卡在处理技术问题上； 也有制作过不少 3D 的游戏，但是同样很容易搞得太复杂而超过一己之力 能掌握的范围。Braid 之所以成功是因为它有办法在一个大家已经非常熟悉 的系统上，传递一个很不一样的意念；而且光是操纵时间的系统在技术上就 够复杂了，其他「载体」应该越是简单越好。（Jon 也强调他不是 Mario 迷， 只是单纯向 platformer 上最成功的作品表达敬意） ※　※　※ 有个学生提问了很重要的问题，而且这和後来在原网址回应的一些内容有关， 故一并整理在最後。 该学生问：「那为什麽现在学校都这样在教程式设计？」 Jon 的回答是， 第一，当然学校教的 Computer Science / Programming 基础是必备的， 但是要不要用，或用得有没有真得有效是另一回事，不过若没学过，也不可能 去比较到底怎样比较有效； 第二，学校本来就不是在教「Production」的，「专科学校」与「大学院」 的导向本来就是不同的（虽然目前遇到的状况是产学断层日益严重，而且专科 学校与大学院的界定也越来越模糊，美国教育体系同样面临这个问题）； 第三，其实学校教的和 Jon 所讲的内容并不真的冲突，这是两个层次的事情： 先学会规则，然後懂得忘掉规则（※）。只是学校往往连教完第一个层次都很 勉强，遑论去教那种需要经验累积才能归纳出来的结论。 在原网址回应的讨论中，看得出来蛮多也是学生去发问的，譬如说「哪间学校 比较好」、「这系这样排课程对不对」，看了 Jon 的一些说明，原来美国也是 很多一窝蜂的「我也有」学校，开很多 Game Design、Digital Media、blah blah 科系。比照台湾现况，好像有稍许宽心的感觉 XD？Jon 认为只有极其 少数的学校值得推荐，保险起见还是从 Computer Science 或 Classical Art 等方面切入较好；游戏的话可以自己找课余时间做。 （FYI，Jonathan Blow 在 UC Berkeley 是双主修 Computer Science 和英文 文学，不过据说没毕业） 更详细的讨论可以定期回原网址查看。 ※　※　※ 最後还是再把警告标语拿出来念一下 :p 1.整个演讲内容是 Jon 长年累积经验归纳的心得，里面也有些许举例，但是 这些举例也有其时空背景环境，请不要太过着重於他所举的例子字面上的意义。 （或是可以怪我整理的不通顺 :~） 2.Jon 演讲的对象是一群 UC Berkeley 的 Computer Science 学生，这些学生 的性质、经验、能力导向也许与你、我不同。而 Jon 真正的目的是要让学生 了解「学术」与「生产/开发」间明确的差异。 3.这场 talk 真的非常、非常 focus 在「独立游戏开发」，简单的说就是通常 只有一个人写程式的状态。 如果您有亲自去听完演讲录音而与我解读有些不同的话，欢迎提出讨论，感谢！ （※）well，「先学会规则，然後懂得忘掉规则」这个解读算是我浓缩原句自己掰 出来的，因为听到 Jon 在 Q&A 那段谈话，我不得不想起大学时某教授讲的话， 虽然他实际上的作为是「大家连半套规则都还学不懂（因为他也不会教）， 就要大家忘掉规则」。 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 203.72.57.78 ※ 编辑: linjack 来自: 203.72.57.78 (06/27 16:00) ※ 编辑: linjack 来自: 203.72.57.78 (06/27 17:24)