引擎应该包含这样的模块结构：
底层的绘图模块，关于这个，我是这样理解的：
合理的做法应该是：绘图模块只需要负责把表现的图元和纹理绘制出来就好。而不需要关心逻辑方面的处理。
比如：什么时候画，画那部分，画在那里等等，这里应该留给应用层来管理。
就是说，应用层什么时候给绘图底层填充数据，传入什么坐标参数，纹理宽高参数等，这个时候渲染就按照给定的定时器的速率一直在渲染渲染。
数据更新了，渲染新的数据，否则在一定的速率上面渲染旧的数据。旧的数据在显示内存里面，只需要占用很少的CPU时间片来渲染缓存并显示。
我看了一些人的做法是逻辑跟底层绘图彼此纠葛在一起，使得引擎结构相当复杂，其实个人感觉这样做不一定理想。
首先不利于引擎的扩展和优化，改动一个地方，都需要关顾很多地方的改变。
此一时彼一时，现在行业的竞争已经趋于白热化，所以效率是首当其冲的放在首位。
效率当然指的是开发效率。
显然以前的开发架构已经不太适宜目前的环境，而不适宜以前的环境做法也许更适宜于现在的做法。
以前我们更关心对系统硬件的直接研究，现在应该是关注于应用层开发的效率研究和架构。
所以绘图底层是跟硬件直接挂钩的部分，所做的都是一些必须的设置。只要有数据，它就按照标准的流程绘制出来。
显然不再需要我们人为地去干涉它了。
另一方面逻辑部分，这些应该也应该是应用层需要关心的部分。只需要考虑逻辑算法的实现和控制就好。
于是我们就从底层物理控制跳到软件的实现部分。只要你有想法就完全可以通过代码实现来处理出来。
应用层需要一个强大的数学库支持，相信这些数学库大家完全可以收集得到。
我很幸运，自己想通了这些。因为我一直向往的是开发的便利性。我们需要把时间压干，在最短的时间内做出最好的东西。
然后我们可以在自己今后的人生中做出很多跟自己理想相关的事情。做更多美好的事情，是我们的人生追求！
那么，关于游戏，我们喜欢游戏的打击感。
是的，很多人都谈到什么是打击感。
但是他们谈的不是我所想的。
是的二维游戏PK为什么这样过瘾，这些如果是站在程序员的角度上面，你什么都了解不到。
如果作为玩家，你会明白了。
当我们清清楚楚看到，角色砍下的那一刀，对方的血量立即反映效果出来，这种痛快是显然的。
但是这些还不是最理想的打击感，实际上，我们需要反映出一个这样的过程，从人物挥刀到砍下的过程里面，是否需要一些变化。
这些变化增加角色战斗的凶悍和战斗的残酷性。
在定时片里面，前面3帧我采用了180毫秒的速率，后面的3帧我采用了100毫秒的速率，于是我们看到角色在最后砍下的时候——
是如此的毫不置疑，因为帧数只有6帧，所以如果人物挥刀的时候再稍慢一些，这样的变化就更明显了。
而我了解到很多游戏都是采用恒帧的方式来处理，就是播放的速率是自始至终是一样的。
三维游戏就不一样了，因为动作效果是在软件里面就设定的，要快要慢早就在导出模型文件之前就设置好了的。
只是三维游戏的PK——确实不咋样。
也许你能明白我说的打击感，也许不会。
很多游戏都喜欢加入绚丽无比的特效来展现打击的效果。以为这样玩家会很喜欢的。
我所知道的很多游戏的制作人都是游戏的白痴——这个我是作为一个玩家身份来说的。
是的，你永远不会明白我们到底需要什么。
如果不是受到客观条件的限制，我们可以把攻击失效和角色的敏捷躲避属性通过动画表现出来，而不是使用文字来告诉玩家，你躲过了此次的攻击。
有些人喜欢采用飘血的方式来表现角色当前失血的情况或者怪物的掉血情况。这样的画面你可以在很多游戏里面看到。
我说了，很多游戏制作人跟白痴是没有两样的。
我是不会采用这些白痴的做法。为什么呢。
作为玩家，我们更喜欢在清晰的环境下去体念我们的游戏，这样我们可以很好地进入到游戏的体念里面而不受到那些多余的东西的干扰。
只有清晰地看到我们角色的战斗画面，或者我们在了解我们释放的魔法是否明显作用在对方或者怪物身上的时候，我们才体念到攻击的爽快感。
只有想清楚需要了解的东西，我们才可能开发出一款可玩性更好的游戏，这些跟引擎开发又是脱离不开的。
因为很多东西我们不需要在程序里面做出来，节省开发的时间。
是的，只要有了绘图引擎，你想怎么体现各种效果都行，问题是，我们需要维护和管理大量垃圾代码，并且增加引擎的不稳定性。
而且增加代码量并不是不需要代价的，这些都增加系统资源的开销，这些是最起码的。
继续。。。。。。。。。。。。。
809
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
