浅谈游戏程序设计入门

 无论是学习何种 API ，一开始免不了都是需要熟记很多很多的函式名称、呼叫方式、传入参数等等繁复的东西。然后还需要把整个绘图 API 的程式设计流程架构，从头到尾的彻底了解；在学习 API 时很重要的一件事，就是要用心去思考绘图 API 设计者的想法，尽可能的掌握住这个绘图 API 的「设计思维」，以其思维模式来学习。如果能够掌握住了这个重点，则我相信不管是在学习绘图 API 的理论，或什至是记忆函式的名称等等，都会变成是很自然而然的容易理解。记得试着多问自己「 why 」与「 why not 」。

 

 

 

学习，应该是一种主动性的思考，而非仅止于被动性的知识填充而已。

 

 

 

当你确定自己已经建立起正确的观念与思维模式时，就该开始来写写小程式啰。 对于初学者来说，从无到有，往往是最难跨出的一步；如果想自己从零开始，一行行的撰写程式码，可能到最后才发现辛苦的结果，全部变成不解的程式 bug 。 如果觉得自己可能还没办法，独立完整的完成一个程式，那么比较好的方法就是：先参考别人的程式码。无论是 DXG 或 OGL ，在各种书籍与网站中，都有为数不少的范例程式存在。藉由 trace 一个范例的完整程式码，可以因此而学到很好的程式写作方式。如果已经把整个范例的程式码都了解的差不多了，或者还有疑惑不明白之处，可以试着改变程式中的一些变数或函式呼叫，看看程式的结果会有什么变化，这也是一种很不错的学习方式。

 

 

 

学习 Graphics API 最重要的是什么？ 熟记函式和参数？ 搞懂整个理论架构？ 

 

 

 

都不是。最重要的是：动手做。如果所谓的学习，只是脑袋里记了一大堆不知所以然的东西，而很少真正动脑去想、动手去做，那么所有的一切，可以说都是白费功夫。没有实际踏实的程式写作经验，几个月后，记忆里只会剩下一堆不连续的残片碎影罢了。很多写程式时要注意的小地方或小技巧，我们称之为 tip 或 trick ；一般的书籍或网站多只提供概略性的教学，对于实做上细节的一些小技巧，就需要自己亲身经历过，才能真正体会到的。简而言之，就像是一种经验值的累积啰；现在很辛苦的练等级，到了真正要面临大阵仗、大魔王的时候，才不会临场怯阵、纰漏百出。

 

 

 

 如果对整个 API 已经有了相当程度的了解，加上时间经验的累积之后，就可以开始动脑想一些有趣的点子来做啰。有三角形、有灯光、有材质，可以做些什么？ 让灯光的颜色随着时间变化如何？ 还是改变材质的座标让物体外表有变化？还有透明度也可以做很多变化！工具在你手上，创意在你脑中；魔法人人会变，巧妙却各有不同。之前经历过这么长的学习曲线，一路筚路蓝缕、披荆斩棘的到了这里，终于是可以自由挥洒的时候了，快把自己脑中存积已久的所有点子都压榨出来吧！ : ) : )

 

 

 

        嗯？有什么地方不对劲吗？

 

 

 

随着自己写的小程式数目一直累积下来，或许你已经发觉到一件事实：「其实根本不用每次都从零到有的一行行程式码撰写，对吧？」没错，一般来说都会存在有一部份的程式码是重复的、不变的；例如：视窗程式的初始化、绘图 API 一定会做的初始化之类的动作。 那应该怎么做比较好？需要的时候再从之前的程式 “copy-paste” ？ 不，这绝对是既没有效率又存有风险的方法。 什么是最好的做法？ 最好的做法，就是把每次都会重复使用的程式码，写成一个骨干架构 (framework) 。所谓骨干架构部分，通常是一个程式中变异性很小的程式码；例如视窗程式的繁复初始化动作，动辄数百行程式码以上，但却有很大的固定性，所以就非常适合写成骨干架构。如果我们把骨干部分的程式码，独立在一个 source file 中，而把真正相关绘图部分的程式码抽离出来到另一个 source file 中；把所有不相关的闲杂人等，写成一个 source file 一次解决，从此不需要再烦恼那些不相关的东西，只要我们把主要绘图部分的程式码撰写完成后，再和以前就写好的骨干程式做编译连结，就可以让专案 (project) 的整体架构看起来更清楚易懂，也大幅增加了专案的结构性。

 

 

除了最基本的 framework 之外，还觉得需要什么吗？

 

 

没错，你需要自己的图书馆 (library) 。什么是 library ？让我举个例子来说明：如果你所学习的 API 是 OpenGL ，你可能会发现，不管是 BMP 、 TGA 或 JPG 等等所有的图档格式，都需要自己撰写程式码来读取。OK ，那就写吧。The same as old ，你会发现到，无论所需读取的是哪一种格式的图档，我们的目的都是很相近类似的：就是做为多边型的材质 (texture) 。那我们何不以 C ＋＋的物件导向模式，写出一个专门处理相关 texture 大大小小事务的类别呢？把读取每一种图档的 function 写在 texture class 的成员函式中，并且一样的把它独立成一个 source file ；如此一来，只要每当需要处理 texture 相关程式时，就把已经写好的 texture source file 和我们的专案做编译连结，够简单又结构化，看起来很棒吧？

 

 

 

同理可证，除了处理 texture 的类别外，还有文字的输出呢？计时器的控制呢？ 键盘滑鼠的操纵？……… 别忘了还有最基本的矩阵和向量！ 把所有你能想到的基本功能，都寫成一個個的獨立 source file ，只在需要的時候才和它編譯連結；如此不但程式碼易於維護除錯，未來的擴展性也相對的寬廣許多！ 把所有你能想到的基本功能，都写成一个个的独立 source file ，只在需要的时候才和它编译连结；如此不但程式码易于维护除错，未来的扩展性也相对的宽广许多！ 而这一个个的 source file 集合起来，就是所谓的 library 啰。 就像是自己家里有座图书馆一样，架上摆着分类齐全、功能众多的各种书本，可以依照自己的需求而选取不同的书本来运用；而不是把几万行的程式全都浓缩在一本书 (source file) 中，时日一久，如果生了臭虫，恐怕连原作者都不认识书的内容了！

 

 

『所以，在写小程式赚取经验值的同时，最重要的工作就是要开始建立起自己的 library 。 』 』

 

 

 

其实不管是在网路或书籍范例中，都可以看到很多别人写的 library ；有一些 library 甚至还具备了很强大的功能。但是我并不建议在自己的程式中使用别人的 library 。有什么坏处？以学习者的立场来看，使用别人的 library 所能学到的知识远逊于自己辛苦写出来的 参考别人的 library 写法，或许是个不错的主意，但是要记得：自己的 library ，自己应该要看得懂才行。 否则别说是扩充功能了，就连善加利用可能也没办法做到。 在写 library 的过程中，就可以看出之前学习的成果如何了；如果程式语言、资料结构的基础没有学好，现在肯定会是最痛苦的一刻。在撰写自己的 library 之时，也未必要一次就写出功能非常齐全的物件类别；如果使用物件导向设计模式来撰写 library ，就可以利用其可扩充的弹性，在有需要的时候才写新出的功能，并加入相对应的成员函式；如此又可减轻了初始设计的负担。

 

 

 

 

 

 

Hardcore Stuff Hardcore Stuff

 

 

经过漫长的旅程，写过几个小 demo ，拥有一些自己的 library 之后，应该可以感受到一点游戏程设的乐趣与魅力了吧？但是这样的知识，可能还是不足以达到设计你心目中理想游戏的能力，对吧？  基本知识有了，绘图 API 熟了，接下来呢？ 让我们更进一步来看看比较深入的游戏程设世界。

 

『 Ok, let's talk something seriously. 』

 

 

我想，只要是对于游戏设计稍有兴趣的人，在玩一款游戏的时候，多少都会问自己：「这个游戏是怎么做的？」是的，如果你是一路踏实努力走来的学习者，你现在更应该认真思考这些问题。除了以玩家的身份体验一款游戏的乐趣之外，更要以设计者的角度来看这款游戏。 在此，网路上的许多网站，就扮演了很重要的学习媒介角色。相信你在学习过程中偶尔都会听过一些奇怪的名词术语，像是： BSP 、 Portal 、 Octree 、 LOD 、 Lightmap 、 Ray tracing ……… 等等。 这些就是游戏设计的相关技术名词。 你知道这些技术和游戏程式有什么关连性吗？ 你好奇这些技术如何应用在游戏程设中吗？ 在此，你的英文能力就十分的重要了。

 

 

你想知道的一切，網路上都找的到答案。

 

 

网路资源的利用可以说是学习过程中非常重要，并且不可或缺的一环。  以国外的三大游戏设计网站 Gamasutra 、 Flipcode 和 Gamedev 来比较： Gamasutra 通常会提供相当深入、内容充实的研究主题，包含了游戏程设、美术，甚至音乐与企画管理，非常适合想对某一特定主题深入探讨的人；此外， Gamasutra 也是 Game Developer 这本著名游戏设计杂志的相关网站。 Flipcode ，也会不定期有教学文章的更新，主题多数都蛮具实用性的；并且 Flipcode 的 Image Of The Day 区域提供大家一个展示程式的地方，在此往往可以看到不少有意思的作品，绝对是这个网站不可不看的部分。Gamedev 相较于另外两者，在业界新闻及教学文章的更新速度都比较快，并且文章的数量很多、分类详细，不过其所提供的教学文章多以概论为主，少有比较深入的探讨。

 

 

到此为止，才算是真正开始逐步踏入游戏程设殿堂的时候。

 

 

只要稍微浏览过国外游戏设计网站的话，应该不难发现，其中的文章数目及种类实在太多太多了。 其实对一个初学者而言，这个样子反而不见得是一件好事。  可能会不知从何开始学习，文章里充斥着一大堆看不懂的专业术语，甚至可能搞不清楚自己想要学习什么。 万事起头难，刚开始或许一整篇文章，从头到尾仔细的阅读了两次，还是只懂得其中的两三成内容；这个时候就需要踏实的投注时间与精力，点点滴滴的累积知识的广度。文章看得多了，程式写得勤了，渐渐的就可以了解七、八成以上的内容啰。 每篇文章所讲的主题，就像是一个个的「点」，如何找出点与点之间的「关系」，将这一个个的「点」连成「线」，进而化成一个知识的「面」，也是学习中值得思考的一件事。

 

 

 

 除了每个网站的教学文章之外，附属于网站之下的讨论区也是一个非常重要的资源。试着用英文表达你的诚恳、发出你的问题，即使文法不是百分百正确、即使找不到合适的词汇表达你的意思，你会发现总是有许多热心的人很乐意帮助你的。在国外讨论区回答问题的人，往往都很愿意帮助别人解答疑惑，就算是自己不熟悉的问题，也会提出自己的经验和想法，甚至连程式码的展示也毫不吝啬；所以只要你问的问题够好 ( 我相信唯有好的问题才能导引出好的答案 ) ，往往可以得到远超过你所想像的丰富收获、学到很多有用的知识。在发问前，也可以先搜寻看看该讨论区有没有类似的讨论，或许你的问题早已有人问过了。  记得不要再问「 DirectX and OpenGL, which one is better? 」这种问题啰！ : )

 

 

『网路的资讯是学习新知技术最好的一条途径，那如果想对基础的原理有更深的认识呢？ 』 』

 

 

别无二法，就是书本。书本可以说是学习知识最扎实的 ( 也或许是最痛苦的 :p) 途径。 其实真正学习的最好最好方法，就是找到一个好老师加上一本好书。 不管任何知识，如果有了好老师的授业解惑，绝对有事半功倍之效；很可惜的是，一位称职的好老师真的很难找，特别是在游戏程设这个怪领域中。 所以靠人靠天，最后还是靠自己最实在；书本，就是闭关练功的武林密笈、不二法门。 或许你会怀疑，已经学会了程式语言、视窗程式、绘图 API ，为什么还要看书？书里写的不都是一堆无聊的理论加上复杂的数学式吗？正如在之前的文章所提到的，了解理论并不见得会带来什么立即的效益，也不一定能增强写程式的功力；但是书本的知识，能够帮助你更确实的掌握住事物的本质基础与思维模式。 特别是在日趋复杂的游戏程式设计中，如果没有深厚稳固的理论基础所建构起的法则做为地基，恐怕难以负担起越来越庞大复杂的游戏程式架构。

 

 

 

还是那句老话：「想创造规则的人，必先了解规则。」每一本好书，都是前人以无可计数的时间经验所得来的心血结晶，集英荟萃之后以文字的形式传诸于世，让所有有心学习知识的人都能因此受惠。  从书本中，我们可以轻易的学到前人的知识经验与心血结晶；原来可能自己要花费数年时间才能领悟的道理，现在只需要从阅读书本中的知识就能轻易习得。以 3D 电脑图学来说，了解其背后的许多理论基础，更能帮助你更快的学习并吸收新的知识。例如在了解了 Phong reflection model 的定义之后，就可以很容易的理解为什么光源的组成要分成 ambient 、 diffuse 及 specular 三个成分了；如果了解 3D 电脑图学的发展历史，就不难理解为什么目前的 3D 绘图主流方式还是以 polygonal mesh 为主了；诸如此类，太多太多的例子可以举。 理论知识这东西，不会是你一时的饭碗；却会是你一辈子的财富。

 

 

 

 

 

 

Build Up Toolbox Build Up Toolbox

 

 

 熟悉了一些游戏的核心技术之后，就可以开始建立自己的工具箱了。 何謂工具箱？ 何谓工具箱？ 一般常见的讲法就是「编辑器」 (editor) 。 编辑器大致上有两种用途：一是做为程式的测试工具，二是做为游戏开发的编辑工具。以第一种用途来说，例如你想用之前文章提过的质点系统 (Particle System) 来做一个施放魔法时的特效场面。要怎么要才能知道所写出来的程式码有没有符合需求呢？这个时候就可以写一个质点系统的编辑器工具，把所有可以调整的变数全部列在编辑器的面版中，可能会包括质点大小、位置、颜色、速度及运动法则等等要素。然后就可以在编辑器的面版上，直接调整变数的值，即时的观察质点系统的变化情形如何。使用这种方法，就能够很便利的以各种不同数据测试程式的结果，而不是每次都要在程式码中更改数据后，再重新编译连结整个程式。 更大的好处，就是可以让不懂程式码的人，也能直觉性的调整并控制程式的呈现结果。所以建立编辑器之后，就算是复杂的交叉数据测试，也会变得容易、而且直觉许多。

 

 

编辑器的第二种用途呢？举个例子来说， Quake 3 Arena 中宛如艺术品般惊为天人的美丽场景是如何制作的？如果你对游戏设计的核心技术已经具备有基本概念，就应该能够了解，它的场景不可能是由几位程式设计者，一个一个物件的撰写程式码而完成整个复杂场景的。那应该是用什么样的方式来建立复杂的游戏场景呢？就是依靠所谓的编辑器。 一般来讲，一个完整的 3D 场景就称做一个 level ，而编辑场景用的就叫做关卡或场景编辑器 (level/map editor) 。 通常编辑器是由程式设计者，将所有可能会使用到的功能先设计完全，并做出一个易于操作的使用者介面；如此一来就可以让专门负责场景的设计者 (level designer) 来完成所有的关卡与场景。 只要编辑器的功能够强大齐全，甚至不用懂得任何程式码，也可以设计出非常棒的场景；而这正是编辑器的真正威力。

 

 

编辑器的真正目的应该是化繁为简的能力。 最理想的状态应该要做到，不需要任何说明文件与教学，任何稍具游戏设计概念的人都可以轻易上手才是。  编辑器的产生也使得游戏开发的分工变得更合理可行；只要程式将人物的对话编辑器写好之后，就可以交给企画负责编撰人物的文案；如果程式开发出够强的场景编辑器，就可以让美术来负责整个场景的建模与成形了。 所以编辑器往往是游戏的制作过程中，相当重要的一个部分。如果说一个游戏的开发时间，有百分之五十投注在设计开发编辑器的过程上也不为过！

 

 

 

我知道你在想什么。

 

 

 

到了这里，又要再次面临类似的问题： Borland C++ Builder 与 MS Visual C++ ，到底要选择何者做为开发工具用的编译器？我的答案还是一样的平凡：两者都学了再说。 在之前的文章提过，要写出比较进阶的视窗程式，可以用 Win32 SDK 、 Borland 的 VCL 或是 Microsoft 的 MFC 。 其实编辑器就是属于一种进阶的视窗程式设计，因为它会包含很多复合性的元素，如绘图 API 的呈现、对话盒、控制面版与档案的储存载入等等。 在各大程式设计讨论区， BCB 与 MSVC 的批评比较，绝对不亚于 OpenGL 与 DirectX 的情形。 如果用另一种方式来比喻的话， BCB 就像是家里的万能老妈一样，会帮你把所有想做的事情都打理的很好；只要用「拖拉点放」的方式，就可以完成大部分的视窗元件设计。 而 MSVC 就像是精打细算的老婆一样，所有要完成的事情都要跟她报备，照着规矩一项一项的来做；虽然有一些便利的设计精灵可以应用，可是大部分还是要用「手工打造」的方式，循序渐进的来完成。

 

 

 

而两者的缺点呢？BCB 常被人所诟病的，就是其不佳的程式编译效率及执行效能；而 MSVC 则是 MFC 的学习曲线太长，庞大复杂的 MFC 结构，往往使初学者望之却步。我的建议还是相同，不管别人的说法如何，还是只有自己亲身用过之后才能体会其优劣胜败之处。两者都学习之后，或许才会发现在别人眼里是优点的地方，自己不以为然；而在别人眼里是缺点的地方，自己却不以为意。不论是 BCB 或 MSVC ，都只是一种工具，为了达成某些目的而被造出来的工具；所以，能因地制宜，选择合适的工具，看何者用的比较顺手就使用何者，或许才是比较好的方式。

 

 

 

 

 

 

On The Way

 这么无聊的三篇文章你都能看到这里了喔，真服了你耶。

嗯？ 你说你前面的所有学习步骤都完成了，接下来呢？

不，如果你会有这个疑问，表示你还没到达这里。

『 ……………………… 』

『好吧，好吧，如果你真的好奇的话，让我们再来稍微谈谈之后的路。 』

 

 

 

其实很容易，至此有几个简单的选择；一是对自己有兴趣的主题继续深入研究，往深度发展；二是再寻找其他没学习过的主题，往广度发展；第三，还有别的吗？就是写 GAME ！跟我念一次， G ? A ? M ? E ， GAME ！别忘了我们一路从这漫长艰辛的路程走来，为的是什么目的。 现在你终于可以大声的说：我有能力写出一个游戏了！开始激发你的创意，爆发你的潜能，构思设计一个 GAME 吧！ : ) : )

 

 

 

最后再提一件事情。或许你也会常常听到某某游戏用了什么「 3D 引擎」之类的。 嗯？ 你说这一系列的文章，怎么从来没有谈过有关 3D 引擎的主题？ 咳咳，请记得这篇文章的主题是「浅谈游戏程式设计入门」，不是什么「如何在 30 天内做好一个 3D 引擎」、「快快乐乐学做 3D 引擎」，或「如何在 30 岁前拥有人生第一个 3D 引擎」之类的 OK ？好啦，讲认真的， 3D 引擎真的是非常复杂的东西，绝非像这样的三两篇文章可以解决的。 也不是我目前的能力可以分享的。 也不是我目前的能力可以分享的。 其实像之前所提到的编辑器工具，可以说就是 3D 引擎的一个重要核心；不过 3D 引擎同时还必须整合美术及音乐的部分，将一切制作游戏所需的元素都考虑进去，才能算得上是一个完整的、真正的「 3D 游戏引擎」。 不过我的建议是，就算你已经学习至此，还是先不要想太多 3D 引擎的东西；继续充实自己，累积写程式的经验，利用自己现有的知识与技术，做出一个有趣的小游戏吧！

 

 

 

一向惯于以文字表达的我，到了这里还是不禁要怀疑：这些辛苦敲打出来的文字，究竟能不能适当地表达我心里真正想说的话呢？真正能了解我想表达的意思的人有多少呢？ 而真正能努力做到并且达成目标的人又有多少呢 ………………… 好吧，我承认我想太多了 ( 其实是已经不知道要说什么了 ~_~) 。 总而言之，基本上这一系列文章的重点差不多已经告一个段落，在接下来的最后一篇文章中，我会以自己亲身的学习经验为例，和大家做个分享。  还请大家多多指教。