Ahyangyi@铷铯
Part 1
我今天中午采访了韩文弢前辈，他是第一届的姚班学生，因此也是清华大学里最早上邹老师的现代软件工程课的同学之一。他们那一届的软工课还没有要求写blog，他们工程的主页在上课之后也没有继续维护，所以，现在除了采访得到的结果以外，应该没有多少可供参考的资料了吧。
这个工程最初的想法是，已经有的各种游戏平台（如联众）上面有的多人棋牌类游戏，其实背后有大量的共同点，比如玩家依次行动，有一个固定的棋盘或者桌面，以及一些棋子或者卡片来作为活动元素，有着相似的用户界面，网络连接方式，等等。因此，他们小组认为，可以实现一个通用的在线多人棋牌类游戏平台，以简化此类游戏的开发流程。他们设定的最低目标是，实现一个多人的红心大战；而最高目标是实现一个多人的三国杀游戏。他们对于项目成功的定义是，在系内有一定人数使用他们的程序来玩。
他们采用C#.net平台，总共编写了约6000行代码。人工的分配是一个人负责游戏逻辑部分，一个人负责接口，两个人负责图形，一个人负责网络。
最终，他们实现了多人的红心大战部分，但是三国杀部分则没有完全实现。他们实现的三国杀没有武将牌，也没有锦囊牌，所以可玩性不高。因此，最终这个工程在系内也没有流行开来。这应该也是这个工程没有继续被维护的原因之一吧。
我于是继续提问，既然红心大战做出来了，为什么三国杀没有做出来呢？我得到的回答是遇到了多方面的困难：
- 红心大战的网络传输方式比较简单，只需要同步的传输，而三国杀对网络传输方式的要求则要复杂很多，比如需要异步的类似"抢答"的机制。（注：这个机制在人和人当面玩的时候是常见的，但是似乎现有的网络版三国杀也没有实现"抢答"，而只是按顺序要求每个人做出决策。）
- 在6人及以上玩三国杀的时候，他们发现窗口尺寸不够大，画不下场上的各种信息。
- 他们的通用平台采用了这样的方式来支持不同的游戏规则：在C#里面通过某个库来执行一些Python脚本，这些脚本来决定游戏的流程。他们希望通过这样的方式来实现系统的通用性，但是，在做三国杀的时候，三国杀的复杂的游戏逻辑给他们造成了很大的障碍。
- 开发时间不够，到了最后，他们觉得最低要求已经达到了，而最高要求遥遥无期，于是就定型成前面所说的样子了。
Part 2
问题就问了这么多，我觉得有一些似曾相识的感觉。原来，在大一暑假的时候，我Java课的大作业题目与这个类似。当然，这不是助教给的命题，而是我自己选的。之所以选择这个题目，是因为当时三国杀是一个很流行的游戏，但是还不存在任何一个三国杀游戏在电脑上的实现。所以，我当时的前景是，如果我能支持完整的三国杀规则，无论如何系内流行是肯定的，而继续向外传播的前景也是很有可能的。
同样地，我也提出了一个"最低要求"：一个多人抢答四则运算题的游戏。在简单地设计了整个程序的各个组件要做什么之后，我就开始了实现。我做了一个复杂的游戏框架，它有一个被我定制修改过的金灿灿的GUI效果，支持你建立一个服务器，然后玩家连接到这个服务器上以后可以建立游戏房间，并且可以使用一个与游戏独立的聊天室功能，并且游戏也可以向聊天窗口输出调试信息或者提示信息。当然，最终结果也是类似的，我只实现了最低要求，然后因为一些突发事件而放弃了三国杀部分的开发。并且，这个程序从此也再也没有被维护过。
Part 3
韩文弢他们小组的技术能力毋庸置疑。我一个人虽然能力上会差很多，但是至少当年的激情也毋庸置疑。然而我们从结果上来看都没有成功。在上个学期的SRT申请表上，我又看到了"通用多人游戏框架"这样的提案。我不知道是不是在上个学期结束的时候，又有谁重蹈了我们的覆辙。所以，作为一个有一定的亲身经历的采访者，我想在这里分析一下韩文弢他们小组为什么最终会不太成功。
首先，三国杀这个游戏本身有着相当的逻辑难度，而我们在开始做的时候总是希望通过添加一些机制来"简化"三国杀本身的复杂程度。但是，附加的结构显然只会增加复杂性，先实现一个通用的游戏框架再实现一个三国杀要比仅仅实现一个三国杀要来得更难。 不能因为在计划里添加了一个通用的游戏框架，就降低对实现复杂性的预期。
其次，在设计阶段，我们并不清楚三国杀这个游戏究竟需要底层部分向上提供哪些接口。我们的想法都是先设计一个通用的游戏框架，然后实现它，实现过程中使用一个简单的玩具级的游戏作为测试用例，在实现完框架之后再在上面开发三国杀。但是，因为实际上我们学生阶段做这些项目时设计阶段总是会各种不靠谱，我们实际上或多或少总会一边implement一边design。而这样做的同时我们还只拿一个玩具级的游戏来试验，最终形成的设计必然有很多不适合三国杀的需求的地方。
最后，我觉得他们小组的角色分工也有待商榷。我问为什么他们组会有两个人负责图像显示方面的任务，我得到的答复是，似乎是因为不但需要些负责显示的代码，也需要准备图形素材。但是我觉得，从最终结果来看，如果三国杀游戏做不出来的话，准备图像的同学精心准备的卡片图形也就白费了。反过来，如果这两个人中有一个在前期投入到其它几个角色之一，帮助他们解决遇到的各种困难，可能最终的结果会好很多。
Part 4
如果现在让我们组来做同样一个项目的话，首先我会建议先写好一个初具雏形的三国杀的逻辑的原型，再等下面的网络部分，图形部分和Python的逻辑控制引擎。这样话，各个模块的设计者就能设计得比较清楚。如果不是这个开发顺序，那么我们就需要设计者在一开始就把三国杀的游戏流程分析得非常详细，并且以开组会的形式确保每一个人都对我们后面会在哪里遇到麻烦比较清楚。
然后，我会建议把红心大战这部分去掉。它会消耗掉一部分的编码时间，但是对整个工程的成功与否其实用处不大。就算实现了红心大战，如果没有三国杀，这个平台仍然不会有人用；反过来，跳过红心大战，只要实现了三国杀，就会吸引足够多的注意力来注意到这个平台的可扩展的一面，那个时候如果真的有人有用这个平台玩红心大战的需求，也就不难解决了。
最后，我觉得我们要分清楚哪些特性是我们自己觉得有趣的，而哪些特性是会决定一个项目的成功和失败的。我觉得从这个项目来说，吸引参与者的主要特性是这个游戏平台的通用性。但是一方面，没有做出来一个实际能玩的游戏导致它吸引不到人气，也就没有后续开发者的加入，在学期结束以后项目就完全搁置了；另一方面，由于在制作游戏平台之后三国杀没有做出来，游戏平台的通用性本身也没有被证明，如果我做为一个具体游戏内容的开发者，想开发一个三国杀游戏或者别的棋牌游戏，我也会怀疑这个平台究竟能不能提供必要的支持。因此，实际上决定这个项目成败的特性应该是用户可以用它在线玩三国杀。
