導(dǎo)讀： 本文作者Juhani Lehtim?ki，現(xiàn)任Fat Robot聯(lián)合創(chuàng)始人兼CTO，在過去三年里一直負(fù)責(zé)游戲《Lands of Ruin》的原型制作，由此撰寫了自己在構(gòu)建Android原型方面的實踐經(jīng)驗。

以下為譯文：

我最近更文較少，原因有兩個：

Android最近優(yōu)化了很多，沒有太多可抱怨的地方。各家公司都開始了解：理解Android設(shè)計并進(jìn)行正確的設(shè)計有多重要。最多就是說說新G+應(yīng)用？
這個是主要原因：之前我一直在忙一個項目，努力將長時間的興趣變成真正的產(chǎn)品。我和朋友懷抱一腔熱情，開發(fā)了一款名叫“Lands of Ruin”的新型混合模式的模型游戲。這是一款A(yù)ndroid的微縮模型游戲。
在過去三年多以來，我一直在負(fù)責(zé)構(gòu)建這款游戲的電子部分（制作Android應(yīng)用原型），并發(fā)現(xiàn)其實在Android平臺上，只需使用本地原生代碼，就能快速建立起原型。

緣起
在詳細(xì)解釋我們的工作內(nèi)容和工作方式之前，先說一下我們正在做的事情。

Lands of Ruin包括桌上模型游戲以及同名的平板電腦應(yīng)用。這樣的應(yīng)用前所未有，盡管混合型的游戲也有人嘗試過，但我們的游戲跟之前那些有本質(zhì)上的不同。簡單來講，我們想要在物理實體游戲與電子世界間建立平滑的交互。換成是你，要如何做呢？我們沒有能夠借鑒的樣本，也沒有可以照搬的想法，只能從頭開始，從無到有地創(chuàng)建這樣的交互。

第一步：紙
所有偉大的項目都是從一根筆和一張紙開始的。在快速原型構(gòu)建上，紙和筆就是無價之寶。無需寫下一行代碼，就能了解需求，最棒的是，這部分的工作可以通過協(xié)作完成。智慧的頭腦乘以2>所有其余的部分加起來！

我們最早的紙上原型甚至沒打算畫出平板UI，而是通過紙筆，找出需要追蹤的地方和需要自動化的部分，這時討論UI還為時過早。首先，在討論“怎么做”前，我們必須先解決“做什么”的問題。

很遺憾早期的圖紙都找不到了，不然還能跟大家分享一下，它們大多都是畫在紙上的備忘列表。

常規(guī)迭代
在項目最開始，理解速度很快，迭代也非常頻繁。我們必須為這個作為業(yè)余愛好的項目建立一個工作日常。我們的解決方案是在每周抽出一個晚上進(jìn)行測試，最終決定的測試日是周四晚上，三年來一直如此。每個周四我們用目前的原型玩一局游戲，然后討論改進(jìn)想法和下一步的工作。然后為下個周四設(shè)立目標(biāo)，再分開各做各的事。在未來一周內(nèi)，我們會執(zhí)行各自的任務(wù)計劃，同時進(jìn)行頭腦風(fēng)暴類的對話（一般在酒吧里），來解決遇到的問題。這種辦法非常有效！

周四游戲夜還在繼續(xù)并非偶然。不過如今的游戲夜，一般會有訪客到我們辦公室來，一邊玩游戲一邊喝上一兩杯，雖然我們對互動的改進(jìn)仍在進(jìn)行。我們將在會話時發(fā)現(xiàn)的問題記錄下來，希望在下個周四前修復(fù)掉。

第二步：功能性的“內(nèi)容”原型，或者驗證概念
在最初的紙面階段過去后，我動手編寫了第一個Lands of Ruin應(yīng)用。這時我們在UI和功能的表現(xiàn)方式上花的心思很少，第一個原型還是用來理解應(yīng)用需要涉及的內(nèi)容，

在構(gòu)建某個全新的東西時，有一個值得思考回答的問題：

對于這個問題，一般大概有三個答案：

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

如果回答是2，那么你有可能是在騙自己。地球上的人那么多，很多聰明人的智慧遠(yuǎn)超你我。

要想回答這個問題，我們決定：要對概念進(jìn)行驗證。就是抱著這個目的，我們開始編寫代碼，得出的成果如下：

此時的結(jié)果，無論在UI還是體驗上都還差得遠(yuǎn)，不過這兩者也并非我們設(shè)計這個原型的目的。這個原型讓我們能夠第一次真正的體驗這款游戲。這個應(yīng)用已經(jīng)定義了有限的規(guī)則及功能，因此我們可以通過推敲，得出完整產(chǎn)品的規(guī)則和功能。

這個原型還有一個重大的意義，就是能讓其他人試玩了。當(dāng)然，最初的體驗者想要順利玩下去，需要我們提供很多協(xié)助，不過這些體驗是非常珍貴的。我們能夠了解到這種概念的優(yōu)勢，并確定繼續(xù)往下做。

我花了大概兩周的時間，在晚上編寫代碼。雖然UI幾乎沒有，不過核心已經(jīng)出來了。游戲角色有了，動作可以執(zhí)行，玩家還能用平板通過WiFi與其他人對話。

第三步——快速建立原型
一旦對想做的東西有了足夠的了解，就該思考如何構(gòu)建了。這時，是時候開始構(gòu)思真正的UI了。我們做了差不多有15個測試版來累積經(jīng)驗，關(guān)于交互還有很多不明白的部分，特別棘手的就是電子與現(xiàn)實世界之間的連接，在我們的設(shè)計中，應(yīng)用需要大致了解在戰(zhàn)場上模型角色所處的位置。

我們需要更多信息，用概念驗證原型無法測試最復(fù)雜的那些設(shè)計理念。是時候再多花些時間在應(yīng)用上啦。

最開始我們坐在一起，在紙上畫出想要的東西。在紙筆快速迭代階段過去之后，我們開始利用Omnigraffle畫些更具體的內(nèi)容。

此時想要用紙原型玩游戲不再可行，我們用Omnigraffle線框圖進(jìn)行討論，然后決定這個概念值得一試。

成果如下：

此時離直觀或美觀還相距甚遠(yuǎn)，不過已經(jīng)包含了游戲所需的一切功能。游戲藍(lán)圖已經(jīng)有了，并且運作良好，這是第一次可以按照我們預(yù)想的方式來玩游戲了，此時我們在這個項目上已經(jīng)花了6個月的時間。

問題
現(xiàn)在，隨著原型的保真度更高，我們開始了解存在的問題。盡管距離最終的解決方案還差很遠(yuǎn)，不過理解問題所在的第一步已經(jīng)有了。

這時候事實已經(jīng)非常明顯，操縱角色并不容易，也不好玩……如果某款游戲的互動無法令人開心的話，就不能算好游戲。

我們開始進(jìn)行設(shè)計迭代，并非視覺上的，而是功能上的。我們想要在小小的7寸屏上找出足夠的空間，讓用戶很容易便能訪問所有的組件。我們增加了折疊式抽屜（sliding drawer）控件，以查看更多細(xì)節(jié)；又增加了view pager控件，以快速切換角色。

下面是其中一個迭代：


下一次迭代：

再下一次：


我們不斷移動物體、修調(diào)其大小并進(jìn)行重排，每次都會感覺距離目標(biāo)更近一些。游戲測試者越來越多，每版的反饋也越來越好。

碎片功能（fragments）非常強(qiáng)大
我想要指出一件事，與你聽說的可能有所不同，Android的fragments在設(shè)計原型方面非常強(qiáng)大。

我們的游戲UI到了現(xiàn)在還全都采用的本地代碼。作為Android開發(fā)者，這是我最了解的方式，也是我能最快得出結(jié)果的環(huán)境。截屏中可見UI的各個部分都是獨立的碎片，在上面的截屏中能看到5-7個碎片，每個碎片都了解各自需要展示的內(nèi)容，并訂閱著中心游戲狀態(tài)（gamestate）的變更。碎片之間不會直接對話，所有通訊都通過事件總線的方式來去耦。

這一架構(gòu)允許我們進(jìn)行快速迭代。無論該碎片位于哪里，或者其他碎片是否可見，碎片中當(dāng)前游戲狀態(tài)下角色應(yīng)當(dāng)如何表現(xiàn)都是有規(guī)則的。

這種去耦的事件總線架構(gòu)讓我可以將某部分UI完全從一個原型改成另一個，而無需擔(dān)心影響其他部分，也不需要對UI進(jìn)行整體調(diào)整，而游戲修改后的版本仍是可玩的。

第四步——設(shè)計
最終我們進(jìn)行了足夠的測試，收集了充足的數(shù)據(jù)，因此可以進(jìn)行下一步了。目前的原型太過簡單丑陋，很難在公開場合展示。剛好我們有個機(jī)會，參加當(dāng)?shù)氐闹谱髡呤⑹翸ake Munich，將游戲公之于眾。

我們需要這個機(jī)會。我們決定在Make Munich上發(fā)布我們的游戲，因此先將這款應(yīng)用在Google Play商店上架，進(jìn)行封閉測試，希望能找到更多團(tuán)隊之外的人試玩，從而找到視覺設(shè)計人員。

Rick是LoR團(tuán)隊的設(shè)計師，他接受了這個挑戰(zhàn)，成為了我們的視覺設(shè)計師。結(jié)果，我們獲得了這個UI：


有了這個UI，我們就能驕傲地去參加Make Munich大會，并發(fā)布游戲啦。那時候是2014年4月。

第五步——現(xiàn)實給了重重一擊
在Make Munich盛會之后，我們將從觀眾和其他試玩者那里收到的回應(yīng)做以評估。大體就是這款游戲不夠好，一些規(guī)則機(jī)制太過復(fù)雜，使得交互非常困難。在這款應(yīng)用的很多用例中，都因UI太過笨重而導(dǎo)致玩家的精力浪費在平板部分，難以集中在桌面和對手上。

我們的設(shè)計準(zhǔn)則之一就是，這款游戲必須感覺像是模型游戲，玩家應(yīng)當(dāng)專注于模型、地形和桌面上，因此這種狀態(tài)顯然是失敗的。


好吧，只能重新開始！很明顯，游戲的概念還是不錯的，但我們的做法有問題。必須做些什么。

盡管我們在產(chǎn)品的生產(chǎn)設(shè)計與開發(fā)上花費了很多時間，不過現(xiàn)有的應(yīng)用版本必須廢棄掉。它跟我們的目標(biāo)不符。

第六步——嘗試全新的東西
設(shè)計方面的最大問題在于，角色很難控制。

我們灌了幾罐啤酒，開始就能做些什么進(jìn)行頭腦風(fēng)暴，結(jié)果有了一個想法：彈出drawer，于是我們決定一試。

最終完全修改后的游戲UI如下：



盡管此時，在這個狀態(tài)下游戲還不能玩，不過這個概念看起來很有希望，似乎能夠真正解決我們現(xiàn)有的問題，很值得我們多花些時間看看。

結(jié)果奏效了，很接近得出結(jié)果。一兩周之后，游戲也可以試玩了，我們感覺事情最終開始往想要的方向發(fā)展了。

第八步——優(yōu)化
我們不能發(fā)布將完全是原型的東西發(fā)布出去，因此針對卡片理念進(jìn)行幾次快速迭代之后，我們決定在視覺上做些合適的調(diào)整。Rick被迫又做了一次asset生產(chǎn)模式。

初版如下：



最終，應(yīng)用開始接近我們想要的方向了。在測試中出現(xiàn)了巨大的區(qū)別。在游戲時，平板終于成了次要的部分， 成了桌游的延伸。這就是我們一開始的目標(biāo)。

并不是說這款應(yīng)用就完美無瑕了，不過在開發(fā)了三年之后，我們終于達(dá)成初衷了。目前實現(xiàn)的方式值得再雕琢一下。

在下面的迭代中，我們修改了卡片的方向，讓它更適應(yīng)我們使用的方式，能夠在恰當(dāng)?shù)臅r候為玩家提供更多信息。

下面是我們得到的結(jié)果：


第九步——準(zhǔn)備發(fā)布
目前這款應(yīng)用已經(jīng)包括了所有的核心功能，具備基本可玩性了。對于如何在核心之上構(gòu)建更高級的功能，我們也有很好的理解。不過，應(yīng)用的視覺效果還無法令人滿意。之前的視覺設(shè)計都是由Rick來做的，不過他現(xiàn)在手邊有一大堆其他任務(wù)，需要將更緊急的眾籌和大會demo弄出來。

我們又找了個外援，雇了我女朋友的姐妹Natalia Kovalchuk來優(yōu)化游戲設(shè)計，讓它合乎標(biāo)準(zhǔn)，能夠在大會和眾籌中表現(xiàn)良好。

下面是這次設(shè)計迭代的結(jié)果：



第十步——眾籌
現(xiàn)在到了眾籌的時候，從有初始概念到如今，三年來以來我們一直在嘗試讓這款游戲進(jìn)入公眾的視野。我們目前正在進(jìn)行眾籌，希望能為這款桌面模型游戲的實體部分籌集足夠的資金（觀看視頻，需自備梯子）。

英文來源：Android as a Prototyping Platform - a Case Study
作者： Juhani Lehtim?ki（@lehtimaeki），F(xiàn)at Robot聯(lián)合創(chuàng)始人兼CTO
翻譯： 孫薇