MFC和游戏框架。(需要和高手讨论)

[tobato]

问题： 1. MFC为何不适合做游戏？
2. 制作游戏的时候，你是否考虑过程序的框架？如何考虑的？
3. 是否考虑过程序的面向对象特性和重用性？
4. 是否考虑过用那种模式来设计程序,已达到程序有比较好的扩展性？
5. 在制作游戏的时候，是否使用一些分析工具？


我对这几个问题百思不得其解，希望能和游戏的设计高手们讨论一下。

[nickHu]

1.
他们总说因为MFC复杂的class层次结构导致了程序速度降慢，我总是不以为然：现在开发2D游戏即便再复杂,用directX,玩家是PIII的机器也能应付了得了，directdraw已经为我们节约了大把的时间，多态的、复杂的class层次结构所占的时间总是凤毛麟角！
至于3D那就不好说了，没做过，不敢胡说八道！
2.
我所喜欢使的是gaf游戏程序框架，正在自己力求写一套游戏中用的基于ddraw的控件库，别的我认为就很难重用了（工具程序除外！）
3.
面向对象是你的奴隶，你不是面向对象的奴隶，认为有必要就用，没必要就不用！你又不是在开发library!

剩下的我认为我没有资格做答：）

[tobato]

问一句：
Gaf 游戏框架是什么？

对于是否使用面向对象，我的观点是：使用面向对象，一定能够提高程序的适应性，和可扩展性，但是需要对面向对象的方法有比较深的了解，还需要对使用的语言有深入的了解。

[finalvictory]

to nickHu(小子)：

1.有些微词：
永远不要指望用户的机器让你的程序运转如飞！没错，他的机器是PIII，可是如果你有一台PIII的话，你会甘心开着一个窗口玩游戏不做其它的事吗？我想不会吧？我的老牛C433还要玩quake的时候载东西呢！有可能他也认为你的程序足够快了，他的机器足够劲了，于是开着Winamp听歌，开着FlashGet下载，再来一个金山独霸后台扫描……呵呵，还有多少CPU分给你的程序？

2.保留意见……
3.同意！

to tobato(tobato):

1.我认为MFC之所以不能用来做游戏除了它体积庞大的原因还有别的原因，而事实上我不用它也不是因为我的程序苛刻到要在乎这些，而是我认为它的结构不适合用来做游戏。看看MFC的类框图就知道了，它是为那种典型的OnXXX()结构设计的，说白了就是“有任务就执行，没有任务就等”。做过游戏的都知道，这样可不行啊！

2.框架没用过，因为担心效率。顶天写过10万行代码，框架是自己写的……

3.up

4.使用C++，并且应用OOP。在一开始就尽自己最大努力设计一套好的接口（虽然这很难，现实一点来说基本不可能，但还是要尽力去做）并且严格按照接口规范编程。等工程庞大起来以后你就有可能发现自己当初是多么的英明！

5.down

[nickHu]

我的意思是:速度已经越来越不是问题了！（当然，别用windows gui去做！）
gaf(game application framework--口气大了些！）是“第二人生工作组”开发的一套游戏编程库，免费下载，另外新书《pc游戏编程》盘中提供（比较好用，对dx的复杂初始化、释放进行了重新封装，还提供了直接用jpeg文件创建表面)

[madmanahong]

问题： 1. MFC为何不适合做游戏？
据说是慢！

2. 制作游戏的时候，你是否考虑过程序的框架？如何考虑的？
从流程考虑

3. 是否考虑过程序的面向对象特性和重用性？
没有！淘汰是一种必然！

4. 是否考虑过用那种模式来设计程序,已达到程序有比较好的扩展性？
面向对象！


5. 在制作游戏的时候，是否使用一些分析工具？
在窗口模式下用vc调试感觉良好~：）

[ninny]

有道理
顺便问一句，大家又没有写过mfc框架下的directx程序？有代码例程给小弟参考吗？

[uno]

Andre Lamothe著
《Windows游戏编程大师技巧》
中国电力出版社出版

看看大师的忠告
就知道了

[zhangyan_qd]

1. MFC为何不适合做游戏？
这要视游戏的性质而定，如果是一些交互简单的战略性游戏比如三国志那样的，利用MFC未尝不可。但是否考虑过MFC扩展UI的时候的麻烦？如果是对速度有要求的游戏，特别是3D实时游戏，MFC的OO特性会影响表现力。虽然传递几个虚指针浪费不了多少时间，但是请计算一下，在一个每秒30帧的3D游戏里，处理一帧的时间实际只有30毫秒，还要花多少功夫在几何计算和像素处理上？所以综合来说，MFC的特性不太适合做游戏，但如果你自己根据MFC的思路做一套适合游戏的Framework又另当别论了。

2. 制作游戏的时候，你是否考虑过程序的框架？如何考虑的？
这个毫无疑问，做什么程序不需要考虑框架呢？但是如何做就是见仁见智的了。做得多加上勤动脑而已。至于成熟的框架都是游戏公司的不传之密。

3. 是否考虑过程序的面向对象特性和重用性？
底层的处理，比如图形、声音、输入等等，可以考虑一定的重用性，但未必一定要OO这种重量级的东西来实现，C Style API也很好用，只要你设计得好。至于框架级的重用，我觉得意义不大。除非你想炒冷饭。

4. 是否考虑过用那种模式来设计程序,已达到程序有比较好的扩展性？
游戏和一般的商用软件不一样，基本没有什么可延续性，考虑所谓扩展性得不偿失。至于模式，模式从来都是后验的，做的多了自然总结出模式来，可是如果从来没做过，或者经验很少，给你个模式也用不好。不必迷信模式，但是应该不停的思考再思考。

5. 在制作游戏的时候，是否使用一些分析工具？
分析工具？UML吗？太夸张了吧？
游戏制作是一种很专业的程序类型，经验远比理论重要。这一行要形成像UML那样的方法论还需要很长的时间和更大的市场来支持。

[key_lord]

我的切身体会是，速度不是问题，那点额外的开销在根本觉查不出来。但用MP3做背景音乐（用DIRECTSHOW）时声音会断续，可能和线程机制有关。

[tobato]

我的意思是不是单独用MFC，而是MFC+Directx.

to finalvictory(维克) "在一开始就尽自己最大努力设计一套好的接口"
你的经验是什么？

面向对象的设计，绝对能够提高程序的可重用性，为什么感觉国外的程序或大公司做的程序比较健壮，这是可重用性产生的技术积累。比如EIDOS古墓系列，和它的3D游戏，大部分感觉都是一样的。有了技术积累才会有快速开发的能力。

[finalvictory]

我的经验？举个例子吧。

在游戏设计初级阶段，就要尽量把游戏中所有的对象都设计好，当然不用太详细，但是每个对象的功能，行为，属性等等都要有一个清晰的轮廓，有点像一个软件工程。当你完成这一步的时候，呵呵，下面就要看造化了，你要尽可能把所有对象的共性提取出来，抽象成一套适合于所有对象的接口（在C++中就表现为抽象类和纯虚函数）。以后编程的时候，严格按照这套接口来，不到迫不得已，决不改变接口，除非发现确实是当初接口设计失误。等工程庞大起来以后，你会发现：原来增加一个原先没有料想到的模型是这么容易，只要从虚基类派生一个描述新对象的类就可以了，别的代码都不用改！如果你一次又一次重用这个模型，你会对它的内涵把握得越来越清楚，你也会把它优化得越来越合理，于是你的开发速度就越来越快了！我觉得这当中最难的地方就是抽象提取那一块，非常费脑筋，而且要非常细心，一旦有一个地方提取得不好，接口设计得不完善，事后你想一想的话，它给你带来的麻烦会呈几何级数增长！我觉得这种本事学是学不来的，更是背不来的，靠的是平常经验的积累，和对面向对象编程思想的深刻把握。

好了，废话了一通，让高手们见笑了，呵呵……

[anamnesis]

mfc本身还有mem leak
目前好像光荣的和3do的游戏很多用mfc开发的
所以说也不是不可以
但是directx等本身就是sdk方式的
硬要改成mfc框架来跑不是很爽
mfc主要是为了rad
一步到框架
但灵活性比较差
c#的默认工程现在也改回sdk了

[夭夭]

1MFC在游戏中有用处吗,界面上用不上,别的更不用了,

[guoyin007]

游戏公司应该有用什么引擎来开发产品吧,难道真的一切都得从车轮造起吗?
自己写一个游戏框架费神费时,还不一定很健壮,我想这只是在学习过程中有用吧,但真正拿到商业开发就是另一副样子了