大家去不去VC那边，看看这个，我译成简体中文了。无意引起开发工具的争论！！

smartboyme 2001-06-01 01:45:00

All Forums
程序设计知识及技术
Game Design
[随笔] 游戏程序设计初学者常遇之疑问

Author Topic
Jethro
论坛坛主

Taiwan
312 Posts Posted - 02/16/2001 : 11:22:51
--------------------------------------------------------------------------------
只是随笔 --
游戏程序设计初学者常遇之疑问

作者: 陈宽达
EMail: kuan@ilife.cx

开发环境的选择

对于许多刚接触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), 即使有微软如此
强而有力的老大哥极力护盘, 先天缺陷仍旧无法去除, 除了易学外, 实在找不出太多
该使用VB的理由。VB 虽然可以使用 DirectX, 但还必须透过其它链接库的帮忙, 因此
除了 VB, 我很赞成就配合你目前的所学, 会 Pascal 就用 Delphi, 爱用 C++ 就请
用 C++Builder 或者 Visual C++。

若原本是一张白纸, 还未学习过任何程序语言呢？那也好, 请见下段, 视你的个人偏
好啰。

三.个人偏好

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, 其实应该说是 Object Pascal, 为 Borland Delphi 所采行的语言。Pascal
的严谨明确是自 Niklaus Wirth 发明它以来一直遵行的宗旨, 而之所以可以顺利演化
为完全的对象导向程序语言 Object Pascal 是由于 Inprise 公司 (原名 Borland)
对 Pascal 语言的全盘掌握, 就像 FreeBSD 的 coreteam 全盘控制所有 FreeBSD
套件的更新撰写一般, Pascal 控制权控制在 Inprise 一小措人手中, 虽失去开放性,
但保有该有的坚持及清新, 也因此我认为它的物向导向支持恰得其所, 该支持的全都
支持了但也没有更多。它与 C++ 的优劣是没有答案, 见人见智的, 正如同大礼服及
小洋装, 好不好看, 适不适合, 因人而异。

RAD Tool 无罪论

最近网络上兴起一道 "Visual C++ 与 C++Builder 孰优孰劣的讨论", 其中可以看到
一些颇为中肯的言论：

--------------------------------------------------------------------------------

发信人: Meou@m2.dj.net.tw (Dadai), 看板: programming

这两个东西都蛮好用的. 但是现在我摸了几个月之后, 我反而比较喜欢 VC++.
VC++ 的界面看起来繁琐, 但是真的用心花个几天把 VC++ 的功能摸熟, VC++
用起来还蛮顺手的. 再加上把 VC++ 的 Application Wizard
的来龙去脉搞清楚, 把 ClassWizard 的用法弄懂, MFC 一点一点慢慢弄熟之后,
VC++ 的功能还蛮强大的. 加上 VC++ 的 HTML Help 比 BCB 好上百倍,
我现在觉得 VC++ 比较好用.

其实这两个工具, 一个是倚天剑, 一个是屠龙刀, 放在不会用的人,
那一把都不顺手. 这两个工具都需要相当好的 C++ 基础. 好的 C++ 基础对
MFC, OWL, VCL 来说都是基本功而已. 学程序学了一阵子, 觉得 MFC
摸熟之后, construct 界面不比 BCB 来的慢,
重点在于界面之下你到底要如何解决问题. 这个问题比 Application
Framework 及那一套开发工具比较好来的重要多了.

--------------------------------------------------------------------------------

发信人: dyliu@ms1.hinet.net (四眼的王虫), 看板: programming

VC++ 的 help 系统的确比 Borland 的 Delphi, BCB 等好太多了,
Borland 在这一方面一直没有甚么进步, 有时候我用 Delphi 或
BCB 时还会执行 VC++ 就是要用 VC++ 的 help 系统, Borland
实在应该在这一方面大力改进才是.

界面方面 MFC 实在是比不上 VCL, 简单的界面还好复杂一点的
MFC 就得搞上老半天.

--------------------------------------------------------------------------------

发信人: oesd@email.gcn.net.tw (Dadai), 看板: programming

VC++/MFC 的 Learning Curve 看起来比较长, 但是值得.
因为你如果搞懂的话, 再配合上一些 SDK 的 knowledge 及合适的 development
kit, 你几乎可以在 Windows 下做任何你想做的事
(剩下的只是你怎样解决你要解决的问题). 我自己觉得 MFC 要用的有点基础,
最起码你要能把 VC++ Wizard 能做的东西知道如何全部用手工打造出来.
不然用 Application Wizard 建出来的东西, 你一样看不懂,
更不要讲如何去改它了.

其实象 BCB 这种 RAD Tool 要学的好, 我觉得比 MFC 还难.
因为在那漂亮界面下的底层机制往往比 MFC 复杂许多. 真的大声喊 BCB
好简单的, 我只看到两种人. 一种是在 Win32 SDK 里面打滚多年, 那几千条
Win32 API 就算没用过也都大概摸过, 没摸过也知道大概会叫什么名字,
该往那边找. 问他一个问题, 脑袋里面会自动列出一堆 Win32 API,
一条条过滤该如何解决. 写 Windows 程序可能打字到手指头都长肌腱炎了.
BCB 对他们是种解脱, VCL 更是不成问题.

而另一种则是完完全全的初学者. 用 BCB 来学 Windows Programming.
最多只能学到 Compnent 有提供的功能都会用, component 不会的他也不会.
component 不行的他也不行. component 的限制就是他的限制. AP 写到一半,
中间要 call Raw WIN32 API, 他大概就挂了. 要做现有 component
做不到的功能? 那你要不要花钱买 VCL library?

--------------------------------------------------------------------------------

同样是 RAD Tool 的使用者, 有的是全然解脱, 轻巧驾御 RAD, 大部分却属于阵日搜
索组件, 局限于别人制作的组件功能内的 RAD enabled-expert, 你愿当哪种人 ?

以大局观 Visual C++, C++Builder 及 Delphi 这三套工具, 就最重要的差异来列出
以下这张表：

Visual C++ C++Builder Delphi
设计公司 Microsoft Borland Borland
前端语言 C++ C++ Object Pascal
Application Framework MFC VCL VCL
接口设计方式传统
(Class Wizard 及手工打造) RAD
(拖拉点按) RAD
(拖拉点按)
程序核心手工打造
(有许多链接库及类别可供运用 ) 手工打造
(有许多组件, 链接库及类别可供运用) 手工打造
(有许多组件, 链接库及类别可供运用)
运作原理呼叫 Windows API 呼叫 Windows API 呼叫 Windows API

呼叫由 kernel32.dll, user32.dll 及 gdi32.dll 三大模块为首所提供的数千个
Win32 API, 原本是 Win32 应用程序开发者唯一可用的方式, 这些 API 分成几些
种类, 各擅其职, 只要利用它们, 少有做不到的事, 唯一的缺点是, API 多且繁杂,
而且如同 RISC CPU 的指令, 每一道 API 所做的事情并不多, 往往一些必须频繁
撰写的例行公事, 例如建立新窗口, 注册窗口类别, 更改按钮颜色等等动作, 还得
花上十几行程序代码来做, 麻烦透了。需求乃创造之本, 于是链接库出现了, 紧接着
挟着物向导件的优点类别库也出现了, 最负盛名的两套就是 Microsoft 的 MFC 及
Borland 的 OWL。慢慢地, 虽然有类别库及 wizards, experts 的辅助, 仍有人不
知足地想要发展能够更快地开发应用程序的方法, 于是就有了 Visual Basic 这类
可靠鼠标完成大部分接口设计工作的 RAD 开发工具, 最后才是 Delphi及C++Builder。

随着时间的脚步, 人们总要适应大环境的变迁及进化, RAD 的确为程序开发员省下
不少接口开发的时间, 但相对地来说, 它也降低了程序设计的门槛, 太多的初学者
沉溺于 RAD 组件的强大及使用, 不知有程序语言之重要, 无论底层的系统呼叫。
我想这也许是 RAD Tool 开始受到部分人们的质疑之故。

看透非 RAD Tool 及 RAD Tool, 抹穿 MFC 及 VCL 这两套 application framework,
它们只是包装一薄一厚, 用法各异罢了。MFC 薄薄的一片, 让你拥有全盘掌握的满足,
相对地, 学习曲线既陡峭且高峻, 需有足够的背景知识才能充份融入 MFC, 享受它的
好处。VCL 包装地并不彻底, 但厚厚地这一层, 让人完全看不到骨子里的究竟, 如同
寒流一来, 一个身穿五六件衬衫外加夹克两条的女人打从你眼前走过, 天知道究竟是
蛇腰丰臀亦或骨瘦嶙离呢。就接口打造来说, VCL 包装的真是好用方便, 不过常有
VCL 力有未殆, 包装不足时, 此刻, 是 RAD 也好, 非 RAD 也好, 任何工具帮不上忙,
只有瞧自己琢磨 API 的功夫, 若没有三两下功夫, 马脚随着framework的不足就立即
露出了。
啥
这让我想到几年前曾发生的 "command line 优劣之争", 有些高手们及UNIX fans
喜爱命令列, 一来速度快, 二来有全盘掌握的感觉; 而另一派当然是倾向 GUI 啰。
传统确实有传统独到之处, 否则为什么在电子音响大行其道的今日, 仍有玩家愿意
倾几十倍的价格, 把玩真空管音响呢 (我老爸就是一个:p) ? command line 用得熟,
操作速度比 GUI 还来得快上几倍倒是真的, 我觉得这是 command line 需要存在的
最大理由。也有人对我说, "command line 较让人懂得计算机真正的运作原理", 我告
诉他, "为什么 GUI 就会妨碍到我们去了解计算机的运作原理呢 ?" 守旧也得要合理的
理由, 否则只是恋旧, 潜意识里的观感其实是怕跨入新的领域而失一向保有去优势。

所以呢, 手工打造的好, 还是拖拉点放的方便 ? 手工打造的快, 还是拖拉点放的省
事 ? 我想是答案是很明显的, 宁可在例行公事上能省时间就多省点时间精神, 我们
还有未来等着去创造呢, 焉可镇日沉迷在手工打造全盘掌握之感觉中呢 ? 我想,
RAD Tool 无罪, 它只是让门槛变了低, 让程序设计变得简单轻松, 何罪之有！

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 的马步工夫是可以这样就学得的。

--
管理员陈宽达
Programmer 深度论坛

taoyuan0715
幼幼班

7 Posts Posted - 05/19/2001 : 22:50:12
--------------------------------------------------------------------------------
各位前辈:
看到这篇文章,实在感触良多.
小弟是属于文中那种VCL用的不错,但没了VCL就有点动不了的那种.
有几个问题请教:
我一直试着自己去写VCL,但一直觉得写的不好,
请问Delphi有没有比较好的书,可以教导我呢?
因为我看一些组件中的程序,他的写法总是一般
Delphi书中所没写的!还是有类似VC++写win programming
的书而是用Delphi写的呢?谢谢指教!!

JBT
园丁北北

Taiwan
340 Posts Posted - 05/19/2001 : 23:06:24
--------------------------------------------------------------------------------
※ 引述《taoyuan0715》于 05/19/2001 22:50:12 发表之铭言：
>我一直试着自己去写VCL,但一直觉得写的不好,
>请问Delphi有没有比较好的书,可以教导我呢?
>因为我看一些组件中的程序,他的写法总是一般
>Delphi书中所没写的!还是有类似VC++写win programming
>的书而是用Delphi写的呢?谢谢指教!!

Borland Delphi 4 Developer's Guide 有介绍如何撰写 VCL 组件，
这本书国内由钱达智先生翻译，Delphi 4 业界标准手册【技术篇】【实用篇】。

网址为：http://www.chih.com/books/d4dg/d4dg_content.html

另外，原版 Delphi 所附赠的手册里，也有介绍如何撰写组件。
以上信息，供您参考。

BTW，建议您下回引言可以稍作删减，要不然，一拖拉库显示还真要花点时间... :P

taoyuan0715
幼幼班

7 Posts Posted - 05/20/2001 : 00:32:04
--------------------------------------------------------------------------------
※ 引述《JBT》于 05/19/2001 23:06:24 发表之铭言：
>※ 引述《taoyuan0715》于 05/19/2001 22:50:12 发表之铭言：
>>我一直试着自己去写VCL,但一直觉得写的不好,
>>请问Delphi有没有比较好的书,可以教导我呢?
>>因为我看一些组件中的程序,他的写法总是一般
>>Delphi书中所没写的!还是有类似VC++写win programming
>>的书而是用Delphi写的呢?谢谢指教!!
>
>Borland Delphi 4 Developer's Guide 有介绍如何撰写 VCL 组件，
>这本书国内由钱达智先生翻译，Delphi 4 业界标准手册【技术篇】【实用篇】。
>
>网址为：http://www.chih.com/books/d4dg/d4dg_content.html
>
>另外，原版 Delphi 所附赠的手册里，也有介绍如何撰写组件。
>以上信息，供您参考。
>
>BTW，建议您下回引言可以稍作删减，要不然，一拖拉库显示还真要花点时间... :P

谢谢您的指教,您介绍的书我会参考!
我目前所处的问题是要做一个类似gis的纟统,
我必须要处理一个大约二百mb的图,
并在其上放置图件,并且这图件还要
动态的定位,并支持图形的缩放!
像这样的问题,我该从那下手!
Delphi有可支持bmp图形缩放的组件吗?
我又能不能在该组件上再作手绘呢?
sorry~本人对于绘图较没研究,
希望大家指教!!

FBI-MAN
幼幼班

5 Posts Posted - 05/21/2001 : 01:04:34
--------------------------------------------------------------------------------
文章实在选得不错,但是焦点稍微不明确,因为每封信都是一小段,建议把所有的评比
列一表,比较能够快速使人辽解复杂的交叉比对。

Tomm
园丁北北

...全文