KOFLive Postmortem
为期两个月的团队项目完成了，我们的游戏也已经发布。在这个名叫KOFLive的小游戏里，我们集成了五个真人角色，每个角色有拳脚基本招数以及三个小招、一个大招，硬值、防御、集气、双人对战、人机对战、练习模式等格斗游戏的Feature基本上全部实现，并且做出了比较炫目的特效。无论从目前的下载量还是用户反馈来看，游戏的效果都达到了我们的预期，也算不枉这几个月的一番心血吧J除了这些，整个项目的教训也是显然的。如果说阅读《梦断代码》使我们对"软件难做"有了感性认识，自己亲自参与到一个软件工程项目中才让我们对这一点有了切身体会——不过，只要群策群力规划得当，一个软件项目总归不是难于登天的。我们愿意把我们做这个项目的经验教训与大家分享，希望对软件开发人员能有一些小小的帮助。
-
项目的选择
一个好的项目方案是成功的关键——它不仅能让你的团队得到更多的用户，更能让队员们在开发过程中充满动力——试想，没人愿意为一个"Hello World"工程付出太大精力，同样也没人愿意做一个根本不可能实现的功能：这中间的平衡需要好好掌握。另外，在选择项目时你提出的第一第二乃至第三方案，都很有可能是别人已经做烂掉的东西，这就要求我们在选择项目时，要有足够的观察力，并做足够的市场调研。
现在想想，我们的队伍在项目选择上，做的不够好：一是对项目的选择规划重视程度不够，表现在提出的备选方案太少，全队六个人仅仅提出了三个方案以供筛选，这是很不好的一点；二是最终选择的项目（链接请看这儿）最重要的Feature实现起来难度太大。整个开发流程中，我们对游戏的愿景可以说有三个阶段：
-
一开始，我们不想做太Trivial的项目，更不想基于别人已经做烂了的技术去完成项目。所以我们选择了在这个游戏里加入图像处理的部分：用户输入一张全身照片，我们程序做图像分割，再将分割出的身体各个部分拼接成人体拳打脚踢的各种动作。做的时候才发现，别说拼接，以现在的图像处理技术，自动识别人体胳膊、腿等具体部位都很难，何况在此基础上进行图像分割了；
- 之后调整计划，将目标锁定为识别人脸，即识别出人脸并将其加载到游戏内置的人物模型上。这个也比较不现实，因为游戏中大部分时间人物都是以侧脸呈现的，即使我们实现了人脸识别并分割的技术，将其加载到这样的一个模型里也比较难看，这一阶段的博客请看这儿；
- 这一阶段才是比较现实的：做一个真人角色的搏击游戏，当时我们定下的目标就是"在去除人脸识别的前提下，将游戏的手感做到最好"。事实证明，这是最合适的目标：可以吸引大量用户（我们的下载量和用户反馈证明了这一点），又有适当的难度，是我们努力拼搏四周可以达成的；
-
所以，"程序员是天生的乐天派"这个说法还是很符合实际情况的。另外我们组没有做过图像处理的组员，在MSRA我们也需要做实习工作，同时三名主力Dev还因为学分问题不得不选修清华姚班开的一门操作系统，在这么繁重的压力下去实现一个图像处理界都没有研究透彻的Feature，实在是不够现实。其实，在项目开始之前，我们不是没有就难度问题咨询过相关的专家，不过可能是不愿打击一群毛头小伙的满腔热情J 他们并没有直接告诉我们这个技术的可行性。所以，奉劝大家在选择项目时，一定要有足够好的市场观察力，肯花时间去好好调研，并要清晰认识自身能力、时间、优先度等客观条件，最好将每一步都仔细规划好，做到"大胆假设，小心求证"J
一个好的选题很重要，不过我们当时没有注意到这一点，做出选择不够慎重——这并不是说我们最终做出的项目没有吸引力，只是如果我们当时能够计划的好一些，开发过程中我们能少走很多弯路。从另一个角度来说，上软件工程这门课，最重要的是学会一整套正规的软件开发流程，而并不是说实现一个多难的技术，况且，一个很难的技术也不一定是用户欢迎的，对于一个学生团队，选择项目，不应当以"开发者"驱动，而应当以"用户市场"驱动。
-
项目的执行
在Beta阶段开始的时候，PM给每位组员发了封整体进度安排邮件，邮件末尾说"希望软件工程结课时，我们能说出一句："We're proud of each other""，现在快结课了，我们认为每个人都值得小组其他成员的这一句话: We're proud of youJ 项目执行的两个阶段，尤其是Beta阶段，无论是PM/Dev/Designer/Tester的紧密配合，还是目标改变后的紧急调整，以及发布之前的紧密测试和应急计划，我们都做到了一个良好软件开发团队应该做到的。
-
良好的设计架构和清晰的接口。我们的Dev们有着强大的单兵作战能力和丰富的工程经验，他们设计了一整套高效的游戏支持机制，整个工程有着清晰的层次架构：
-
最底层的游戏引擎负责图片的透明化、放大缩小、去锯齿、渲染、翻转等操作，并进行图片像素级的碰撞检测和音效支持。
-
中间一层是基于引擎的游戏运行逻辑层，在这一层我们进行人物招数和状态转换的设计和加载，实现攻防判定、血气管理、输入检测、AI机制、纠错机制等等。
- 最上一层负责整个游戏的流程判断：启动、终止界面的加载、用户选择流程的分支等。
-
-
我们三个层次不同的功能模块之间定义好了完备清晰的借口，极大提高了Dev分工合作的效率以及Designer设计招数和特效的效率，并方便及时查错（要知道设计游戏时，游戏引擎在进行毫秒级的不断渲染，Debug是很难通过IDE 设置断点来实 现的J）如果可能，我们也乐于开放自己的源代码，供大家参考指正。
-
专业的招数设计和特效制作。我们的Designer中有拳皇游戏的骨灰级玩家，对每个人物的状态转换和招数设计有着很好的设计（这可是一个参数一个参数调试慢工出细活的过程^_^），同时也有精通PS特效制作、研究过用户界面的同学，制作出的效果十分炫目，不信，自己下载游戏看看吧J 大家分别发挥自己的特长，进行充分的合作，保证了游戏的质量和进度。
- 严密的发布前应急和测试。我们一直有一个理念：发布日期定在那里，我们要在此之前发布，并且应当对用户负责，不能让用户使用一个Bug很多的花架子。所以我们进行了清晰的进度规划，大到周，小到半天，应当完成的进度十分明了。同时我们进行了有效的发布前规划：
-
AI机制在发布周之前都没有涉及，我们制定了应急机制：在目标上降低需求，做出一个让用户不能轻易打赢的AI版本即可， 在实现机制上我们提前设计好了随机性的AI贪心算法，并预留出了相关的接口。事实证明这套机制是行之有效的:我们的AI只用了周四一天的时间完成，经过相关测试，周五游戏就发布了。但AI效果非常好，电脑出招很犀利，（有的角色甚至让玩家惊呼"Bug" "Imba"J） 刚刚上手的玩家很难打赢，这无疑能刺激用户接着玩下去^_^
-
频繁的健壮性测试。每当有人要Check in一个新版本，我们都规定他自己要进行近乎变态的测试：长时间的乱序键盘输入检测。这一点在发布周执行地更频繁：每当有人Check in一个修改比较大的版本，我们都会组织两个人在电脑上打一打，疯狂的敲击键盘J。事实证明这也是非常有效的：我们大部分的Bug都是这样测试出来的，并且我们保证在发布之前这些Bug都被及时修正。在Test Report中，我们报出的"可以发布"的结果，是切实有效真正对用户负责的。
- 发布前整流：在临近发布前两天，我们兵分两路：PM和一个Dev进行发布的所有事项准备，Branch一个发布版本用于制作安装包、测试、撰写说明文档、确定下载站点及统计方式等，其他人员接着做之前的事情。这样保证我们发布时不会手忙脚乱，出现各种意外情况。
这些措施的实施，使我们提前两天发布了游戏 ，并且到现在没有收到用户反馈的任何健壮性问题，我们保证了我们最一开始交付给用户的，即是一个健壮合格的产品。
-
有效的时间管理。由于我们在确定实现的基本Feature时有过一些改变，所以真正开发起来时间显得很紧张，我们必须保证大家都能充分利用时间，为此我们有以下机制：
-
修改了Scrum的流程，如果一个Daily Scrum没有讨论出真正必要的东西，我们为什么又要花那么多时间呢？所以我们规定：每天的Scrum不一定必须大家聚在一块儿，只需由PM调查每个人的进度，并将每个人的进度通知其他人。PM应当对整个项目的进度有很好的了解，当PM认为有必要大家在一块儿商讨时，我们才会专门去会议室讨论清楚问题。在每次Scrum之前，我们都提前确定了本次需要汇报给其他人的进度以及需要讨论好的问题，确保会议时不会因为冷场而耽误整个组的时间。这样我们聚在一块儿的Scrum基本上两天一次。事实证明这是非常有效的沟通合作手段。
- 我们会充分考虑每个队员当前的时间安排：毕竟有队员会在某个时间段因为组里面有deadline而时间很紧张，我们会平衡每个人的负担，将他的任务适当转移给其他的队员，大家也都能做到互相体谅互相帮助。
-
总结：尽管降低了难度，但不借助外界引擎开发一个完整的游戏，毕竟还是很有难度的。队员们在四周的开发流程中圆满完成了开发的任务，交付给了用户一个负责任的产品。可以说，我们在项目选择、计划阶段有考虑不周的地方，但在真正的开发过程中，我们的个人努力和团队合作是高质量高效率的。
回想这个KOFLive开发流程，我们经历过计划大改的阵痛、成员意见的冲突、通宵工作的劳累，也经历过目标实现的兴奋、初具雏形的喜悦、游戏发布的欣慰，不管最终结果怎么样，这样一个过程让我们真正了解了如何做软件，更重要的是如何与他人合作：说服他人以及被他人说服J 这是让我们感激彼此的重要原因。
最后，上张合影， We're proud of each other!
