集え！勇士の名の下に --《勇士online》研发回忆录 2

本文是用第一人称记载的真人真事，里面涉及到了大量他人的名称等信息，所以为了避免不必要的纠纷，谢绝转载

在2007年的上半年，整个开发组对于游戏要做成什么类型，依然是处于“摸着石头过河”的阶段。其实当时，开发团队内部成员，就连什么是“格斗游戏”这一概念都还很懵懂。那时候，就是各有各的理解。这也反映出中国游戏业确确实实处于很原始的初级阶段，就连术语都没完全统一。有人把一直所说的“格斗游戏”，理解为英文术语的“combat game”。而有人则理解为“action game”。乍一看来，两者都是即时性的打打杀杀。但在具体实现上，对游戏画面的表现上大相径庭。

按英文直译，combata game就是所谓的“格斗游戏”，通常都是一对一单挑的模式。强调细微入至的攻击判定；强调动作招式的细节和表现；无论是攻击者还是受击者都有丰富的攻击受击表现。代表作有《street fighter》，《King of Fighter》，《Tekken》等。比如下图就是：

姑且不讨论street fighter 4有没有引入物理引擎去实时计算动作，就单看表现，上下两图Zangief都是处于受对方腿击的状态。第一个图是Sakura的冲天踢，这时候Zangief是处于被踹飞的状态，第二个图则是Sakura跳跃攻击踢中zangief的头部，这时候Zangief的受击表现是向下扑倒。如果Sakura是采用攻击下盘的扫堂腿，则Zangief的表现就应该是摔个仰八叉。而如果攻击者不是Sakura，而是有灼焰脚招式的feilong，那么受击者的被击打表现就应该是被烧焦了：

而action game更多被翻译为“动作游戏”。典型的就是《Prince of Persia》。相对于combat game，动作游戏的动作招式较为粗放单调，攻击判定要简单得多；仿真度没combat game那么高。而且更多是用在一些主角一对多的通关类的游戏——马踏连营一扫一大片的酣畅淋漓的感觉是动作游戏的最核心体验。比如，攻击方用“A招式”攻击受击方。基本上这个“A招式”是不分“打到受击方的上半身”或者是“打到受击方的下半身”的。在所谓的“搓招”，即“通过不同的按键组合释放出不同的招式”的要求上，大部分动作游戏不作要求。而“搓招”的熟练与否，却是鉴别一个combat game玩家，是骨灰级玩家还是菜鸟玩家的重要标志。

除了到底要做成“combat game”，还是“action game”尚未完全统一之外，对于这个游戏要做成一个纯竞技竞速休闲类的游戏，还是要做成一个大型的RPG，在整个开发团队内部也并未完全统一思想。2007年的中国网络游戏市场，正是MMORPG泛滥之际。托“一人有代码就全国有代码”之福，短短三四年，市场上就充斥着良莠不齐的RPG游戏，各运营商的推广运营手段层次不穷无所不用其极，市场竞争相当残酷。一个RPG从研发到运营都是要重金投入的。而且越往后推广费用就越夸张。9you是靠代理了《劲舞团》起家。作为一种音乐类休闲游戏，在当时可谓是异军突起。正因为这个原因，王先生的“不趟RPG这趟浑水”，在当时就作为整个公司战略思想。所有开发组，都围绕着“做休闲类游戏”这一指导思想去做。厦门这边也不例外。另一个项目《劲爆滑板》就是一个竞速类游戏。而我们这边的项目，也起了个暂定名了，叫《格斗飞人》

当时主策的想法还是偏向于做成一款RPG，整个世界观的设定都是按RPG的方式去走的。但问题就在于这和整个公司的战略思想相悖，能不能通过高层那关都是个问题。所以做成一个竞技场挑战模式的休闲游戏；和做成一个做任务角色养成的RPG两种截然不同的想法，同时存在。并且左右摇摆不定。整个游戏世界观也在不断的折腾反复。而程序组这边没法去等策划案最终敲定了，才能动手去做。而是要对一些确定的东西要先行一步了。在反复摇摆之后，最终定下了“场景及视角是横版卷轴”这一模式。

现在回头看来，当时定的“横版卷轴”这一模式，意义深远。因为在后来这款游戏处于夭折边缘而可能要改成什么别的游戏的艰苦阶段。这一模式始终都没变换过，而坚持这种既定的模式，无论是在程序实现上，还是在美术资源的制作上，都避免了大量的无用功。试想，如果当时不坚持这种模式，采用45度俯视角，或者就是全视角的方式去制作的话，所有的代码逻辑就得重写，所有的在横版模式上可以取巧制作的美术资源，尤其是场景和特效，就不得不重做。带来大量的人力浪费不说，更重要是“冷了兄弟们的心”，对士气打击是很严重的。时至今日，一些拍拍脑袋就要求这样要求那样的老板们，在决策时，是否真的从各个角度去权衡过呢？

约在07年4月底定下来场景视角模式之后，程序这边就开始着手编码了。此时我入职一月多。对Gamebryo-PhysX能做到什么程度已经有一个较清晰的了解。正如前面所说，Gamebryo-PhysX的功能实在是太弱了，根本无法去实现逼真的打斗效果模拟。所以开发组决定，暂缓使用物理引擎，我也先做其他客户端前期开发工作。和CQ一道，都先把Gamebryo系统摸熟再说。

约在2007年5月底左右，原来的客户端程序yuanhui离职，CQ接手yuanhui原来的客户端框架搭建工作。囿于yuanhui的经验和专长等原因，对他写的那个框架，开发组的评价并不是太高，对此的评语是“像用做一个2D游戏的思路去设计的”。因为写好的代码并不算多，CQ决定重写一个客户端框架。第一个短期的目标，就是作一个登录场景和一个新手村场景，要让玩家能登录到新手村中去漫游。2007年的3D游戏，玩家可以换装已经是很普遍的功能了。所以我先行做换装功能的相关的基础搭建，以及实现一个换装编辑器。以供策划和美术使用。

换装功能不难，我在tencent时已经做过类似的工作。只不过在tencent使用的是封装了Gamebryo的gfx框架。而这次是直接用Gamebryo编写而已。方法很简单：假如视为某个部件模型，比如穿着在躯干上的铠甲为A，视整个角色模型为E，原来穿的铠甲部件模型为OA。首先取得A的蒙皮数据S，根据S取得附着在其上面的骨骼数据B。然后遍历去整个E所有的和B同名的骨骼数据EB，把EB设置到S中。最后就把OA那一部分的模型从E中卸载掉，再把A挂接到原来的OA所挂接的地方就可以了。

如果用烧伤植皮手术去理解这个换装过程就很直观，首先把新皮肤和肌体做一个排斥测试，如果新皮肤和肌体不发生排斥反应（也即把EB能设置到S中），那么就把烧伤的皮肤给做个清创手术（OA从E中卸载掉），把新皮肤植上去（挂接A到E上）。换一个部件是如此，换多个部件实质上就是重复上述的过程。如果把每一个部件的换装数据描述组织成文件，用一个外部工具去生成的话。就成了一个换装编辑器的工作：

换装功能的客户端表现层实现后，对应的相关网络逻辑也就不难描述了。在服务端，每一个玩家都有一个称为“外观包”的数据结构。这个数据结构描述了当前组成每一个玩家角色模型的各种部件的ID值。当A玩家换装后，就把换装的部位的新ID值发给服务器，服务器则再广播给区域内其他玩家。其他玩家的客户端代码将会同步地显示出换装后的A玩家的最新外观。

约在07年6月份左右客户端就已经完成了换装功能，算是先行一步。相关的换装服务端逻辑安排在较后的一段时间才实现。这时，在场景的实现和数据组织方式上，程序部和美术部之间，还有客户端程序和服务端程序之间，发生了争论。