关于游戏中的实体系统 --- Component-Based Entity System

首先关于游戏实体，最早有这个概念是看了这篇文章---游戏Entity设计不完全整理

最早接触游戏编程的时候，看的是老师的代码，类似于早期的游戏，使用的是最传统的继承模式的实体系统。当时就觉得继承就是面向对象的一切，认为只要不断的继承就能解决所有问题。到后来才发现，继承的一个严重的缺陷是你必须知道所有父类的具体实现，到了最后一个实体也变得非常臃肿且难以修改。后来接触了设计模式，知道了策略模式这东西，大概的意思就是使用组合代替继承，个人认为组件模式更多的就是使用了策略。

总之，第一次接触组件模式的时候感觉很兴奋，认为一旦有了这种系统，无论策划怎么变，修改起来都是轻而易举的。于是立刻找了相关资料开始尝试实现，但是真正去实现之后才发现这玩意真不容易，越写越没思路，后来只能放弃。

后来跟一个朋友提起这个系统，然后他也尝试去弄了一下，相互交流之后感觉思路更开阔，不过苦于工作繁忙一直没时间再去弄，而且实际上对这个模式依旧是只有一个模糊的概念。其实期间一直在想办法找到可以参考的框架，那样就可以站在巨人的肩膀上去看组件模式。后来又接触了U3D，发现这玩意不正是组件模式的设计吗，于是迫不及待去看她的API，还去看了相关教程，然后就非常手痒的想实现一个看看。这时候公司说要做页游，于是就让我去搭框架，我第一个就想到了组件模式，而且第一个想法是直接复制U3D的那套。

虽然复制的话结果不需要想太多，但到了细节就不知道怎么实现了，比如实体具体该怎么创建，原型和克隆该怎么管理，最关键的是组件的动态添加和删除问题。虽然游戏中去给一个实体添加组件或者删除组件的情况不多见，但是有的时候还是想那么做，而其中最麻烦的就是组件之间的依赖问题，相互依赖的组件要如何找到对方是个问题。后来为了简单就放弃这个功能，所有组件实现添加好，之后一起初始化。最好不得不佩服U3D漂亮的解决了很多细节问题，那些细节我都直接放弃掉了，而且U3D有编辑器帮助，我们是不可能实现那样一个编辑器。同时也发现，游戏除了实体，还有很多重要的东西，比如场景管理，资源管理，GUI，与服务器的同步，以及游戏的核心逻辑等。由于刚接触网游，对怎么与服务器同步并没有很好的解决方案。场景管理东拼西凑基本上还能凑合，而最棘手的估计是游戏的核心逻辑，这也是任何框架都躲不开的一个东西。总之去写一个ARPG的哟徐，就会发现自己对状态机的把控能力实在有限，需要找时间补一补。另外棘手的还有对象间的交互，本身很多交互都在服务器完成，但是实际上加了这一步才不知道从何下手为好，因为服务器只负责结果的计算，时间过程需要客户端根据结果来模拟，于是以前棘手的“怎么去交互”变成了更棘手的“什么时候去怎么去交互”。还有资源的动态装载，虽然已经想到了自认为不错的解决办法，不过还没有去实现项目就已经搁浅了。。。

于是有时候会想，可能够用就好，可能不需要实体系统，不需要设计得太复杂，但是实际上很多时候是不知道怎么样才算够用，如何宏观的去把控一个游戏框架？感觉程序设计就是不断在和程序的复杂度做斗争，于是引用一句话：既想马儿跑又想马儿不吃草是不现实的，复杂度不会平白无故地被抹消，所以必须有所取舍。于是又补上自己的话：策划不会让你舍，你自己也会告诉自己舍弃得太多就没了竞争力。于是这大概就是写程序的为什么个个都变成苦逼的原因。。。