最近，我就開發者能否用純粹玩家的心態，來體驗自己製作的遊戲這一問題，與不同的設計者做了相對深入的探討，大部分集中在：一個對遊戲邏輯（比如接下來要展開怎樣的進程；在哪個環節會出現什麼動態，或執行什麼操作會有多少相應的遊戲反饋）了如指掌的製作者，在面對已知的遊戲時究竟所持的是什麼心態。是假裝一無所知，好奇地尋覓潛藏在遊戲各個角落的功能設置並將它激活為一種當刻的愉悅（或許還能因為遊戲還原到一個自如運行的場景中，不同的元素相互碰撞而衍生出了很多開發者在設計製作時根本沒留意到的新鮮樂趣來）；還是用無所不能的「上帝視角」苛刻地審閱每一個遊戲的進程是否真的能夠如預期設置的那般完美地再現出來（儘管事實上，因為遊戲的製作涉及到多方位的協同，必然在步調上存在不一致的現象，而導致最終的結果有一定妥協，不一定真存在100%的製作還原度），抑或是存在各種亟待調整的瑕疵。
事實上，我的看法更傾向於：開發者在體驗自己設定的遊戲時，基本很難再從探索遊戲的進程行為中體驗到如玩家那般的樂趣（玩家樂趣很大一部分來自於未知進程的實現，比如新打開的副本是什麼樣的場景，而自己要面對的Boss是什麼角色等。當然也有例外，比如在重複體驗遊戲時，按照技巧和經驗能最大程度優化遊戲的完美操作程度，而獲取到更至臻的樂趣），而是來自於開發執行之前的方案推演和開發前期的原型設計，這兩個環節是否存在能觸動開發者的樂趣發現，差不多就能決定該項產品能否最終獲得開發支持——前者（方案推演）需要從產品的獨立定位和獨特體驗，進行雙重論證以獲取必要的研發經費和團隊的理念協同支持。換句話說，開發者大多在方案階段就全面向自己的搭檔完整地展示遊戲的潛在樂趣，並用圖文或肢體語言將這種樂趣輪廓式地勾勒出來，以便從一開始就能獲得價值認同（雖然很多產品的立項大半沒有經歷過這個階段的論證，可能只是大體地知道一個含糊的方向就開始參與到細節研發中，以致很多參與人員即便到遊戲的完成階段也說不清楚自己做的到底是什麼樣的遊戲，比如有哪些讓人印象深刻的環節等）；後者（原型設計）更是需要最為直觀地向整個開發團隊立體地演示出該款遊戲最為核心的獨特體驗應該是什麼樣子，而這樣的體驗是否能驚豔到玩家（比如區別於其他遊戲的進程方式，和其他遊戲相似的操作行為是否有更進一步的深度優化），並從反向進一步驗證方案設定的可行性和具體能執行的程度（如果原型設計並不能滿足開發者對遊戲設定的最基本要求，即使勉強開發也不一定就能獲得好的結果，還不如再逆推回到方案重新尋找可以替代甚至更優越的方式）。
這兩者差不多是玩家關注不到，而開發者必需優先考量的層面。如果遊戲存在樂趣也必然是開發者先於玩家進行設定，再落實到具體可操作的範疇，而不是類似玩家那樣在遊戲的進程中去逐步挖掘和感受遊戲釋放出來的樂趣。基於這種比照，開發者的這種遊戲再體驗就和玩家的行為存在了本質的區別：開發者是遊戲方案的設定者和遊戲樂趣的實現者，先於遊戲存在，就需要預設和描摹出這種樂趣和可行性，開發者的再體驗就是確保和驗證這些設定好的樂趣的實現程度和再優化的角度（這種體驗允許各種不合理的存在，並通過各種測試開發得到完善的結果）；玩家是遊戲樂趣的體驗者，只是按照遊戲設定的邏輯依次感受遊戲賦予玩家的美好時光，並且大部分的愉悅就來自於對這些依次展開但對自己是新鮮元素的遊戲內容（這種體驗不允許絲毫障礙的存在，任何大的瑕疵都可能影響玩家的體驗情緒和導致玩家的不滿而離開）。
如果進一步梳理則大致可得到以下結論。
注重遊戲進程的邏輯
對於開發者而言，任何的遊戲系統、功能點、界面布局、彈框層次、遊戲的資源布局、進階屬性、可能存在的掉落概率、遊戲數值、副本順序、戰鬥效果等因素都必然瞭然於胸。基於這種熟悉度，所有之前深思熟慮過的環節都會在遊戲的體驗進程中先後在腦海中呈現出來，逼迫開發者邊體驗邊比照。一種潛藏的責任感往往能滲透到每一次的點擊行為，直到這種遊戲行為慢慢演變為一種校驗舉動。
於是，開發者就很在意那些彈出的文字框次序是否符合設定，文字陳述是否清晰，是否存在錯別字；彈窗的顏色配比是否符合場景效果，字體是否放置得當；界面的按鈕是否醒目，每次點擊是否響應自如；功能系統生成時是否剛好匹配遊戲的進程需求；客戶端和服務端通信和數值銜接是否順暢；玩家的資源和數值設定在遊戲的深入發展中是否合理；遊戲是否存在頻繁的卡頓行為；預先設定的道具的掉落概率是否存在問題；遊戲的美術圖層是否存在設置疊加問題；戰鬥的打擊感是否到位；遊戲的每次加載時間是否會超過玩家的容忍度；玩家能不能接受基於內容不足設定的一些人為障礙（比如拉長遊戲時間或使用重複行為）；遊戲的AI表現是否能盡如人意；玩家能否逐步適應遊戲的難度設置；遊戲的關卡和副本設置是否有讓玩家探索的欲望，諸如此類。
對於開發者而言，這些進程是經過自己推演和預設的，如果重複回到自己所熟悉的場景，就必然堅持所有內容都要對號入座，才覺得這種體驗是完滿的。而一旦稍有差異，基本上渾身上下就只剩下「再把這些內容矯正回先前設定」的衝動了。
數值和數據控
隨著遊戲設置中的各種獎勵數值和進階數值泛濫化（這裡的「泛濫」指的是數值出現太頻繁，這些數值單次出現時對遊戲整體效能的影響微乎其微。現在玩家基本上是程序化地完成這個展示動作，緊接著再完成一個收集動作而已。玩家基本不關心單次出現的1000個金幣真的有什麼價值，事實上這些金幣本身也真的沒什麼價值），很少有玩家會去關注具體數值的出現對資源增減的變化，大半都是伴隨著一個點擊行為就過去了。只有開發者才會對這些細微數值的變化敏感。這背後必然意味著：需要驗證前端的數值運算和服務端的等值反饋是否準確或是否即時。在遊戲數值化（基本靠數值的變動來表現玩家資源或戰力的差異）的當今，每一次數值的記錄都左右著玩家在進程中的遊戲體驗（特別是一些關鍵位置的數值變動，比如完成一次大戰役和執行一次小任務在數值層面就需要拉開差距）。而如果一旦數值出現記錄失誤，可能玩家會忽略，而開發者則必須追根溯源地尋找到問題的癥結才算邁過一個門檻。
與單次行為相對應的是數值的可控性設計。很多設計者有多種看起來完美的計算公式，一下子就梳理了整個生命周期的數值布局，但實際上比單次計算更嚴重的是：要麼數值不能兼顧長周期，導致遊戲進程中數值累積量不斷失控，最後玩家間遊戲既不可能平衡，而單個玩家面對自己大額度的資源數值又手足無措；要麼數值設定完全公式化，沒有權衡到遊戲進程中因為玩家的深度參與和一些事件性的變化，可能致使原本合理的公式化計算偏離需求，最大化地迷惑了設計者本身，原以為完美無缺的環節成為遊戲最糟的瓶頸。
校驗偏執症
這幾乎是一種本能的反應，開發者在遊戲體驗中的每一個行為都在追求操作正確，這種正確性的訴求可能又包括三個方面。
其一，整體的遊戲進程是否和當時方案的設定相吻合，因為開發者本身的溝通問題或開發者對技術相關能力的偏好，有些預設的內容在執行層面被置換為其他的替代方式，或壓縮了使用範疇，或直接取消了部分有實現難度的內容。事實上，很多功能系統最後實現的部分都是偏離預案後的妥協結果。
其二，遊戲的執行進程是否存在體驗障礙，影響了玩家的直接遊戲感受，諸如卡頓是否太厲害、視覺效果是否讓人失望、功能響應是否有障礙、界面設置和彈出是否符合用戶的邏輯習慣、用戶是否覺得數值所得不滿意（如圖1所示）。大部分玩家都是情緒派，任何糟糕的體驗都可能導致一個用戶的流失。
圖1 Pixelmator測試Flapcraft遊戲技能
其三，多次驗證那些在方案推演和原型設計過程中被認可的功能系統是否如預想中的那般。這包括：第一，這些系統和整體的遊戲搭配的協調度，是突兀地單獨游離成為一個環節，還是成為遊戲整體的有機部分（我們看過的很多遊戲的一些功能點都是附屬的，基本缺乏整體感）；第二，在整體的遊戲環境下，單個系統的執行有趣性是否和預想的相當，或作為一個整個的銜接環節讓遊戲更有趣，還是淪為一個重複執行的枯燥體驗；第三，與市面上現成的遊戲相比照，從側面驗證類似的設計在玩家群體中是否有足夠的競爭力（比如匹配用戶需求的創新點或相似玩法具有深度優化層面）。
細節層面的考究者
舉一個典型的例子，近一年《Clash of Clans》類的遊戲大為盛行，但又都必然面對一個問題：「防建同體」玩法最大的顧慮是，遊戲的執行後期界面中的遊戲素材堆積失控，特別是一些動態構造，既讓玩家應接不暇，也同樣給系統帶來了無盡的負荷壓力（與之相對，在網頁遊戲中，開發者所著力追求的同一個場景的火爆場面同樣也存在著這個問題，當同一個界面有無數個人物在跑動時，對玩家的計算機就提出了更高的配置才能適應遊戲需求不至於卡頓），玩家可以追求各種華麗的效果，而開發者則需要兼顧這些效果是否會干擾玩家的正常體驗。
當然也包括開發層面常遇到的問題：在電腦正常配置和平均網絡加載數值的情況下，就需要考慮遊戲內容的加載時長是否超出了玩家的忍耐限度。而各種NPC的加載是否存在滯緩的情況，甚至在玩家的博弈狀態下延時問題又會給玩家帶來哪些困擾，大面積特效的使用是否會讓玩家的體驗不夠流暢，AI的表現是不是會讓玩家覺得不夠給力，遊戲的數值設置是不是足夠均衡。
基本上最容易惹怒玩家的，就是開發者必須關注的核心細節，我們常看到的玩家吐槽中，很大比例都和上述幾個層面相關。
勤奮的書記員
我曾做過一款遊戲的測試，僅僅關於問題的陳述和截圖就將近1000頁Word文檔。和純粹體驗遊戲的玩家不同，開發者必須不放過任何一個優化遊戲的問題記錄。不管問題再小，出現的概率再低，都可能成為一個遊戲自我完善的困擾。
於是，開發者所做的記錄可能細緻到：陳述問題本身並截圖以做印證；還原遊戲當時執行操作的相關步驟；當時捕捉到的關聯代碼；玩家的網絡問題；玩家其他不合適的操作行為；問題本身可能重複出現的概率（如果概率很大就算功德圓滿；如果概率一般甚至只出現過一次，這個問題就會成為一個等待處理的擱置嫌疑，留下一個懸而未決的尾巴）。
當然，並不是所有的記錄問題都能得到妥善的處置，比如有些問題超出了開發者的能力範圍就基本會成為大問號，直到玩家都公開抱怨也無能為力（大部分都和技術瓶頸有關）。
馬甲控和重複測試
從開發者的角度所做的體驗很多不是基於尋找遊戲的樂趣（這部分我們在前文論述過，開發者的樂趣在方案推演和原型設計上，如果這兩個部分不能感知到樂趣，就基本沒有再研發的必要了），而在於重複印證遊戲的邏輯設定是否順暢。差不多此時，開發者的眼裡都只有Bug，如果一次體驗沒找到Bug，都可能會懷疑是自己玩得不夠好或玩得不對。
與一般的玩家「玩第二遍就會膩」完全不一樣的熱情是，開發者有兩個差異化的能力。第一個是重複體驗，在不存在Bug的情況下體驗遊戲的流程（需要確保這個流程是開發者可控的）；存在Bug的情況下校驗問題的修正程度（問題是否得到修正，這個問題是否誘導了其他問題的發生）。並且這種重複還可能是不間斷地數據重置，重新開始，有時一個場景就要重複進出N次才算結束。第二個是馬甲控，意圖相對明顯，第一種情況是校驗不同等級的帳號在實際遊戲中可能存在的戰力和資源差異，特別是從純粹策劃的角度，推算出來的數值是不是存在偏差；第二種情況是杜絕帳號之間可能存在的利益輸送問題，特別是以馬甲出現的大小號是否存在以饋贈或不均衡交易導致的資源單向堆積，而破壞遊戲玩家平衡的問題。
作者鄭金條，遊戲邦負責人，遊戲邦主要關注和解析國內外社交遊戲和手機遊戲領域，並定期做深度行業闡述。
本文為《程式設計師》原創文章，未經允許不得轉載，如需轉載請聯繫market#csdn.net(#換成@)