我是想参考rmxp。把游戏中的物件，像人物，地图，技能...都放在model中，把操作这些物件的方法放在controller中。
例子中直接用list来声明东西，只是为了简单说明那是个list。模板实例化应该是alias list ! (GameObj) GameObjList; ，下次不偷赖了.....
model中的GameObj应该可以不用理会用VertexBuffer这类东西。VertexBuffer的存在，本来就是为了加速显示。如何显示，这是view的工作，那就由它自动为GameObj创建好了。
这么一说，果然，只是简单的把整个view看成是一个对象Game是不行的。c/s没我YY的那么简单。人不能太贪心。 还是先考虑单机吧。谢谢你的提醒。
VERTEXBUFFER其实偶没想过应该 用这个怎么放 就直接提问了……
实际上从直观来说，你的头文件至少需要被VIEW和MODEL交叉、可选的看到……
即是说，如果从状态表征方面来看，VIEW需要的至少是每个OBJ的位置、状态、尺寸、透明……等等的信息，而这些信息肯定需要被时时的FRAMEMOVE来修改……
LIST的话偶并不是很关心……因为偶比较喜欢用数组……XD，STL用过发现会生成100-400K的尺寸立即放弃掉了……
C/S 偶以前有一个简单的模型，不过做的可能不是很理想只测试了简单的情况……CODE要的话下次放出，貌似那个还是用C++写的，不过完全没用啥LZ喜欢的设计模式……
设计模式这种东西是可以refactor出来的,没关系...
是的，如果不想用两个list来浪费内存的和CPU的话，view和model，应该是共用一个list的。其实这样并不是太好。只是没想到更好的解决办法。现在在看rails的代码，看看别人是怎么解决的。
用list，是因为它在内存中不是连续分布，添加删除元素的时候显得灵活一点。数组，容器什么的也是差不多的作用，各人的习惯吧。
exe文件的大小，这个无所谓了，我又不为便携设备写程序。（其实d的exe自带gc，想小也小不了，时间长了看得多了，对这个问题也就麻木了。 ）
有源代码时，c++移植D难度不大。但是，心急吃不了热豆腐，等我什么把单机的部分弄得差不多了，再来向你请教c/s的问题吧。
嗯，重构这个办法我一定要记住了。一开始写出来的东西，肯定不会满意，到时候就能派上用场了。
貌似会很好玩的样子XD～～～