Dev blog 07/17/2017

#devblog

很久没有写 devblog，游必有方那边也有段日子没有更新了，先跟大家道个歉。这段时间安排比较乱，前一篇 devblog 大家也有看到，就不再解释原因了。现在陆陆续续算是慢慢安定下来，开发仍然继续，节目也会慢慢恢复更新，请大家海涵。

当然这段时间暂停开发其实也给我们了一个机会，让我们大家暂停下来思考一下设计方向。小团队开发大项目，尤其是还有点新意的大项目，设计和开发的矛盾就显现出来了：一方面，仅仅沉迷于设计而不实际进入开发，就会难以意识到实际开发中可能会出现的困难，是纸上谈兵，花大量时间讨论而无法得到确实可行的解决方案；另一方面，埋头进入开发追赶进度，能看得见成品，仿佛有种工作不断进展的错觉，可是缺乏设计指导的开发，在开始阶段虽然能迅速打下基础，但是随着开发的深入，也会逐渐丧失方向。

最好的实践方法当然就是通过 playtest 的方式将两者连接起来，并减小开发周期，将功能划分成子部分并逐一击破开发，其实也就是 Agile 开发。不过这种开发方法有一个小问题，那就是所有人都需要理解这个并不是很直观的开发流程，并且按照这个框架执行。在这个问题上，大团队和小团队都有各自的难处：大团队转型期难，但是可以请专人辅助建立结构，一旦建立起来，新人加入只要随大流学习即可；小团队规模小，转型简单迅速，但是一旦有组员理解不到位，对团队的影响就更大。大家在使用这个开发方法的时候，一定要注意这些问题。

在这里也稍微讲解一下 Scrum，为同样面临这些问题的小型游戏团队们做一个扫盲。

第一步，开发需要确立一个 Product Backlog. 所谓 Product Backlog 就是一个按优先度排列的一个产品需求列表。这个列表一般情况下是由产品负责人来制定的，不过对于独立游戏设计团队来说可能是由主设计师、甚至整个团队来共同制定。

Product Backlog 中的每个需求条目很多时候是通过用户故事（User Story）的格式来撰写的。User Story 的格式如：作为一个____的用户，我想要____的功能，因为_____。
套用在游戏中，则是“作为一个___的玩家，我想要___游玩系统 / 体验，因为____ . ”
需要强调的是 User Story 并不是唯一的格式；实际上 Scrum 开发法并没有要求一定要使用任何格式，适合你团队的就是好格式。

对于游戏来说 Product Backlog 比一般 App 要难于制定，因为很多情况下文化产品的需求并不像 App 一样明确，很多时候也很难直接排序；小团队在创建初期缺乏经验的情况下也有可能迷失方向。尤其在游戏设计初期的原型探索阶段，过于严谨的结构可能会扼杀整个开发的创想。在这里，游戏团队可以采用迭代的方法，将整个游戏流程划分成原型期、绿灯期、开发期和打磨期，对于重网络的游戏还可以加入运维期。在各个时期过度的时候重新进行 Product Backlog 的更新，这样能够既尽可能地保留创新的想法，又不至于使整个系统失去控制。

第二步，团队需要根据 Product Backlog 做一个工作量的估计。在使用 User Story 的时候，这个工作量估计可以使用故事点（Story point）来预计。故事点并不需要和工作时长一致，但是必须要反映工作的复杂程度。我的教授举了一个很恰当的例子：在设定 Story point 的时候，可以把它理解成打怪的经验值，也就是把这个工作“消灭”之后需要给“玩家”（开发成员）的“奖励”。

Story point 的估计往往用一种叫“计划扑克”（Planning poker）的方法进行。 Planning poker 是这样一组牌，由 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 所组成，每个开发成员有这样一套牌。从Product backlog 中选取一个未估计的任务，每个成员为它出一张牌，面朝下放置。等所有组员均出牌之后，大家一起亮牌，并就自己所给出的估计的理由进行讨论。这个方法的主要目的是为了让大家不会被他人的估计影响，而能够独立给出自己的估计和思考。

第三步，就要进入主体的开发阶段了。开发组员从 Product backlog 中选取最重要的一系列任务，构成一个冲刺列表（Sprint backlog）。这些冲刺列表的工作应该能够在四周内完成，对于独立游戏小型项目来说，根据我们的经验，最好能够在一到两周内完成。在选取出 Sprint backlog 之后，要将其中的各个任务仔细分解成可执行的冲刺任务。对于这些冲刺任务，可以重新玩一次 Planning poker。注意在这里的 Story point 可以和 Product backlog 时作出的 Story point 不一致。

可以这样理解： Product backlog 的 story point 是一个全局的估计，它象征着整体计划的进展情况；而 Sprint backlog 的 story point 则是针对本次 Sprint 的估计，它象征着本次冲刺的进展情况。这两者是相关的，但是未必需要一致；最常见的情况是 Sprint backlog 的 story point 是 product backlog 的等比例放大，相当于对估计给出了更精细的“分辨率”，让开发组员对本次冲刺有更精准的把握。

第四步，则是实际进行冲刺开发。每天，全组成员要进行一次站立会议（Stand-up meeting）。这个会议持续时间必须极短，一般在十五分钟左右，目的是为了让组员们了解各自的工作进展情况。每个成员都需要发言，发言依照下面的格式：

1. 我昨天做了什么；
2. 我今天需要做什么；
3. 我面临了怎样的困难（例如，我的工作依赖于另一位组员的工作，而另一位组员没有完成相关工作；我需要尝试一项新的技术，而结果未定；等）

前两者是主要是为了公示工作进展，而第三项则是为了安排工作流程。具体针对这些困难如何解决，则不是站立会议的内容，而需要组员们私下会议解决。

每一天的结束阶段，都需要保证工程是可以编译执行的状态。

以我们的经验，对于小型独立游戏工作组来说，可以不必这么严格，但是仍然需要保证起码每周都能够完成一到两次的 standup meeting，以及每周都要保证有一个可编译执行的版本得以发布。

随着工作的进行，每个完成的工作都可以把相关的 story point 从计划中删去，以此则可以形成一个“时间”和“残余 story point”的折线图，这叫做 sprint burn-down sheet.

第五步，在 Sprint 结束之后，由产品负责人来决定这次 sprint 的那些 backlog product 项目是否完成，是否要接受。

以上，重复三到五步，则是一个比较完整的 Sprint 周期。

我们由于一开始就意识到了Monsterologist (怪物学者) 的开发规模之大，于是选择了偏重开发的策略，在开发进度上确实得到了从同学到教授的一致肯定。而教授给我们提出的意见，大多数是从实际玩家出发的角度，是“浅”的体验，并不是我们在开发过程中最注重的（我们总认为后期会有时间调整，因此工作重心放在了搭建框架而不是调节体验）；但是任何玩家接触游戏的时候，也都是从这些“浅”的体验入手，慢慢过渡到“深”的体验，或者说是“游玩系统”（gaming the system）。像 P 社四萌这样特立独行的游戏毕竟是少数，就连同样拥有庞大系统复杂度的文明系列也是循序渐进地展开系统，更何况是这种模拟 + RPG 的游戏呢。

所以这次的暂停，也正好让我们调整一下工作的重心。在现阶段基本的系统和玩法框架搭建起来的时点上，是时候来该细化设计，落实纸面，好好“填表”了。这也是我们下一阶段的工作目标。

感谢大家一直以来的支持，我们之后仍然会放出更新，不久后也会放出测试版，希望大家还能够继续关注 Monsterologist，关注微博 @Hi_MoE嗨盟游戏组。

================================================================

如果您对Monsterologist的后续信息和更新感兴趣，欢迎关注我们的微博：

@Hi_MoE嗨盟游戏组

或我们的专栏：纽大游戏故事 知乎专栏

进入Hi-MoE游戏组 | indienova 独立游戏 Hi_Moe小组，注册后也可以讨论或直接和我们互动。