这段时间看了不少的传奇的源代码。
感觉一个字，烂，不是一般的烂。
我相信大家都知道。
同时大家肯定明白，如果重新优化和架构，效率肯定要比原来的代码要高很多很多倍。
首先说一个地方，virtual和dynamic，虚方法和动态方法。显然代码里面大部分都是采用动态方法，这个要命啊，慢啊。
关于虚方法和动态方法的最大区别是，虚方法速度快，比动态方法快多少倍未知。缺点是费空间。动态方法费时间省空间。
一般我们是不经常调用而且速度不是居于首位的时候，我们采用动态方法。相反经常调用频繁，而且速度居于首位的，我们采用虚方法。
这些是毫不迟疑的。
但是那些（大家明白的源代码）为什么采用动态方法呢，告诉大家，这个是个时代的问题。
不要以为源代码必须要这样才行，想象一下，当时这个游戏开发的时代是那个时代，那个时代的内存和CPU是特点怎么样的。
128MB内存估计还是挺高端的吧，现在是否明白了？
有现成成型程序的，可以把动态修改成虚方法看看，客户端占用内存的情况。
游戏程序需要的是速度，目前玩家的电脑一两GB的内存已经很普遍了吧？
咋样，只修改一些地方，游戏效率肯定提高上去。
但是这些还未够。
然后我们先看MShare.pas这个单元，吗啊，大量的全局变量。
看看图片库的全局变量，看出啥问题没有。
问题是在：很多不需要实例化的变量都已经被实例化了。
为什么说是不需要的实例化的对象呢，因为我们知道，进入游戏的时候，玩家的职业仅有一种。
实际上，那些其它职业的相关图片库对象完全可以不用实例化。这样完全可以节省非常多的系统开销。
但是对于现在的这些源代码来说，你必须全部实例化他们，否则运行肯定有问题，因为结构本来就是个大问题。
先看角色这个基类，这个能够叫做基类，告诉你，这个啥都不是，我叫做废物类。
NPC类型，怪物类型，各个职业的类型的东西都挤在这个所谓的基类里面，这个叫做啥类合适？
牵一发而动全身，哪怕你修改或者增加一点东西，很难想象会不会影响其它的运行。
尤其是很长很长的各种检测判断代码，天知道，系统执行一条函数，需要怎么样的开销。
这样的代码你还敢往上面添加功能，真是神啊。这种精神很值得佩服，不是吗。
为什么很多人的程序执行效率那么不如人意，因为这些结构本身就是错误的，你还能够咋样？？？
看了这些代码，我完全看到了自己最初学习编程的时候那种写代码的风格，呵呵，没有法子，谁都是这样过来的。
常规下，我们首先把一些雷同的东西的抽象出来作为基类进行集中处理，这样可以节省很多代码模块的开销。
然后我们再在这个基类上面进行细分出各种不同的子类，只需要编写它独有的功能模块。
这样的好处是，当玩家当前玩的是这个职业的角色的时候，我们只需要实例化该类角色的相关对象。
逻辑层面，我们只需要处理此类角色的逻辑代码。
如果我们要修改该类，只管调试该类相关的东西，不至于会影响到其它类型的东西。
想象一下，这样合理的代码结构，会给你程序提高多大的性能。
你不需要再调用检测模块去检测那些不相关的类型的代码，单是这个，程序的性能就提高很多很多了。
并且无论是以后的维护和扩展，空间是完全足够的，而且花费的时间更少。代码结构更合理。
那些GM骂你的客户端卡B实际上是正确的，哇哈哈~~~
想象一下，如果你选择是武士这个职业，而不需要系统去为其它职业分配资源，那些声音啦、图片库啦等等，是不是很开心的事情。
说真的，最初看到这些代码的时候，一股无名火串上来，现在看的时候，仍然感觉很火。
真他吗的，有这样编程的吗？
不过这种垃圾代码并不垃圾哦，赚了多少钱了哦，靠。
为了，能够使我的D2D引擎发挥出威力，我决定重新架构出新的类，一个适度的面向对象的类。
为什么说是适度呢，因为我需要的是合理、更高效率、更稳定的、同时更利于维护的结构。
目前有不少朋友都在改系统的绘图底层，有采用HGE的，有采用ASP的。
那么采用那个好呢，其实这两个都不适合你，只适合你做参考。
那么这两个那个好点呢，很多人以为是ASP，其实要理想的是HGE，这个比较底层一些，效率更高，相对的。因为绘图的渲染部分，你必须修改过。
ASP封装得太深，用来做应用程序比较好，不适合做大型的网络游戏。
为什么很多公司都采用C++来制作，因为更底层。HGE就是这样，所有处理都很直接。
有足够的编程的能力的，最好参考HGE来做。