@钦差
基本上，盟军本身便是个高度定制的游戏，这是它不提供地图编辑器、也鲜有创造性MOD的根本原因，尤其是其中的2D地图，其非常不同于普通的基于tilemap的2D game。至今为止，我还没有看到盟2中具有任何"地形模型库"的迹象。只有an2(2D的)、ab(3D等)等"物件模型库"。

既然你谈到了思路，这个事情我曾跟rex曾谈过，这里再说说。首先，鉴于盟军地图的巨大差异，我觉得盟军Mod可从两个方面考虑，一个是2D大场景，这是rex正在做的工作，另一个是3D场景，这是我正在做的工作。

本质上，盟军是个3D游戏，其3D场景的标准化处理方式和综合而又不那么纯粹的2D场景处理形成了鲜明对比。简单而言，这个游戏其实是MOD 3D易，而MOD 2D难。目前前者工作基础已经有了，sec/mbi/abi，从场景到物件，串起来基本上就是一条明路，但后者的场景修改却还不那么明了，由于没有地形模型库的存在，2D MOD效果也很一般。比较而言，盟军的3D工作量远小于手绘2D地图的工作量，如果说简单3D MOD搞不定，那么工作量更大的2D地图MOD更加不可能搞得定。

至于3DS，有几分的实力，便能做出几分的成绩，这并不奇怪。其实自始至终，pyro都把3DS max当作"官方"的地图编辑器，abi等文件里面的.max名称充分说明了这一点，况且，这个软件使用的问题也未必比反汇编的要求更高。

最后的两个问题：
1. 精力问题：没有金刚钻，不揽瓷器活。盟军的高度定制化本身就决定了MOD的高门槛。所以我从一开始就不认为没有专业人员（至少是美工）的参与，仅靠修改/组合控制脚本便能做出漂亮的成绩。
2. 3DS文件格式。这个好办。其实pyro在编辑abi/mbi时，他们用的方法就是用3ds插件直接从3ds里面导出模型，证据就是这个.max的文件后缀和基本的骨骼模型。首先要做的是把3ds数据导出成一种简单的可理解格式(类似.anm)，这一步可以用3ds max SDK，或者用lib3ds直读，这一步骤是目前游戏制作的标准流程，资料极多，基本上不成问题。然后再用工具转换成.mbi、.abi，如果是.sec的话，还必须有工具配套来设置属性。也就是说，模型的建立，必须用3DS，而.sec属性的设置，则必须自己做了。
  回复  引用  查看