靠谱 的软件外包伙伴

您的位置:首页 > 新闻动态 > 快速开发Android应用app原型实践案例

快速开发Android应用app原型实践案例

2016-03-15 10:50:55

我最近更文较少,原因有两个:

  1. Android最近优化了很多,没有太多可抱怨的地方。各家公司都开始了解:理解Android设计并进行正确的设计有多重要。最多就是说说新G+应用?
  2. 这个是主要原因:之前我一直在忙一个项目,努力将长时间的兴趣变成真正的产品。我和朋友怀抱一腔热情,开发了一款名叫“Lands of Ruin”的新型混合模式的模型游戏。这是一款Android的微缩模型游戏。

在过去三年多以来,我一直在负责构建这款游戏的电子部分(制作Android应用原型),并发现其实在Android平台上,只需使用本地原生代码,就能快速建立起原型。

缘起

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

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

第一步:纸

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

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

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

常规迭代

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

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

第二步:功能性的“内容”原型,或者验证概念

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

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

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

对于这个问题,一般大概有三个答案:

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

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

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

图1

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

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

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

第三步——快速建立原型

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

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

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

图2

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

成果如下:

图3

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

问题

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

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

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

下面是其中一个迭代:

图4

图5

下一次迭代:

图6

再下一次:

图7

图8

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

碎片功能(fragments)非常强大

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

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

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

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

第四步——设计

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

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

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

图9

图10

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

第五步——现实给了重重一击

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

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

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

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

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

第六步——尝试全新的东西

设计方面的最大问题在于,角色很难控制。

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

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

图11

图12

图14

尽管UI看起来完全不同了,实际上利用Androidfragments,进行配置只花了一晚上时间。所有的功能模块跟以前一样,不过位置有所不同。由于我们使用了fragment架构和事件总线的方式,这次无需进行其他变更,第二天就修改好又能试玩了。 
可惜的是这次的结果也不怎么样,我们最终也很快放弃了这个办法。

第七步——炫酷的卡片叠加方式

之前的UI不能用了,又只剩下游戏概念本身。我们不想为游戏制造更大影响了,因为我们对目前游戏所采用的方式不满意,感觉上不对劲。我们需要根本上全新的方式,对模块进行简单的重组根本不够。

这时我们想到了卡片!很多桌游都使用卡片来代表角色,也许更熟悉的概念会更有意义。还有很多游戏是处理电子卡片的,我们可以找到喜欢的游戏,看一下交互完成的情况。

第一个使用卡片的无功能状态如下:

图15

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

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

第八步——优化

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

初版如下:

图16

图17

图18

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

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

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

下面是我们得到的结果:

图19

图20

第九步——准备发布

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

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

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

图21

图22

图23

第十步——众筹

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

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

关于:中科研拓

深圳市中科研拓科技有限公司专注提供软件外包、app开发、智能硬件开发、O2O电商平台、手机应用程序、大数据系统、物联网项目等开发外包服务,十年研发经验,上百成功案例,中科院软件外包合作企业。通过IT技术实现创造客户和社会的价值,致力于为用户提供最佳的软件解决方案。联系电话400-0316-532,邮箱sales@zhongkerd.com,网址www.zhongkerd.com


  上一篇   [返回首页] [打印] [返回上页]   下一篇