时常会看到一些合作开发人员因为发动机使用不顺当或这类机能不相匹配而埋怨，那么在现今的格斗游戏产业发展新格局下，是不是必要性自己合作开发3D发动机呢？
做为曾的格斗游戏发动机合作开发人员，现在就而言说那个难题。合作开发两个发动机，要明晰四件事：
投资收益
象征意义
如何做
具体来说，须要面向全国历史事实，我曾凭借着发动机拿过许可金，但我不认为在现今国内的大自然环境，商业性发动机的适用性，以及适当的盈利模式运转里，暗鞘发动机还能产生经济价值。暗鞘发动机绝非单纯的造车轮，你须要遭遇金泽尔耗费天量的天数生产成本，使用价值几乎为零，挣钱的可能着实非常有限。我说隐晦一点儿，假如你寄希望于合作开发两个格斗游戏发动机来为了给你带来经济效益，相比之下没有你在自那儿摆香菇摊卖香菇相比之下毕竟。为何？做为合作开发人员，我要为两套解决方案埋单，不外乎就是考量四个难题：1、它与否能满足用户工程项目市场需求
对于格斗游戏发动机而言，假如不能满足用户工程项目市场需求，是难以商品化的，而你要努力做到满足用户绝大部分工程项目市场需求这一点儿，须要牺牲大批的天数和心力。2、它与否能大批延长合作开发周期这一点儿依赖于你的辅助工具链，辅助工具链虽然不是什么正经，但是两个反转形态的工作，对个人是跟两个项目组有其本质差别的。随着天数的流逝，那个差别会进一步缩小。
3、它与否能节约物力生产成本
这点是根本性难题，格斗游戏研发生产成本几乎就是物力生产成本。而物力生产成本就是合作（磨合）生产成本及学习生产成本。这些无不是基于对软件系统的熟悉程 度，也许你对自己的发动机很熟悉，但其它人不是。使用你的发动机，合作开发项目组每对个人都须要先学习再使用，这对企业，是不可承受之重;对对个人，学习你的引 擎并不能带来长期的技术储备。而相反，商业性发动机有大批的学习资料，掌握之后，在不同的企业都能运用。而至于其他，比如性能，机能等，不能满足用户以上3条，这些都只是幻影。也许你好奇我是如何拿到许可金的，我的发动机在商业性发动机早期，那时还没有Unity，UE还要很贵的许可金，我也许是最后一批暗鞘发动机的受益者。如今，必须承认的是，这一页已经翻过去了。那么假如合作开发发动机不能带来经济效益，这件事本身与否有象征意义？我觉得还是有象征意义的。到现在，发动机虽然不能再为我带来金钱上的直接收入，但带给我的是：1、规划项目组合作开发，评估生产成本，设计架构得心应手，做全栈算是附送的技能。2、更了解两个格斗游戏发动机的底层运作原理。我现在使用Unity，对于如何针对性为Unity工程项目做优化，提供软件系统有比较清晰的思路。想想假如我不知道有PIX调试这种东西，那得多可怕。3、快速地上手并深入两个商业性发动机。4、很轻易地扩展商业发动机。这些都是隐形的投资收益，对于对个人而言，也许这是可以运用一辈子的经验。所以这些，不是所谓的“象征意义”吗？那么，现在假如你有决心牺牲大批的天数生产成本做两个不会给你带来直接经济利益的发动机，如何去做？我的提议是：1、避开竞争一件有象征意义的事情，须要有其特点，造车轮也要分与否是正经。针对某两个方向，或者市场需求点去做，效果会好很多。比如在页游时代，Flash平台 做3D很难，商业性发动机都还在观望，仅有的几个框架（如Away3D等）都难以在性能和工作流上很好地支持两个工程项目的研发，我发动机做了那个跨平台支持，很自 然从中受益（这跟Unity具体来说做对移动平台支持是一样的策略）。2、从实际工程项目市场需求里提炼架构我认为没有需求凭想象力去做是很多发动机程序员常犯的错误（我也是）。因为想象出来的框架通常难以适应真正的工程项目市场需求，常常是两个技术成果想得很好，真正用起来很糟糕。3、先实现，再谈架构发动机很容易陷入设计陷阱，有时底层实现是比较复杂的，实现之前很难想清楚，时常在你耗费大批的天数做好两个你认为完美的设计后开始信心满满地编码，然后不得不为了性能或算法实现推翻你的设计。
