板主心得：这一篇其实很有历史了，不过里面所阐述的内容，对於 　　　　　任何时期的游戏制作者来说都是个重要学习内容！ 　　　　　面对游戏制作这个高深的学问，初心者往往最容易、最 　　　　　想问的就是：「有没有什麽捷径？」、「有没有什麽程 　　　　　式语言最适合写游戏。」 　　　　　我想这一篇就是最适合的解答。 原文开始 －－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ ※ 原文刊登於游戏设计大师1999年四月号 只是随笔 -- 游戏程式设计初学者常遇之疑问 作者: 陈宽达 EMail: [email protected] DirectX 的角色 DirectX,这让初学者最易搞混学习重心的罪魁祸首。 DirectX在游戏开发者的欢呼声中带着一身众人的期许诞生後,由於它的版本更新速度 远比作业系统还快,因此,使用者不得不自行至网路上下载或由光碟来安装DirectX runtime library,DirectX就是由此吸引使用者的目光而得声名大噪,就如同ActiveX, COM,OLE一般,即使不晓得它究竟是什麽玩意,至少也能琅琅上口,输人不输阵嘛。紧接 着各大书局的电脑书区刚始成批出现打着"Games SDK"及"DirectX"名号的书籍,让这 些对游戏设计有着憧憬梦想却还不得其门而入的游戏爱好份子们误以为DirectX是游 戏程式设计最重要的一环。事实上,如同衣装之於人类,DirectX之於Game Application 的关系仅止於外表的打理而已,至於内涵则是另话,与人的衣装,Game Application的 DirectX同样是八竿子打不着边。 DirectX中,最重要的当属DirectDraw,它是属於不吃不可,不用不行型的,也就是说, 若微软没有推出DirectDraw这套程式库,堂堂一个功力深厚上可飞天下能遁地的程式设 计师也照样没辄,无法突破GDI及HAL这些层层的防护直接控制显示卡,唯有如此才能得 到最高的画面显示效能呀。也就是说,我们无法不依赖DirectDraw而拥有DirectDraw所 提供的功能及效率。至於另一个重要的元件,Direct3D,也与显示卡驱动程式直接私通, 才能获得快速的3D绘图效能,同样属於不吃不可型（除非你偏好OpenGL）。其它的元件, 如DirectSound,DirectMusic,DirectPlay,DirectInput及DirectSetup等,都大大地方 便我们撰写游戏程式所花费的功夫,你也可以不使用它们而作到一样的功能,不过既然别 人都为我们做的好好的了，除非有充分的理由（例如自行发展快速而稳固的TCP/IP连线 函式库）,否则不去使用还还真是自找苦吃:p 另外,虽然DirectX是真正构筑於COM(Common Object Model)上的套件,我想是为了降低 学习门槛及使用的方便性,设计者将较容易让COM初学者困惑之处包装起来,让你不必先 闭关修炼COM三年後才能使用DirectX,就当作是一般的物件导件程式库来用即可。所以 当你迫不急待想感受DirectX的power时,可以先暂时不理COM,用了再说；当你已能灵活 运用DirectX的好处时,可别忽略在底层辛苦出力的COM,是它的功劳才让DirectX能以二 进位形式突破原始码种类的限制让你可以任意程式语言工具轻松享用物件导向程式设计 的好处,对这大功臣还是不可不熟悉熟悉唷。 嗯,回到原题, 提供极欲入门游戏程式设计的各位一句经验谈,不必花太多的时间金钱及 精神在学习钻研DirectX的微末细节,游戏程式设计关键之处末过於整个游戏的核心制 作及内容设计, 相较之下,DirectX真是比较轻松愉快的课题呢。试想: 以游戏程式设计 员的角度来瞧, 对 DirectX 来说是 "user", 使用 DirectX 的 API; 而对游戏核心及 内容来说, 是 "designer", 要设计高效率运作良好的核心及丰富迷人的内容来满足游 戏玩家们, 你觉得, 学习的重心该放在哪呢？ 噢, 顺便一提, 直到现在, 我仍认为对稍有经验的程式员来说, 学习 DirectX 最好的 教科书即是 DirectX SDK 里头附的文件, 厚厚几百页, 读一读再写一写, 绝大部分 DirectX 的马步工夫是可以这样就学得的。 ※ 开发环境的选择 对於许多刚接触Windows程式设计的新手而言，要在各家说法纷云、众多开发工具强伺 的环绕之下，选择一个明智有把握又最适合自己的开发工具的可算是最难的一道入关 匣门了。不啻是新手，就连许多老手也常执着於同一套工具软体，宁可使用钟爱的工 具埋头苦干，无视於身旁更方便好用的解决方法，即使它可以省下开发者三倍的工作 时间。开发工具确是这样重要的一项选择, 选的好, 可让你天天有时间陪陪女友看看 电视逗逗小狗, 万一不幸选到难学难用难写或者根本不适合该专案的开发工具, 就有 无尽的漫漫长夜等着你罗。 常跟朋友聊起, 面对开发工具及程式语言的选择, 约略可将所有的程式员分为三大类： 『菜鸟型』对所有的开发工具程式语言甚至开发平台全然陌生, 只是大略听过一些开发 工具的名称, 而且还经常背错, 如 "Virtual C++", "Virtual Basic", "Dephli", "Borland C Builder" 等等。这个族群所占的比例最高, 也往往是在网路论坛上询问 "该学什麽程式语言 ?" "我想写游戏, 该用什麽语言 ?"这类问题, 甚至常是引发程 式语言及开发工具优劣论辩的导火线, 虽然是蒙懂无辜的。 『专家型』所谓专家, 即是训练有素的...呃, 技术实力高人一等的...呃, 嗯, 专家。 他们通常精通一种开发工具, 独衷一派程式语言, 擅於撰写特定领域的程式, 该开发 工具提供的函式库, framework 滚瓜烂熟。但, 却往往独衷特定工具及语言, 甚至带 点宗教式的狂热, 这类型的玩家常是网路论坛上语言及工具论辩的超级打手。 『无入而不自得型』他们往往会熟悉至少两三种以上的开发工具及程式语言, 并将火力 集中在与语言无关的系统呼叫 (API)。於是, 开发 Client/Server Database 专案时, 拿 Delphi 来拉拉资料库元件; 撰写游戏时, 装起 C++Builder 下载 DGC 元件立刻拼 凑出一个游戏外框; 专案用到 VxD, WDM 或 kernel mode driver 时, 卷起袖子拿出 SDK, DDK 加上 Visual C++, 再买套 VToolsD 或 Driver::Work 来立即动工。无所为 无所不为, 不执着於任何开发工具及语言, 自然不会被任何公司的规划(如MS的VBA吃 遍天下)或美好远景(如Inprise的Information Network)等解决方案所羁绊,而随波逐 流了。 现在有许多电脑玩家常不由自主地对自己所钟情的作业系统, 开发工具, 应用软体甚 至游戏及软体公司产生几近宗教崇拜式的不明究理的狂热, 在此情况下, 很容易去找 到一个貌似敌对的 "对手"来反, 坚定自己的信仰, 壮大自己的声势, 例如 PC vs MAC, FreeBSD/Linux vs MS Windows, Visual C++ vs C++Builder, Delphi vs VB 等等。 在情况越益严重无法遏抑其势的今日, 只能期待点醒一些狂热份子, 拥 X 反 Y 并没 有什麽不对, 但是： "一个人若是为有了宗教信仰而骄傲，自满，甚至因 此鄙薄无信仰的人，或动辄排斥与他信仰稍稍不同 的人，便表示他自己还没有找到信仰，所以，他也 在他自己鄙薄和排斥之列。" <<疑神>>。杨牧 TANet 上一位大哥级的人物也曾语重心长地说：『科技的出现应该是要为人来服务的 ，你尽可以拥抱 X 痛骂 Y ，不过切记知己知彼百战百胜』, 这是看到网路论坛上一 堆连 protected mode, file system, scheduling 都不知何物的网友痛骂 Windows95, 连 API, OOP, framework 都摸不清脉络的新手却大声疾呼推行或反对某某发开工具的 怪现状所发的无奈之语吧！吾亦有同感。 对於"我想写游戏, 该用什麽语言 ?"这类常见也会永远存在的问题, 我曾在网路上见 过这样的回答：『Visual C++ 最适合了』、『VB 好学, 所以 OOXX』等等十分 no-sense, 说是不负责任也不为过的言论。不想流於空谈, 我想还是来谈谈我自己的 看法好了, 就像人类战士通常拿双手巨剑, 侏儒通常肩着巨斧, 而魔法师无可选择地 手执魔杖一样, 选择一把称手武器还是得视个人的情况及需求来量身订作： 一.学习动机 游戏程式设计是程式设计各领域中, 狂热及理想成分比例超高的一群, 甚至有许多各 种性质的程式设计师, 当初都是因为热衷游戏设计, 而就这样持续掉入程式设计的漩 涡呢。学习动机是毫无疑问地: 想要具备撰写游戏的程式功力。不过, 就依游戏种类 的不同, 日後学习的方向与重心也迥异, 例如 2D RPG, 重点在於画面设计及故事剧情, 外加 DirectDraw 提供的快速卷轴能力; 3D 动作游戏, Direct3D 或 OpenGL 是跑不 掉的, 对於图学的理论, 演算法及应用面, 也最好花心思时间去努力研究学习; 再如 多人连线棋类游戏, DirectDraw, Direct3D, DirectInput 我想都用不太上, 好好研 究提供连线功能的 DirectPlay 或发展一套稳固的 Client/Server Socket Library 才是重点。 二.目前基础 目前基础是决定工具及语言上手度的最重要因素。许多人在高中时代学了 QB, 之後便 接着玩 VB; 有些大学的大一计概课程教的是 Pascal, 接着便可顺利进入 Delphi。 必须承认的是, Basic 确实不是开发大型程式适当的语言, 它的先天不良, 例如执行 速度慢, 不是物件导向语言却硬加入类物件导向功能(事实上, 它只可算是 object-based, 而非 object-oriented), 甚至使得微软为了 Visual Basic 一个语 言, 将 COM 规格做了些修改以配合之(如 IDispatch interface), 即使有微软如此 强而有力的老大哥极力护盘, 先天缺陷仍旧无法去除, 除了易学外, 实在找不出太多 若原本是一张白纸, 还未学习过任何程式语言呢？那也好, 请见下段, 视你的个人偏 好罗。 三.个人偏好 Basic, C/C++, Object Pascal 这三个程式语言, 雄霸着整个 Win32 程式设计领域。 Basic 易学易用, Pascal 严谨明确, C++ 强大复杂, 各有各的拥护者及理由。 Basic 简单是因为微软希望 VB 及 VBA 维持在简单到任何想依靠电脑来做自动化程序 的电脑用户都可以轻易地上手的程度, 因此虽然功能不断上叠, 语言本身维持着 Basic 的所有特性。不过缺乏物向导向的支援及执行速度的缓慢, 确是超级无敌让人没力的 致命伤, 因此我会建议所有的初学者, 若能有力能够接受学习其它的语言如 C++/Pascal, 转移阵地为上策。 C++ 的强大无庸致疑, template, exception-handling, RTTI, Stardard Library 等功能不断地加入翻新, 由於使用者众, 要求必多期望必高, 再加上 C++ 本身定位於 功能强大范围广泛的通用性语言, 如江海之纳百川, C++ 自然日益复杂。着名的杂志 C++ Journal 上曾有段话让我印象颇深, "如果你认为 C++ 还不算太复杂, 那麽请你 解释何谓 protected abstract virtual base pure virtual private destructor, 何你又会在何时需要它呢？"(Tom Cargill, C++ Journal, Fall 1990) 虽然是最流 行的 OOPL, 但除非你有足够的耐心及精神来全盘掌握它, 否则轻易尝试的後果可能只 的所有特性。不过缺乏物向导向的支援及执行速度的缓慢, 确是超级无敌让人没力的 致命伤, 因此我会建议所有的初学者, 若能有力能够接受学习其它的语言如 C++/Pascal, 转移阵地为上策。 C++ 的强大无庸致疑, template, exception-handling, RTTI, Stardard Library 等功能不断地加入翻新, 由於使用者众, 要求必多期望必高, 再加上 C++ 本身定位於 功能强大范围广泛的通用性语言, 如江海之纳百川, C++ 自然日益复杂。着名的杂志 C++ Journal 上曾有段话让我印象颇深, "如果你认为 C++ 还不算太复杂, 那麽请你 解释何谓 protected abstract virtual base pure virtual private destructor, 何你又会在何时需要它呢？"(Tom Cargill, C++ Journal, Fall 1990) 虽然是最流 行的 OOPL, 但除非你有足够的耐心及精神来全盘掌握它, 否则轻易尝试的後果可能只 会得到一脸的挫折。当然罗, 十分的复杂也带来十分的便利及不同的乐趣, 我有一位 朋友, 工作上使用其它语言, 但将C++ 当作兴趣来把玩, 跟酷企鹅一样酷呆了。 Pascal, 其实应该说是 Object Pascal, 为 Borland Delphi 所采行的语言。Pascal 的严谨明确是自 Niklaus Wirth 发明它以来一直遵行的宗旨, 而之所以可以顺利演化 为完全的物件导向程式语言 Object Pascal 是由於 Inprise 公司 (原名 Borland) 对 Pascal 语言的全盘掌握, 就像 FreeBSD 的 coreteam 全盘控制所有 FreeBSD 套件的更新撰写一般, Pascal 控制权控制在 Inprise 一小措人手中, 虽失去开放性, 但保有该有的坚持及清新, 也因此我认为它的物向导向支援恰得其所, 该支援的全都 支援了但也没有更多。它与 C++ 的优劣是没有答案, 见人见智的, 正如同大礼服及 小洋装, 好不好看, 适不适合, 因人而异。 　　　　　 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 59.105.58.3