文章搬遷自http://papercatboardgame.blogspot.com/
－－－分隔線－－－
在討論「怎麼幫別人測試遊戲?」與「怎麼設計遊戲測試」之前，我想先討論一個問題：遊戲製作到什麼階段了?
這張圖表示在不同的階段，測試的任務與參與的測試人員也會不同。
這些階段的區分非絕對。概念測試常常是作者自己坐在書桌前，用幾個配件或是自己在腦袋裡沙盤推演完成的。等作出測試樣品時，就已經是進入體驗測試或流程測試。像我現在比較習慣使用一些美工軟體，從測試初期就會開始作界面測試。
當然，平常我們在測試遊戲時，是交雜著許多不同階段的。在開始測試前，先溝通清楚這次要測試什麼，可以更聚焦這次任務重點以及測試後的討論。
概念測試：
階段任務：這個想法有沒有辦法發展成遊戲?
不需要寫企劃，也不用想任何背景設計，甚至不用寫下規則。只要有想到什麼，就可以開始測試遊戲了。可以用手邊的東西來當遊戲中的指示物，甚至只是在紙上寫下幾個字，劃幾個符號，給一些語言上的提示，或是作一些手勢……就可以開始測試遊戲了。
首先，你會嘗試訂出一些規則，這些規則在概念測試階段會經常更改，更改規則的目的除了測試這些規則有沒有辦法構成一款遊戲外，更重要的是，有沒有辦法用這些規則去表述出你心中捕捉到的那個模模糊糊的印象。
像我在《如果雲知道》裡，一開始的概念是「用雲朵拼出事物的形狀，讓其它人猜」。在《龐氏騙局》裡，一開始的概念是「讓玩家被債務追著跑，借更多錢來填補債務缺口」。在《鋼鐵對火藥》裡，一開始的概念是「用手牌構築機制做一款30分鐘左右的文明發展主題遊戲」。
常常開始設計遊戲時，還沒有辦法用語言傳達出概念的內容。沒有關係，這就是概念測試的任務，去找出這款遊戲的核心理念，去找出這款遊戲之所以和其它遊戲不一樣的地方在哪裡，去找到這款遊戲值得花時間把它設計出來的理由。
概念測試階段的成員，最好你比較熟悉的人，或是可以接受你這樣天馬行空想像的人。如果你們已經有一個遊戲設計團隊，應該會是設計團隊內部的這幾個人。特別對於一個團隊來說，參與概念討論有凝聚共識的效果。
通常我會這麼做，找幾個人坐下來。先聲明現在只是在測試概念。使用一些現成的配件，不要作太多卡片或界面上的設計，以免讓測試者對遊戲完成度有過度的期待。隨時中斷，開啟討論。問他們的感覺或想像，看看是不是和我想表達的方向靠近。
概念測試階段不要把遊戲玩完，而是去嘗試，遊戲可以被玩成什麼樣子。
體驗測試：
階段任務：這遊戲有什麼地方好玩?
乍看之下和前一階段的任務很像，但前一階段問的是作者想要的表達什麼，體驗測試問的是玩家對於遊戲的期待，玩家「期待」在遊戲中可以玩到什麼? 以卡卡頌為例，它的核心體驗就是手上拿著板塊，想著要用什麼方式(為自己創造更多得分，或干擾對方得分)拼接到大地圖上。當它拿掉了板塊拼接的這一部分，我們很難說它還是卡卡頌。
核心體驗問的不是玩家怎麼贏，或是玩家可以採取哪些獲勝策略。而是玩家在遊戲中所作的這些考慮、這些選擇、這些動作……對玩家來說是不是有趣的。
體驗測試的階段一直延續到遊戲完工前，許多像遊戲節奏、遊戲調性、遊戲平衡……甚至是遊戲美工與界面的問題都會被放到體驗測試來檢驗。
譬如歷史巨輪這款遊戲，在長達3-4個小時的遊戲時間後，偶爾會出現玩家被戰爭打到只能放棄遊戲的局面。遊戲中是否該給玩家這麼嚴重的懲罰(3-4小時的經營毀於一旦)，一直是核心玩家間熱議的話題。當然也有玩家抱持，就是有這種瞬間毀於一旦的刺激感，才讓遊戲每個回合都充滿戲劇性的張力。
體驗測試問的是整體性的問題，通常作者會在前期先找到這個遊戲的「基調」，之後才有辦法決定什麼元素該不該留在這款遊戲裡。當然也有人是在製作遊戲的過程中，才慢慢捕捉這個遊戲的「基調」是什麼。如果沒有花時間去處理遊戲體驗的話，遊戲常常玩起來像是A機制加B機制的拼裝車。沒有辦法讓玩家清楚地意識到這款遊戲在玩什麼。
流程測試：
階段任務：遊戲流程是否順暢?
區分前期與後期。前期檢查遊戲能不能順利進行下去，有沒有哪裡不流暢。後期要求詳細列出遊戲的完整流程，然後個別檢查會不會在發生特定情況之下，遊戲會進行不下去或遊戲無法結束。
比較細的檢查項目有這些：downtime (等待其它玩家的時間、等待結算或機制調整的時間…)會不會過久? 有沒有經常會被玩家遺漏的動作? 單一時間內給予玩家的資訊量是否過多? 玩家之間的遊戲節奏能不能協同? 行動階段的層級分類會不會讓玩家混淆? 玩家情緒起伏的節奏或歷程為何? 玩家可採取行動、遊戲得分與獲勝條件擴張與收攝的曲線?
平衡測試：
階段任務：避免遊戲崩潰以及確保遊戲策略的多樣性。
平衡測試從預防意義上，是避免遊戲崩潰。相較流程測試是從流程與動作上檢查遊戲會不會玩不下去，平衡測試較多是數據上或策略上的檢查。
遊戲崩潰常見的情況，就是陷入某個無限循環的迴圈，像執行不完的行動或花不完的資源。反過來的情況是，永遠不夠用的行動或資源，讓玩家陷入泥沼中，無法作出有意義的選擇。如果讓玩家察覺到單一最佳解的策略，而使所有玩家採取同一個單調沒有變化的動作，也算是廣義上的遊戲崩潰。
避免玩家取得某項優勢之後(可能是起始優勢)，其它玩家就很難利用其它策略與之抗衡。或避免單一要素(角色、卡片、能力……)過於強勢，以致於其它要素失去價值。或避免領先者的優勢持續放大，讓其它玩家失去競爭動力……等等，這些測試的目的都是為了鼓勵玩家願意採取不同策略進行遊戲，擴延遊戲的深度及耐玩度。
界面測試：
階段任務：圖形及文字界面上的易讀性，以及規則中有沒有容易讓玩家混淆。
界面測試最直覺的工作就是檢查配件上各項資訊是否容易辨讀，還有規則書的易讀性。
如果不是作者獨立出版，界面測試最後的決定權會落在出版編輯身上。僅管作者在作測試樣本時，已經會有對遊戲界面的一些設定，但這些設定在出版流程中，通常只會被視為「建議」而已。比較正式的程序裡，出版編輯必須根據修訂的界面與規則書文字，找一群完全沒有玩過這款遊戲的人，請他們自行閱讀規則書，自行摸索遊戲怎麼玩。再從這樣的觀察裡檢查，有什麼地方需要再修正。
更廣義來說，規則中有沒有容易讓玩家混淆的地方，也是屬於界面測試的一部分。常常會出現這樣的情況，作者自以為是很容易理解的概念或操作方式，但對測試者來說卻很混淆。這時候就要檢查是概念本身有定義上的混淆? 還是說明方式不夠清楚? 還是需要作規則的重新清理與簡化? 如果有涉及規則的部分，就不會是出版編輯的職權，會再知會作者作這部分的修訂。
Jesse Li 2015
Comments