在为期八周的开发阶段之后，我们将第一个MVP软启动，完全专注于第一天的保留时间（第二天返回游戏的玩家所占的百分比）。 几乎没有游戏后期的内容-我们正在做的所有事情都是试图弄清楚玩家是否会返回我们的游戏。 我们还忽略了所有其他有趣的东西：没有社交功能，没有使用IAP进行货币化和没有Cloud Save的机会。
此外，我们会注意随机下载的次数，用户体验和反馈。 毕竟，我们要创建玩家正在寻找并有市场需求的游戏。
MVP-生死攸关的决定
在最初的软启动测试期过后，我们收集了所有数字并做出了生死攸关的决定：我们决定是要进一步开发游戏还是停止游戏。 在这里，我们的决定完全取决于我们是否能够毫不费力地增加第一天的保留时间。 如果我们认为有可能，我们将扩大团队，向游戏中添加我们首先要说“不”的新功能，然后进行用户获取（“ UA”的简称，这意味着获得新用户）。
在Idle Miner Tycoon和Idle Factory Tycoon的帮助下，我们在第一天的保留率达到了75％-四分之三的玩家非常喜欢我们的游戏，因此第二天他们就回来了。 这些数字使我们选择“生活”而不是“死亡”，并且从那时起我们一直在开发和改进这两种游戏。
启动引擎！
在技术方面，这种开发方法是一个很大的挑战：不仅第一个可播放的版本必须在八周后发布，而且必须以允许将来迭代的方式构建。 像许多其他游戏公司一样，我们使用游戏引擎Unity使我们的这一过程变得更加简单。 Unity可以帮助我们在短时间内建立MVP：开发既快速又容易，游戏可以移植到几乎所有平台上，资产商店和其他第三方服务可以节省数周的工作。 此外，其他内置服务（例如单元测试，分析和性能报告）使每个开发人员的工作变得更加轻松。
但是，允许成功实现此开发方法的一件事是遵循代码体系结构。 代码中的体系结构将有助于编写质量更高的代码，维护具有更少错误的产品，以及编写易于迭代和易于测试的独立功能。
我们在Kolibri Games使用的架构框架称为“模型视图控制器”（MVC），这是一种简单的架构，可让我们将逻辑与引擎Unity完全分开。 我们的模型包含业务逻辑和我们的数据，并且均以纯C＃编写。 我们的控制器也处理一些视图逻辑和导航，同样在C＃中。 我们的观点是，将MonoBehavior附加到预制件（预先配置的游戏对象）上，这是我们与Unity的唯一联系点。
遵循此架构，典型的工作流程将如下所示：控制器正在读取模型，获取数据并更新视图。 在某个时候，用户将提供输入并与视图进行交互。 输入被发送到控制器，该控制器接受该输入，对其进行修改，然后使用它来更新模型。
除了简单地生成更清晰的代码外，MVC还通过多种方式帮助开发。 对MonoBehavior进行单元测试通常会花费很多精力，因为它需要将它们放置在场景中并附加到游戏对象上，因此变得更加容易：通过我们的体系结构，我们可以替换Unity组件或视图在这种情况下，具有“假视图”。 这样，我们的单元测试可以在纯C＃中运行，并且可以在服务器以及其他任何地方执行。
此外，在扩大项目规模并与多个人一起工作时，模块化变得越来越重要，MVC帮助我们实施该项目-通过使我们的所有系统尽可能地隔离，我们确保多个人可以在一个项目的不同部分工作功能或同时具有不同功能。 在Unity中，我们从一个空的场景开始启用模块化，在空的场景中我们使用C＃创建所有模型，控制器和视图。 一次只能在一个场景中工作一个人，这就是为什么我们不在一个场景中收集多个功能的原因。 就像预制件一样，它们不能与源代码控制合并，因此使预制件尽可能小和粒度是关键。
原型-它们是一个很好的快速解决方案，在完成其功能后通常会被丢弃。 但是，在Kolibri Games，我们建立了经过测试和扩展的MVP，而我们的MVC方法可以帮助我们。
对于一个简单的原型，您需要一个场景，放入一个游戏对象，并将一堆MonoBehaviors附加到该对象上。 这里的每个游戏对象都有其自己的启动方法，它们的更新循环，并且每当您要访问另一个系统时，只需简单地执行“ gameObject.findobjectsoftype”移动。 尽管这种方法完全可以解决游戏阻塞问题，但它完全不适合我们的专业工作流程，因为我们希望不断改进第一个版本而不是扔掉它。
最终，原型的可测试性降低，代码质量降低，可变性降低并且迭代所需的时间更长。 尽管原型制作在早期阶段非常快，但是MVC使我们在后来改进和开发游戏时能够保持恒定的速度。
尽管它颇有争议，并且遭到了许多MVP的彻底拒绝，但MVP的精益开发使我们几乎每周都可以发布游戏更新，从而保持有效并改进无效的游戏。 我们已经创建并维护了我们的玩家喜爱的游戏，至今已有大约三年的时间，并且有信心我们的方法将使我们从现在开始这么多年。
如果您想从技术的角度进一步了解我们如何遵循几乎每周的更新时间表，请确保阅读 下周即将发布的第2部分！
