快速构建Android应用原型实践

1顶
0踩

2016-03-15 11:18 by 正式记者黑客不黑评论(0) 有5218人浏览

android 游戏

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

导读：本文作者Juhani Lehtimäki，现任Fat Robot联合创始人兼CTO，在过去三年里一直负责游戏《Lands of Ruin》的原型制作，由此撰写了自己在构建Android原型方面的实践经验。

以下为译文：

我最近更文较少，原因有两个：

Android最近优化了很多，没有太多可抱怨的地方。各家公司都开始了解：理解Android设计并进行正确的设计有多重要。最多就是说说新G+应用？
这个是主要原因：之前我一直在忙一个项目，努力将长时间的兴趣变成真正的产品。我和朋友怀抱一腔热情，开发了一款名叫“Lands of Ruin”的新型混合模式的模型游戏。这是一款Android的微缩模型游戏。
在过去三年多以来，我一直在负责构建这款游戏的电子部分（制作Android应用原型），并发现其实在Android平台上，只需使用本地原生代码，就能快速建立起原型。

缘起
在详细解释我们的工作内容和工作方式之前，先说一下我们正在做的事情。

Lands of Ruin包括桌上模型游戏以及同名的平板电脑应用。这样的应用前所未有，尽管混合型的游戏也有人尝试过，但我们的游戏跟之前那些有本质上的不同。简单来讲，我们想要在物理实体游戏与电子世界间建立平滑的交互。换成是你，要如何做呢？我们没有能够借鉴的样本，也没有可以照搬的想法，只能从头开始，从无到有地创建这样的交互。

第一步：纸
所有伟大的项目都是从一根笔和一张纸开始的。在快速原型构建上，纸和笔就是无价之宝。无需写下一行代码，就能了解需求，最棒的是，这部分的工作可以通过协作完成。智慧的头脑乘以2>所有其余的部分加起来！

我们最早的纸上原型甚至没打算画出平板UI，而是通过纸笔，找出需要追踪的地方和需要自动化的部分，这时讨论UI还为时过早。首先，在讨论“怎么做”前，我们必须先解决“做什么”的问题。

很遗憾早期的图纸都找不到了，不然还能跟大家分享一下，它们大多都是画在纸上的备忘列表。

常规迭代
在项目最开始，理解速度很快，迭代也非常频繁。我们必须为这个作为业余爱好的项目建立一个工作日常。我们的解决方案是在每周抽出一个晚上进行测试，最终决定的测试日是周四晚上，三年来一直如此。每个周四我们用目前的原型玩一局游戏，然后讨论改进想法和下一步的工作。然后为下个周四设立目标，再分开各做各的事。在未来一周内，我们会执行各自的任务计划，同时进行头脑风暴类的对话（一般在酒吧里），来解决遇到的问题。这种办法非常有效！

周四游戏夜还在继续并非偶然。不过如今的游戏夜，一般会有访客到我们办公室来，一边玩游戏一边喝上一两杯，虽然我们对互动的改进仍在进行。我们将在会话时发现的问题记录下来，希望在下个周四前修复掉。

第二步：功能性的“内容”原型，或者验证概念
在最初的纸面阶段过去后，我动手编写了第一个Lands of Ruin应用。这时我们在UI和功能的表现方式上花的心思很少，第一个原型还是用来理解应用需要涉及的内容，

在构建某个全新的东西时，有一个值得思考回答的问题：

引用

“为什么以前没人做过这个？”

对于这个问题，一般大概有三个答案：

概念太蠢不值一做；
没人想到过；
之前缺乏支持的科技。

如果回答是2，那么你有可能是在骗自己。地球上的人那么多，很多聪明人的智慧远超你我。

要想回答这个问题，我们决定：要对概念进行验证。就是抱着这个目的，我们开始编写代码，得出的成果如下：

此时的结果，无论在UI还是体验上都还差得远，不过这两者也并非我们设计这个原型的目的。这个原型让我们能够第一次真正的体验这款游戏。这个应用已经定义了有限的规则及功能，因此我们可以通过推敲，得出完整产品的规则和功能。

这个原型还有一个重大的意义，就是能让其他人试玩了。当然，最初的体验者想要顺利玩下去，需要我们提供很多协助，不过这些体验是非常珍贵的。我们能够了解到这种概念的优势，并确定继续往下做。

我花了大概两周的时间，在晚上编写代码。虽然UI几乎没有，不过核心已经出来了。游戏角色有了，动作可以执行，玩家还能用平板通过WiFi与其他人对话。

第三步——快速建立原型
一旦对想做的东西有了足够的了解，就该思考如何构建了。这时，是时候开始构思真正的UI了。我们做了差不多有15个测试版来累积经验，关于交互还有很多不明白的部分，特别棘手的就是电子与现实世界之间的连接，在我们的设计中，应用需要大致了解在战场上模型角色所处的位置。

我们需要更多信息，用概念验证原型无法测试最复杂的那些设计理念。是时候再多花些时间在应用上啦。

最开始我们坐在一起，在纸上画出想要的东西。在纸笔快速迭代阶段过去之后，我们开始利用Omnigraffle画些更具体的内容。

此时想要用纸原型玩游戏不再可行，我们用Omnigraffle线框图进行讨论，然后决定这个概念值得一试。

成果如下：

此时离直观或美观还相距甚远，不过已经包含了游戏所需的一切功能。游戏蓝图已经有了，并且运作良好，这是第一次可以按照我们预想的方式来玩游戏了，此时我们在这个项目上已经花了6个月的时间。

问题
现在，随着原型的保真度更高，我们开始了解存在的问题。尽管距离最终的解决方案还差很远，不过理解问题所在的第一步已经有了。

这时候事实已经非常明显，操纵角色并不容易，也不好玩……如果某款游戏的互动无法令人开心的话，就不能算好游戏。

我们开始进行设计迭代，并非视觉上的，而是功能上的。我们想要在小小的7寸屏上找出足够的空间，让用户很容易便能访问所有的组件。我们增加了折叠式抽屉（sliding drawer）控件，以查看更多细节；又增加了view pager控件，以快速切换角色。

下面是其中一个迭代：

下一次迭代：

再下一次：

我们不断移动物体、修调其大小并进行重排，每次都会感觉距离目标更近一些。游戏测试者越来越多，每版的反馈也越来越好。

碎片功能（fragments）非常强大
我想要指出一件事，与你听说的可能有所不同，Android的fragments在设计原型方面非常强大。

我们的游戏UI到了现在还全都采用的本地代码。作为Android开发者，这是我最了解的方式，也是我能最快得出结果的环境。截屏中可见UI的各个部分都是独立的碎片，在上面的截屏中能看到5-7个碎片，每个碎片都了解各自需要展示的内容，并订阅着中心游戏状态（gamestate）的变更。碎片之间不会直接对话，所有通讯都通过事件总线的方式来去耦。

这一架构允许我们进行快速迭代。无论该碎片位于哪里，或者其他碎片是否可见，碎片中当前游戏状态下角色应当如何表现都是有规则的。

这种去耦的事件总线架构让我可以将某部分UI完全从一个原型改成另一个，而无需担心影响其他部分，也不需要对UI进行整体调整，而游戏修改后的版本仍是可玩的。

第四步——设计
最终我们进行了足够的测试，收集了充足的数据，因此可以进行下一步了。目前的原型太过简单丑陋，很难在公开场合展示。刚好我们有个机会，参加当地的制作者盛事Make Munich，将游戏公之于众。

我们需要这个机会。我们决定在Make Munich上发布我们的游戏，因此先将这款应用在Google Play商店上架，进行封闭测试，希望能找到更多团队之外的人试玩，从而找到视觉设计人员。

Rick是LoR团队的设计师，他接受了这个挑战，成为了我们的视觉设计师。结果，我们获得了这个UI：

有了这个UI，我们就能骄傲地去参加Make Munich大会，并发布游戏啦。那时候是2014年4月。

第五步——现实给了重重一击
在Make Munich盛会之后，我们将从观众和其他试玩者那里收到的回应做以评估。大体就是这款游戏不够好，一些规则机制太过复杂，使得交互非常困难。在这款应用的很多用例中，都因UI太过笨重而导致玩家的精力浪费在平板部分，难以集中在桌面和对手上。

我们的设计准则之一就是，这款游戏必须感觉像是模型游戏，玩家应当专注于模型、地形和桌面上，因此这种状态显然是失败的。

引用

我们没能达成设计目标。下一步怎么做呢？

好吧，只能重新开始！很明显，游戏的概念还是不错的，但我们的做法有问题。必须做些什么。

尽管我们在产品的生产设计与开发上花费了很多时间，不过现有的应用版本必须废弃掉。它跟我们的目标不符。

第六步——尝试全新的东西
设计方面的最大问题在于，角色很难控制。

我们灌了几罐啤酒，开始就能做些什么进行头脑风暴，结果有了一个想法：弹出drawer，于是我们决定一试。

最终完全修改后的游戏UI如下：

尽管此时，在这个状态下游戏还不能玩，不过这个概念看起来很有希望，似乎能够真正解决我们现有的问题，很值得我们多花些时间看看。

结果奏效了，很接近得出结果。一两周之后，游戏也可以试玩了，我们感觉事情最终开始往想要的方向发展了。

第八步——优化
我们不能发布将完全是原型的东西发布出去，因此针对卡片理念进行几次快速迭代之后，我们决定在视觉上做些合适的调整。Rick被迫又做了一次asset生产模式。

初版如下：

最终，应用开始接近我们想要的方向了。在测试中出现了巨大的区别。在游戏时，平板终于成了次要的部分，成了桌游的延伸。这就是我们一开始的目标。

并不是说这款应用就完美无瑕了，不过在开发了三年之后，我们终于达成初衷了。目前实现的方式值得再雕琢一下。

在下面的迭代中，我们修改了卡片的方向，让它更适应我们使用的方式，能够在恰当的时候为玩家提供更多信息。

下面是我们得到的结果：

第九步——准备发布
目前这款应用已经包括了所有的核心功能，具备基本可玩性了。对于如何在核心之上构建更高级的功能，我们也有很好的理解。不过，应用的视觉效果还无法令人满意。之前的视觉设计都是由Rick来做的，不过他现在手边有一大堆其他任务，需要将更紧急的众筹和大会demo弄出来。

我们又找了个外援，雇了我女朋友的姐妹Natalia Kovalchuk来优化游戏设计，让它合乎标准，能够在大会和众筹中表现良好。

下面是这次设计迭代的结果：

第十步——众筹
现在到了众筹的时候，从有初始概念到如今，三年来以来我们一直在尝试让这款游戏进入公众的视野。我们目前正在进行众筹，希望能为这款桌面模型游戏的实体部分筹集足够的资金（观看视频，需自备梯子）。

英文来源：Android as a Prototyping Platform - a Case Study
作者： Juhani Lehtimäki（@lehtimaeki），Fat Robot联合创始人兼CTO
翻译：孙薇