遊戲開發者怎麼做出一個成功的demo？

一份可執行demo能夠讓你測試玩法機制，初窺遊戲帶給玩家的觀感，在這方面的效果比任何設計檔案或模型都要好得多。Demo既是一種有用的內部工具，允許你在正式製作一款遊戲前測試概念，往往還是你獲得客戶認可，或者吸引潛在投資的一個必要步驟。

過去十年，Art of Play製作了超過70款遊戲和150多份demo，並通過反覆嘗試總結了一些行之有效的方法。在這篇文章中，我們將會分享能幫助開發者快速有效構建demo的技巧和竅門，同時列出一些應當避免的“坑”。

當然，第一步是構思概念。(遊戲開發)創意可能來自任何地方，例如對過往專案的覆盤，在其他遊戲中的體驗，以及書籍、電影等其他媒介作品或日常生活帶來的靈感。

某些想法在紙面上，或者在會議討論中聽上去不錯，但你通常需要構建一個小型原型，才能判斷圍繞它打造遊戲究竟是否可行。這既是一門科學，也是一門藝術。



科學：技術方面的要點

瞭解你的工具

遊戲開發者經常喜歡談論他們用來創作遊戲的工具，例如最新框架、外掛或著色器等等。不過，無論是在內部交流或與外部客戶、發行商和投資方打交道時，團隊所使用的溝通工具和系統也非常重要。

在現代軟體和工具的幫助下，無論你的團隊成員在同一個房間辦公，亦或分佈於不同國家，你們都能夠進行持續、有效地溝通。

你需要將所有可用工具(包括遊戲開發工具、團隊管理和溝通工具)視為整個工具箱中的一部分，儘早選擇適當的工具，充分了解它們並堅持使用。如果你將精力分散到Slack、Basecamp、Discord和電子郵件上，那麼團隊溝通效率就有可能大打折扣，加大溝通成本，造成誤解或資訊遺失。考慮到這一點，你應該讓團隊成員堅持用某個單一的溝通工具。

如果團隊成員分佈於不同國家，那麼你就需要在必要時為會議制定計劃。如果某次會議不需要所有人實時討論，你就可以將訊息釋出到溝通工具上，允許每名成員在方便的時候檢視。就算所有人都在同一個地方辦公，為了推動專案儘快進行，你也需要儘可能避免過多的實時溝通。

當一名開發者在處理複雜工作時思路被打斷，那麼他/她很可能需要花上10分鐘才能重新找回狀態。這也就意味著，如果每天都有太多會議干擾開發者的注意力，專案進度就很容易被拖慢……所以，請為你的團隊提供高效工作和溝通所需要的空間和工具。


減少、回收、再利用

怎樣才能減少創作素材所需要的時間和精力？方法很簡單：不要追求完美，儘量多使用佔位符。隨著時間推移，你會建立起內容庫，並積累豐富經驗。無論你完成了一款正式釋出的遊戲，亦或只是打造了一份demo，都能夠從中學習新知識，並積累一些新的素材和程式碼。

在每個專案結束後，你都可以對它進行拆解並組織團隊討論，從而總結行之有效的方法，讓它成為集體“經驗庫”中的一部分。當團隊討論接下來的專案時，可以利用這些經驗來加快速度。從理論上講，一支團隊完成的專案越多，能夠重複使用的經驗就會越豐富。

同樣的道理，當團隊編寫新程式碼或創作新的素材時，也可以考慮將它們加入內容庫，以便在未來使用。通過這種做法，團隊將能夠提升效率，減少構建一份demo或達成下一個里程碑節點所需要的時間。

如果你想創作佔位符圖形和音訊，可能需要耗費大量時間，但如果你打造並維護一個內容庫，那麼你就可以快速利用可用內容，以更快的速度構建demo。

完美是優秀的敵人(不要苛求完美)

一份demo並不是一款遊戲，你不會對外發布，所以它不需要具備太高的完成度。開發團隊很可能想把demo畫面做得更漂亮，新增更多特性，從而打動客戶/投資方，但你需要抓住重點：(通過demo)讓某個機制、關卡或系統能穩定執行，並儘快進行測試。

如果某些東西無法執行，那麼你就應該儘早對它們進行更改或棄用，然後嘗試另一種不同的思路——用創業團隊的話來說，這叫“快速失敗”。如果你在每個階段都苛求完美，必然會為早期版本投入大量時間和資源，一旦決定轉變方向，就會造成浪費……只有當你已經構建一份穩定、經過測試的demo後，才需要花時間將打磨得儘可能完美。

在構建demo的整個過程中，你應當有意識地避免苛求完美，只有這樣才能讓團隊維持靈活性，並快速地朝著目標邁進。


藝術：怎樣管理團隊和與客戶打交道

創造性思維

遊戲開發是技術與藝術相結合的一個縮影。無論一支團隊擁有多麼強大的技術實力，你都需要鼓勵所有成員發揮創造性思維。

根據專案的不同，團隊的創作空間可能差異巨大。如果你為客戶代工開發一款遊戲，那麼客戶會在一份設計檔案中列出非常具體的需求，你不會有太大的創作自由。另一方面，如果你正在根據自有IP開發一款遊戲，希望利用demo來吸引潛在的投資方或發行商，那麼你幾乎可以完全自由地進行創作。通常來講，開發團隊所享有的創作自由度介於兩者之間。

無論團隊規模大小，你都需要鼓勵所有人大膽創新，允許大家提出想法並對它們進行測試。與此同時，你還需要營造靈活的工作環境，鼓勵團隊對demo進行快速迭代，而不必受到繁瑣環節或審批流程的困擾。

儘量減少繁文縟節，使專案保持精簡規模

如果你希望快速構建一份demo，但開發團隊在每個環節都得經過流程繁瑣的稽核，那麼專案就相當於被判了死刑。你需要儘可能將繁文縟節減少到最低程度，讓每個人都能快速工作，共同推動專案向前發展。

與那些規模較大的團隊相比，“敏捷開發”往往是小型團隊的優勢之一，因為大家更容易保持溝通，都瞭解專案進度，以及其他同事正在做些什麼……隨著時間推移，你還會更深入地瞭解同事和他們喜歡的工作方式，這能讓溝通成本大幅下降，讓團隊協作變得更輕鬆。

小團隊還有另一項優勢，那就是所有成員身兼數職，這可以減少在專案溝通中的來回。在那些規模較大、員工分工明確的工作室，如果一名程式設計師想要某種素材，那麼他就不得不先向美術提出需求，然後等待美術團隊交付。相比之下，在小型工作室，程式設計師很可能就掌握了一些基本的美術創作技巧，能夠自己動手創作佔位符素材。


達到客戶的期望值

你需要為專案設定截止日期，因為這有助於團隊管理專案進度，避免在中後期盲目地新增太多特性……很多時候，開發團隊總是希望不停地新增新特性，或者對內容進行更多打磨，但這可能導致專案永遠無法完工。如果你不希望你的遊戲變成下一款《永遠的毀滅公爵》，那麼你就應該朝著在截止日前完成開發的目標努力。這是整個流程中的一個重要組成部分。

設定截止日期後，你需要明確一點：demo只是demo，而非一款完成版本的遊戲。這意味著你需要決定在demo中提供哪些內容，並明確告訴客戶，demo和完整遊戲之間有哪些差異。

Demo扮演著很多角色。它既能讓你驗證某個概念究竟是否有趣，同時也是一種溝通工具。由於demo不能呈現遊戲的所有特性，你應該專注於利用它來展示遊戲的獨特之處，例如一套獨特的機制、全新操作方式，或者與眾不同的美術風格。

結論

為了快速高效地構建demo，你需要擁有一支經驗豐富，既能獨立工作又能彼此協作的團隊，合適的遊戲開發和溝通工具，並讓團隊成員樹立正確的心態，養成良好習慣。

在此基礎上，你應當儘量必要不避免的繁文縟節，讓團隊關注全域性，而不會在每個環節都苛求完美，進行耗時費力的打磨……一支團隊構建的原型和demo越多，積累的經驗越豐富，就更有可能發現“金礦”。《憤怒的小鳥》是芬蘭公司Rovio開發的第52款遊戲，但其前51款遊戲並非“失敗品”，因為它們幫助開發團隊積累了經驗。

無論你正努力趕在專案截止日期前構建一份demo，亦或像2013年的Rovio那樣正在開發自有IP，快速、高效地圍繞遊戲概念打造demo都非常重要。當你擁有一份demo後(哪怕完成度還不高，包含了大量佔位符圖形)，只要它足夠有趣，你就可以為讓它變成一款完整的遊戲，讓鳥兒展翅高翔做準備了。

作者：Ash Nicholls，澳大利亞工作室Art of Play創始人兼總監
編譯：澤塔
來源：手遊那點事【編譯自GameIndusrty.biz】
地址：https://mp.weixin.qq.com/s/tXwwZmsrrB4lWRjuvEYVMg