浅谈游戏制作中的主框架

PassByYou

什么是主框架？
关于主框架的深层意义，暂时不做太多的解释。主框架一般在大中型项目中，被定义成为一种工程躯干。在项目实现中，主框架一般是前期由系统分析员，或则有丰富经验的程序员来制作和规划。一旦项目开始运作，这时主框架就成了集结项目中那些细节末枝的躯干了。

目前我是在深痛的经验教训下，站在走过的路的末端。将曾经的一些经历抖出来，供参考用。

在游戏公司，有种情况经常发生：
开始，一群斗志昂扬的游戏开发者，大家群策群力，终于完成了按预定的策划内容的开发工作。然后游戏也推出上市。也许收效非常好，也许不好。

然后呢。公司的主程们，主策们，开始对游戏进行反思了。找到了很多不足的地方，又冒出了很多新的IDEA。这时，大家突然觉得应该推出二代，或则开始开发另一个新的游戏。这时，主框架问题就来了。

当主程了解到新的策划内容，确定了具体需要做些什么开发。然后搬出以前的一代，看了看，然后就会有这样的感觉：为什么当初我没有想到某种方法？搞得现在改这些密密麻麻的代码真的是比开发一个全新的还麻烦。

然后当公司开发完了二代，这时候，已经是n个月，或则是n年以后了。这时，主程如果再面临当初的遭遇，主程会说，开发二代，小kiss。

纵观整体，进步依靠自己，经验依靠自己。所有的游戏开发都是这样，一步一步摸索着在前进。偶尔有个人，比如我，因为一些偶然的机遇，一个留心看见了高人。于是暗地记忆，分析，最后大大的加深一个游戏制作的层次。

因为认识，所以加深。我大致总结了一下。

主框架中最关键的地方不是什么躯干怎么做，因为躯干部分的开发只要有一定的程序经验一般都是没问题的。加深制作的地方根本不在这里。主框架中最关键地方在于开发过程中那些细节处。
一，能够独立成一个单独模块的，必须独立。甚至做成中间件也在所不惜。不要以为这不重要，这太重要了。尤其是大中型的项目。
二，尽量让主引擎系统中的东西独立。这点需从最细节处开始做起才能看到效果。我举个例子，渲染框架、数据框架、规则引擎框架，这两个框架里面的小东西可以说不计其数。很多公司的做法是重视整体性，而轻局部。在未来如果面临升级，复用时，这时你就会发现，再次基础上再开发是多莫花时间，和多莫痛苦了。简单来说，就是细节到细处的地方，都要独立。未来的升级，修改容易，就意味着高速进步。
三，光是独立还不够。还有流程安排，接口定义，在游戏制作中这些都不是简单实现就可以了事的。
Over.

小小C

如果真的像你说得这么简单就好?

月下临风

能独立的东东，当然最好独立了，否则后果很严重。

clayman

汗-_-b
又见"小kiss"...............

renyihehe

可不可以共享一下更细致的经验呢？比如，举个实例，说明一下！
期待！
顶！

PassByYou

找家游戏公司，工作个半年，什么都会了。多了解一下怎么做，和做的方法。

要不然就自己写一个游戏。纯粹作为提高用。绝对非常有用。

系统崩溃

楼主所总结的一切其实就是一个词：松耦合。
精通面向对象设计的高手，即使他不是做游戏，也一定很认同这一点，只是在很多时候，实现松耦合不得不付出额外的开销，而这种代价从眼前项目看往往是无谓的，只有考虑长远时（如楼主的例子）才意义重大，所以追求框架风格良好的设计师最怕碰上急功近利的老板。

renyihehe

PassByYou: Re:浅谈游戏制作中的主框架

找家游戏公司，工作个半年，什么都会了。多了解一下怎么做，和做的方法。

要不然就自己写一个游戏。纯粹作为提高用。绝对非常有用。

呵呵，我不是程序。所以，你说的方式，无法进行…………

whb9633

最小细节也要独立这就不是“松耦合”的问题了
根本就没用，组件软件设计的基本理念就是“基于组件重用”，一个元操作级的重用根本是无稽之谈

PassByYou

whb9633: Re:浅谈游戏制作中的主框架

最小细节也要独立这就不是“松耦合”的问题了
根本就没用，组件软件设计的基本理念就是“基于组件重用”，一个元操作级的重用根本是无稽之谈

主框架是做给别人用和修改。非自用的。工程大改心得：底层不止一次大改。准确是，元级组合重用。做概念。