从Aplha发布周期分析：如何成功运转一款EA游戏

上个星期，我发布了Cogmind的第10个Alpha版本，我们一直在致力于终止游戏的alpha周期，现在就是一个合适的时机，让我们回顾一下每个发布的版本的开发过程中的思考模式，回顾一下至今为止我们在一年内不断重复的周期。

当然，我要讲的不只是游戏开发本身，我还要讲一下在这个开发过程中我是如何利用社交媒体的，因为在社区进行游戏的延伸与互动对于一个成功的独立游戏维持与增加必须的用户是非常重要的。（对于没有进行广告宣传的游戏，你在社区中做出的努力都是面向你的潜在用户的）

希望通过我在这里分享的方法能够让其他游戏开发者有所收获，还有能够让玩家在等待一个新的重要版本发布时能够更好地理解在屏幕之后在发生着什么。

一个月

如果没有特殊情况或者是来自外部的干扰因素，我的目标是每个月都能发布一个alpha版本。

我发现，如果我们超过一个月没有对游戏添加新的内容或是新特性，玩家就会开始逐渐失去兴趣。我相信合适的游戏时间长度是随着游戏改变的——比如说在游戏社区大家比较喜欢的游戏内容会在各个版本中走得更远。

更短的游戏发布周期也是可以的，比如两个星期或者不到两个星期，但是这也有它的问题。这就意味着每一次新版本的发布都不会有很多实质性的改变，因此不会令人印象深刻，缺乏令人印象深刻的更新，那么谈论游戏的人就会变少。

所以，从市场营销的角度来说，将你每一次发布的游戏作品改变稍微大一些是比较好的，这样做可以提升玩家觉得这个新版本值得一玩的可能性，因为我们有足够的时间对游戏的各个方面进行开发，也就是我们要在新的游戏内容方面下功夫，在玩家经验的基础上对现有的机制和内容进行优化，对之前发现的问题进行修复。

作为一个全职的个人独立游戏开发者，我们在每一个新版本发布之后还有剩余的任务要处理（例如社区里的事情），这对于推广你的游戏来说比维持不可持续的现有进展（它们很容易被各种事情淹没）要重要的多，我们需要在吸引玩家还有内部的游戏开发之间不断努力。

因此，一个月的更新周期可以在获得足够多的进展的同时，还能够保证不让玩家等待太久。我的周期分为三个不同的阶段，下面我将详细地讲一下各个阶段的细节内容。

简单来说一个周期的过程就是像图上那样了，不过这几个阶段还有很多细节内容。


*无论如何，一个月是最理想的了。回顾Cogmind以前发布版本的日期，实际上我们版本发布的间隔一般都是五到六个星期。这就是由于上面我们所说特殊情况和外部因素，包括持续几个星期的社区活动，还要绕道进行游戏世界中大的特殊部分的技术基础的构建。我每个月还会至少写几篇博客和其他的文章（就像这篇一样：p），这样的话，发布的时间就会往后挤一挤了。

阶段1：新内容

在新周期的前两个星期，也就是这个周期前一半的时间，我们都要完成新发布版本的主要内容的开发。对于Cogmind来说，这就意味着我们需要开发地图、lore、NPC、对话、剧情，以及和上面这些内容配套的项目。

所以，通常来说我在每个新周期第一天都会在纸上画出新地图的布局，然后得到我的mapgen utility需要符合标准的参数。


对于每个新地图，我还会写一个文本文件，这个文本文件描述了我的地图布局、居民、特殊遭遇，以及对游戏挑战性可玩性的总结，以及它如何融入玩家的长期游戏策略之中。这里就是一个回收地图的文本文件的例子，这是一个很少会涉及到的地方，但是它会给你一个清晰的想法。（警告：尽量不要剧透哦：特别是在大家还没有玩过这个地图的情况下！这就是为什么我不能真正地向你们展示其他/更好的地图的文件——剧透实在太糟糕了。

上面讲的是一个非常根本的过程，因为有时候地图可能会表现的比你写下的信息还要好，但有时候恰恰相反，你需要来回进行一些调整，直到地图可以适应游戏。

当地图总体上已经达到预期，能够按照期望运行，那么我们就可以开始进行细节方面的问题了，例如prefabs还有其他之前已经列出来的内容——只有所有的内容结合到一起才能让一张地图变得有生气。

在一个周期中，新的游戏内容总是第一位的，因为新内容是新版本最大的组成部分，而且我们很难准确预测新版本全面实施意味着什么。也许一个新的区域需要一个新的机械来搭配它？或是一个已有的系统需要进行扩展？如果新版本的发布时间已经临近，那么小的问题一般都可以推迟到下一个版本，但是如果一个新的重要的alpha版本没有完成新的内容那么这就违反了我们的目的：P。因此，尽早完成版本的新内容是比较安全的，完成这些新内容有利于我们以后安心进行进一步开发。

外部交流

当谈到推进Cogmind的开发时，我的目标就是每周最少有一张（如果不是更多的话）图片或是动态图片能够总结这一周的开发内容，这在第一阶段是最困难的方面，因为这总是围绕非视觉元素的内部开发或是我不想要破坏的内容。有时候就是没有什么能够分享的东西。

为了不破坏这一条原则，我可能要将周五的时间花费在我能够展示出的快捷UI/可见特性方面，这只是为了保证我能够展示出我这一周做了什么。与玩家和追随者一起探讨游戏开发的新内容对我来说是一种激励，而且从其他人的角度来看，他们可以看到，是的，我们对于游戏开发有一些进展。保持信息流动是很重要的。

无论我做了什么，我通常都会先分享到我的推特，如果Cogmind在其他一些论坛得到了很多关注，我有事也会在这些论坛进行分享（Bay 12, TIGS），这都取决于游戏本身。


在每个星期结束时，我也会将我所做的事情分享到 /r/roguelikedev'sSharing Saturday，我通常会讨论任何我发到推特上的内容，然后以此为基础写一篇新的文章，把任何发生的事情作为笔记加上去，比如博客上的帖子、新版本的细节、以后的开发计划等。

但是在这一阶段的最后，我们就应该在 forums和/r/Cogmind发布一篇关于游戏进展的报告了，对最近的进展进行汇总。然后，让游戏圈里的玩家保持兴趣也是非常重要的，更不用说是早期玩家给我们筹资进行游戏版本开发的时候我们应该做的事情了。他们有权利知道，而且要发布几个字来告诉每个人当时的情况也不是什么难事。作为参考，这里是alpha版本的最后两个更新： 7/21，7/28。

阶段2：新特性

下一个阶段就很短暂了，一个星期用来开发一些大的特性（也可能是两个星期），可能是力学方面也可以是UI方面的，这些都需要由对游戏的分析，还有衡量哪些需要添加的东西更加重要，更加有需求，或是当时具有更多可行性来决定。

对于alpha10版本，新特性就是lore收集UI还有闪避总结窗口，对于alpha9版本，新特性就是交互式机械检修，对于alpha8版本就是实时FOV更新等等。


关于可行性方面，早期的话没有比实现lore UI更有效的方法了，因为在alpha8，alpha9之前我们都没有添加现在我们设计出来进行读取的好的部分。如果在那之前就实现了，那可能我们还有必要在之后回去进行调整，这就意味着我们在浪费精力！我从来不根据我想要做什么来选择在什么方面下工夫，我选择的是在当时我应该做的事情，当然，这是考虑了所有综合因素之后作出的决定。

这一阶段做的工作和第一阶段做的工作算是一对，因为它们都是在进行所有玩家都能够体验到的游戏特性。保证每一个新发布的版本对于每一个玩家来说都有新的特性是非常棒的一件事情，尤其是对于那些没有接触所有新地图或是新内容所必须的知识和技能的玩家来说。（尤其是在最近的几个版本更新中，因为这些东西离游戏的开端越来越远了）。

外部交流

与第一阶段相比，这一阶段更容易与大家一起分享，因为这不包含任何剧透的成分，而且开发结果更值得进行展示与记录（GIF！）。在第二阶段推出的大的改进也都是在上面提到的那些平台与大家分享。在这个星期快结束的时候，是时候进行另外一篇更新了。

阶段3：小更新的填充

马上就要到发布新版本的时候了，最后一个星期（或者通常是最后三四天）让我们非常兴奋。加速更新通常都是令人兴奋的：）。

第三阶段通常起始于对TODO列表的回顾。我主要是通过一个文本文件来组织游戏研发的，这个文本文件包含各项高优先级任务、特性需求、已知bug、以及由游戏性测试和阅读alpha版本玩家体验得出的系统改进、我们能够进行提升的各种想法、一直到低优先级的长期的“可能要进行”的东西。还有在第三阶段之外的开发时间，这个列表会随着新项目的加入更新优先级顺序（新项目通常是优先级最高的），当然，依据先前发布版本的运行效果和其他的因素，优先级在每个发布的版本都是会改变的。

因此，首先要做的事情就是先解决列表顶部的哪些内容，如果要完成的实际任务数量能够包括下一版本要更新的那就更好了，我们可以将它们按照优先级顺序重新排列。

然后，前一阶段只关注新的事物，这一阶段就包括了开发的所有的三个部分：普通的新特性、对于现有内容/特性的更新以及bug修复。

所有的bug都设为最高优先级，因为只有修复了所有的bug之后我才回发布新版本（通常这些bug都不是很多，而且也不是非常严重的bug）。在这一个alpha周期结束的时候，上一个版本所有的bug都应该已经找出来了（大多数bug我在自己玩这个游戏的时候就已经找出来了，因为我知道所有东西的运行原理，我可以轻易地找出它们），所以所有的这些bug都可以立即解决。

除了要根据估算实现这些项目的时间划分优先级，剩余的项目都根据第二阶段认定的相同因素进行优先级划分。


这是在alpha10版本记录的优先级列表大概的样子。这个文件被命名为changelog.txt，因为这份文件包含了现在和所有以前的更新记录，早期版本的更新放在最下面，现版本的更新放在最上面，所有的TODO项目放在中间，这样的话我们完成了TODO项目就能够迅速记录下来，然后迅速转移到更新记录上。

注意到已有的列表主题可能与论坛上的跟帖、一些其他网络位置甚至是一个玩家的名字也是有联系的。每当我遇到合适的主题，我就会保存这个主题的讨论链接，一旦我忘记了一些细节的东西，这些链接对于我的参考就显得非常有价值了（当然有太多方法来记录这些问题）。也有一些推理会是已经完成了的——通常包括当时我自己的观点——从而缩短了开发的实现过程，并且与我自己最近的想法相比，还能够提供许多不同的观点。

就像前面提到的，如果新版本发布日期临近的话，我们可以将这个列表删减一下，这就是为什么我们要将它保存到最后。我会反复对这个列表进行研究，直到我已经没有时间了，然后这个列表上没有完成的事物就会被推迟到下一个发布版本的工作之中。

然而我在这个阶段的工作量不完全是由时间决定的。就像第二阶段开始时“充实每一个人”方面的内容一样重要，在这一阶段，我们要保证的我们的更新日志达到一定的长度。是的，取决于行数的更新日志长度：P。仔细推敲，更新日志的长度不是新发布版本优秀的质量指标；毕竟，一个单一的项目可能只要花几分钟就能够实现，然而另外一行可能代表着我们一整天的工作，甚至可能更长！尽管如此，更新日志的长度也是很重要的，所以如果发布迫在眉睫，然而更新日志还没有达到规定的长度，我可能会选择推进一些小的任务来将更新日志填补到足够长度。

此外，我们已经知道从经验的角度来看，发布新版本是很好的，因为这个更新是我们最前面几个星期付出的努力来保证的。

外部交流

这一阶段是外部看来最高产的阶段了，因此我们肯定有很多图片可以与大家分享。现在离发布的时间已经不远了，所以在这一阶段的最后我将新的东西进行截图，记录一些动态图片（LICEcap很好用，我用gifsicle来优化结果），然后将这些图收集起来，放进一个“即将到来的更新”的帖子中来代替游戏更新标准。 这里 是Alpha 10的例子. 还有aplha 9。（这些都会发布到subreddit。）


如果某时我在那里发布这个帖子通常就暗示了我将会在接下来的一周内发布新的版本，不过我从来不会宣布我在某个特定日期更新，因为任何事情都可能会出错，做出一个可能随时被打破的承诺毫无意义。

在这一阶段我们也有很多的图片可以与大家分享，我们可以间歇地在推特上分享这些图片，我们通常在推特上给他们标记为#screenshotsaturday ，我们就能让更多人有机会接触到这款游戏。

测试预先发布测试是很重要的，但是就先正式发布之前很短的时间内告诉我新特性新内容开发的方法意义也不是很大。我们在游戏中添加的新的元素都经过广泛的测试，这些测试基于我们事先准备的在实施更新之前以及更新过程中潜在问题的列表，在每一个阶段我们也都考虑了不同的需要注意的问题。无论是在头脑风暴，设计或是编程时，我都在背后不断问自己“这里会发生什么问题呢？”，然后记下所有的可能，所以一旦一个新特性完成了，在那个列表上所有的情况（这可能有好几个项目那么长）都会进行准确地测试。从本质上来说这是一个质量保证的工作，只有在这种情况下，我对于源和系统的精通可以让想出假设的问题变得简单。利用我们对于新系统和背后代码的高度理解，将这个过程集成于新特性的开发中也会提升开发效率。

在测试一个特性之前，列表中任何可能会影响其他测试项目的移到顶端，几乎每一个源代码的改变都要在转移到喜爱一个项目之前立即编译成一个新的bulid进行测试。编译的过程很快，因为我们是在调试模式的帮助下进行游戏方面的测试的，在调试模式下，我们可以很轻易地进行传送，产生对象，显示地图，以及从根本上控制游戏的任一方面，只要这是我们证实问题或是反证问题所需要的。在玩家遇到bug之前解决这些bug是一个值得追求的目标，对于快速设置测试场景来说，要想保持工作尽可能的高效，一个好的调试模式是必不可少的。

在阶段1到阶段3个过程中，我们没有必要设置一个专用的测试阶段。但是在游戏开发的过程中，复杂性随着相互系统的发展的迅速扩展，很难完全预测出结果。有些问题不可避免地会被玩家所遇到。但是测试在游戏后期预防严重问题方面仍扮演着重要角色：它可以通过认定找出代码中会引起崩溃或是已知错误的代码。我们有一个很好的方法在版本发布之前解决这些问题：自动化测试。

自动化测试的目标当然就是获得最大的覆盖率，对此我有两个主要的安排。

第一个就是针对地图的生成，这是一个复杂的过程，在这一过程中我们构建初始布局。利用脚本定义初始布局的内容。在这个测试中，游戏正常地开始了，加载第一个地图，选择一个随机的出口然后构建下一个地图，然后在我们重新开始这个游戏之前不断重复这个过程知道退出游戏。


第二个自动测试主要是针对人工智能行为（包括中央的以及个体的），战斗和游戏中许多其他的力学，我们希望能通过不断重复加载不同的地图以及互相匹配大量不同的对手来让奔溃或是bug的情况能暴露出来。在这里，这种奔溃或是bug有上百种。想想在这个游戏世界中全部都是机器在执行它们常规职责，那么这个世界就非常乱了，对于测试来说，混乱就是最好的。


人工智能/力学自动化测试。这一过程在四个独立游戏中同步运行，这四个游戏都会整夜的进行测试。如果这四个之中每一个都没有遇到任何问题，那么对于准备游戏新版本的发布就是安全的，另一方面，如果确定遇到了任何问题，那么这四个测试程序又将运行一整夜。通常玩家会被传送到一个很远的不可达到的位置，这样就不会干扰到测试了（对于他们来说就是跳过了），但是如果你想要看一些AI方面的问题，我把它们记录在了这里。

测试通常会与阶段3的后面部分重叠，因为最坏的情况可能是要把这些弄好要画上两三天时间。最坏的情况可能就是玩家在游戏时游戏奔溃，所以让我的电脑先进行这些上千种情况是至关重要的——因为我的电脑从不会抱怨游戏奔溃。

发布准备

在发布的前一天，我们要做的就是将游戏打包然后准备将它发布出去。

为了保证我没有忘记一些东西，我按照下面的清单循序渐进地进行检查：


一旦游戏压缩完成，我对它进行解压然后运行以保证这个刚刚完成的游戏副本能够按我们期望的那样运行，这通常会演变成几个小时的游戏测试，主要是这很好玩（我根本停不下来：P）但是这也是为了找到明显的错误。平均起来，我通常会在这时发现一个错误，所以我在压缩之后都要运行试试，然后再做一个新的可执行文件。

然后我会预先写下明天所有的发布公告：


第一个准备也是最重要的就是发布说明，它可以比更新日志更深入地解释这次更新的主要特点。（比如：Alpha10发布说明）然后就是针对 /r/Cogmind进行格式修改，以及为其他论坛准备的简单版本。

对于这些公告我每次也都是按照类似的格式写的（有时也会根据情况做一些改动），有一个模板可以参照，在模板上进行修改可以省时省力。

我还会对更新日志进行截图，然后将这个截图发到推特上。我通常会通过高亮来将值得注意的内容凸显出来，所以对于那些只想要了解大概内容的人也能够轻易阅读这个列表。这些高亮的地方我也都会将它们复制到我发布帖子的论坛上（还有subreddit）。

整个准备过程就会占据这一天的大部分时间。

发布日

发布日通常是在周二或是周三，因为

1、这个时候会有更多的人关注社交媒体，所以得知更新的可能性更大（包括有些从没玩过的人可能会第一次听说这个游戏）。

2、在这一天立即下载更新的人更少，这就意味着我可以在一个问题影响太多玩家之前，做一个热修复补丁（如果有必要的话）。

3、我不想在周末处理问题，因为周围一般都是家庭时间。

4、周二周三发布新版本，那么我就可以在周一做左后的准备工作，上周末的多余时间我可以用来进行更多的自动化测试，因为这时候我一般都不会将我的电脑用于游戏开发。（测试必须单独进行，因为我的开发设备是一个五年前的老旧的便宜笔记本。

要将发布日期定在每周特定时间的另一个原因就是一个aplha周期可能会多花几天时间，就像我在开头提到的那样，因为我需要等到下一个窗口。

在发布日之前我们所有实质性工作都已经完成了，在早上的第一件事（实际上在美国是晚上，因为大多数玩家都是在美国的，而我是在亚洲）我将会打开我事先写好的注意事项，然后一件件完成它们——在各种论坛，subreddit，YMLP，推特，脸书，Rogue Basin等等。


所以我大多数都是按计划进行的，因为我在早上总是不在状态，如果前一天熬夜的话那就更严重了，所以我要保证发布的时候一切有序进行。

准备好了之后我就会在fastspring上更新最新版本，这是个分配系统，在这里每个人都能够下载到最新的版本，但是在技术上他们不清楚有什么更新，直到我发布了公告。


这里就是能够让一切完成得很快的地方，因为如果一个新玩家在我上传新版本的中间进行购买游戏那就会变得很麻烦，比如说下载一个比之前分享的游戏版本更新的版本。

只要游戏文件准备好了，我就会立即上传服务器文件，这个文件包含了更新新闻还有最新的版本号，它可以提醒打开游戏的玩家现在有新版本了。

然后我就会立即发布更新公告。

发布更新

然后我就坐下来稍微放松一下。：）每一次发布新的游戏版本对我来说都是一个巨大的安慰，通常来说，以必须的紧凑步伐向一个循环的结尾迈进是非常累的，但是现在还有更多的事情可以做。

我将会更新FAQ上面的向导：


作为公告的一部分，我用WMLP向用户发送通知邮件，不过在这里我不能提供通讯服务提供商。（MailChimp想必很不错，但是对于用户量比较大的发送者来说它可能有一点贵，不过我不经常发邮件，而且我也没有很多钱XD）尽管我们一改再改，想要避免被邮箱认定为垃圾邮件，不过这些天还是有某些电子邮件提供商的很多用户将我们的邮件认定为垃圾邮件。不过现在有如此多的方式可以接触到新闻，许多玩家通过这样那样的方式来跟上我们的进展，所有我不担心有些玩家不知道游戏的更新。但是我仍然要关注YMLP发出的邮件，来看看有哪些邮件被用户接受然后打开了。


我还会注意论坛，邮件还有对新发布版本问题的讨论。如果有任何严重的问题我们会立即做一个热修复补丁，这种情况我一般在一小时之内修复。如果这天仍然是发布日，我可能会对现有版本秘密更新而不是增加一个微调版本，当然我们还会为已经下载有问题版本的用户提供补丁。每一个版本我们都会在论坛上开放反馈贴（举例）这样的话新版本的玩家不需要在论坛上另开一帖就可以进行讨论了（如果有一个地方可以让大家进行反馈，大家就更可能给我们提供意见）。这些论坛的帖子是我笔记来源的主要地点。（比如前面提到的TODO列表），我们将会根据这些笔记进行调整。

最近，根据每个游戏版本的排行榜，我已经发布了旧版本的有趣的统计数据和玩家指标。比如：


玩家对统计数据很感兴趣，游戏开发者也能从数据之中学到很多东西：

1、81%的玩家全屏进行游戏（也就是说19%的玩家是窗口化的）

2、10%的玩家用hjkl控制移动

3、21%的玩家更愿意用ASCII

4、27%的使用者只用键盘不用鼠标

大概一半的玩家使用默认字体，而其他的玩家选用了很多种字体，在这之中Terminus 字体和旧字体是最受欢迎的

在我们进行分辨率统计时，结果并不令人惊讶，因为我们可以在Steam调查结果中看到相似的趋势：46%的人用1080p，15%的人用768p，26%的人用这两个之间的粉笔那缕，12%的人用1080p以上的分辨率。

在 IndieDB上，我发布了另一种类型的公告，这种过高在更新日志旁配上了我们之前收集的旧版本的图片，但是我们在新版本发布之后的第一个星期五才会发布这种公告。

在twitch上直播新版本很有意思，这样我们就有新的每周任务了，不过稳定笔记本显然不能够进行直播了，不过我会在我买一个新的笔记本之后继续直播的：P

总结

即使其他游戏开发者不使用相同的模式，关键就是找到一个适合自己的周期，然后坚持下去！游戏和个人的细节可能会不同，但是如果能够保持一个玩家喜欢的相容性是很好的。

如果没有通过视觉更新进展和实质上的新版本发布来反复提醒玩家这个游戏的存在，我可以说Cogmid很难获得现在的成功

我经常会收到欣赏我游戏的玩家的邮件和PM，就在我写这篇文章时，一个玩家发了一个这些评论之中的一个帖子，这让游戏开发者内心感到温馨舒适，这是真的，所以我在这里把这个评论复制过来：

“不要不必要地增加你自己的东西或是什么的，但是毫无疑问，你是我见过的最好的独立游戏开发者。你的最初游戏版本本身就是惊人的。你源源不断的更新也是无与伦比的。你极低的bug水平还有连续不断的更新令人难以置信。你一直致力于用你自己的新的思路，而不是简单地尝试，只有你自己的设计才最适合你的游戏。

跟随着你的前进我感觉我见证了一个经验丰富的游戏开发团队随着时间不断扩大自己的成果的过程。

我不知道你是如果完成这一过程的。”

也许这段话在这里也有一些价值。

注意：关于标题上“成功的EA项目”，在定价之类的重要问题上肯定有一些讨论，但是如果我有时间的话我会另外选一天写一些我像与你们分享的东西！

（本文最先发布GridSage Games游戏开发博客。）

GAD编译

相关阅读：世嘉资深制作人：游戏上线前 如设计好长线运营空间