|
|
楼主 |
发表于 2007-11-1 22:47:00
|
显示全部楼层
Re:关于委托的一些想法
最近两天忙着写世界编辑器，一直没空来这说两句，也许我的表达不是很清楚，确实，一开始我自己都没想好就说了，现在我整理了一下我的思路重新表述一下。
再解释一下委托和代理：
如果我买了台xbox360,我把它弄坏了，我想找ms的代理修，结果找不到，或者我发现那个代理不在中国，我只好找委托人去帮我解决这个问题了。
在类库或者服务方思考，我设计一套服务，那么我必须还要设计这套服务怎么服务于不同人的需求，设计代理就是解决这个问题的一个方法。
如果站在使用者和被服务者的角度看，我要需求一种服务，我可以自己解决，解决太麻烦的话我可以自己找服务，如果那个代理在我可见范围内，则我不需要委托就可以了。除非我实在一点办法也没有，就只好找委托，或创建委托。
一般我们开发游戏，引擎程序都和逻辑程序在一起，逻辑程序有什么需求只要提给引擎程序，一般都可以解决。
而且我们一般都把代理设计成全局的，这样的话一般情况下都直接用代理解决了，所以楼上的说代理就是委托。
如果引擎不能随便修改的话，如果代理的设定有严格的可见限制，那么有时候就需要委托了。
需求的产生：
UI编辑器，当时希望于UI库无关，UI库都是已经设计实现好的。
场景编辑器，于引擎无关。
游戏的场景系统。
我的思路和做法：
先说编辑器，编辑器实质上都是一个壳，要做到和内核无关也是很自然的想法。
UI编辑器和场景编辑器，站在编辑器的角度上看实质上也没什么差别，编辑器要做的事情很简单，方便游戏设计者编辑游戏中对象的属性。
我做好了编辑器的壳，用extream toolkit确实很方便，3大类一堆就出来了，而且做的和vs差不多，这也是我想要的，要什么对象直接从控件面板上拖过来，旁边是场景的对象层次关系，和属性列表，中间是显示主界面，下面一个输出窗口。
场景系统框架也写好了，场景系统的所有信息我都保存在我事先定义好的xml文件里面，xml确实牛叉，里面有继承也有模板不用它我真的不知道用什么更好了，这些反正都交给引擎的IO代理上解决。
现在我想要把游戏里的对象，3D物件和UI的属性读到编辑器里去。
这里我有个问题，很多引擎都是带了一套编辑器，我想他们的做法都是编辑器向引擎兼容了，这样做也确实没什么不好的，毕竟做编辑器简单，以后大不了重新写个，谁会为了编辑器去重新写引擎呢？而且引擎尽量保持简洁强悍也是一大卖点。
但对我个人来说，今天在这家公司，以后可能离开了，如果编辑器太依赖引擎（也是由我和另外一个程序来写），以后我写的这个编辑器就没用了。所以我打算为编辑器设计一个简单的委托方式，也就是最基本的数据结构的定义和转换。
编辑器只认委托方，但委托方是不可能直接从引擎解析出数据的，具体怎么解析交给引擎的代理，引擎根本不需要管他有没有编辑器，编辑器也不需要管他有没有引擎，反正他只负责把属性的数据传来修改再传去。
注，委托和代理肯定都是dll，如果是lib，这样做就没意义了，因为我假设不改动引擎和编辑器的情况下。
也有人可能觉得为什么不做成一个呢，把委托和代理集中在一起做了，就像一个中间件一样。但这样的话这个中间件就是把这个引擎和这个编辑器联系在一起，这也可以，不过这对我似乎没多大好处，我想把这个编辑器变成自己的私有财产。而且还有UI部分，以后可能会换来换去，感觉还是往这个目标做会更好点。
最后的工作量也不是太大，主要就是集中在，由IO的代理解析出数据后，再由编辑器的委托把这些数据转换成编辑器认可的格式，传给编辑器。
以后如果换其他引擎了（我想它是带IO文件解析组件的），编辑器部分只需要给编辑器的委托增加一种转换算法，这个可以用策略模式来解决，也不是太麻烦。
我前段时间一直在想要不要在场景系统中用委托，而我的问题大部分是代理设计的不全面而且可见性不是全局造成的。后来觉得还是不要委托算了，直接增加代理，并设成全局的，这样就OK了，在游戏中又设代理，右设委托太乱了点。反正服务多点也不是件坏事，我是这样想的。
Shall I made me understood? |
|
发表于 2007-10-30 09:04:00
