學習遊戲拆解過程中的一些思考與感悟
引文
筆者相信很多初入遊戲行業的新人在試著對某款遊戲進行拆解時都會存在一些困惑。
我為什麼要拆解?該如何拆解?筆者在參考了許多拆解相關的方法論和樣例後,決定記錄一些自己對“遊戲拆解”的思考與方法論。
拆解需要目的
作為初學者,筆者見過許多同樣身為初學者寫的拆解,這其中不乏能寫到萬字以上的文章,或是行文排版視覺設計上十分美觀的PPT,也有輔有細心思考所總結的複雜資源迴圈圖與系統框架圖的文章。
然而筆者往往在閱讀完這樣的拆解後,很難留下深刻的映像,一方面是這部分的拆解大多涉及的遊戲系統繁多,閱讀者往往會眼花繚亂,另一方面是大部分這樣的文章中的主體都是對元素的羅列和稱述,鮮少有對設計進行較深層次的思考與分析。
因此這裡筆者引出自己的第一個觀點,即——“拆解需要目的性”。
沒有體現出“目的性”的拆解就像是一篇隨手寫的讀後感,觀感上會十分空洞。
在對目的性的思考上,拆解文章應當直面疑問——“為什麼要做這篇拆解?哪些體驗是優秀的?這樣的體驗是如何被設計出來的?”,對設計的分析應當具有獨特性與代表性,並考慮所得出的結論是否具有一定的指導價值,而不是泛泛而談一些不會出錯的空話。
圖源自網路,僅作演示無惡意
圖源自網路,僅作演示無惡意
諸如此類的拆解文章有很多,而大部分拆解文章趨於雷同本質上就是拆解缺乏目的性的體現。
因此我們需要為自己即將要做的拆解賦予目的性。
目的往往是由一個疑問,一份好奇所誕生的。如:
黑魂與只狼在箱庭關卡設計上存在哪些差異,這種差異帶來了什麼樣的體驗?
怪物獵人中不同武器是如何在完全不同的戰鬥風格的基礎上設計狩獵體驗的?如果要設計一把新武器的話又該如何與其它武器進行平衡?
當產生這些疑問,並且在網路上搜尋一番後發現沒有人提出過類似的疑問後,對這些問題的好奇心會促使我們形成一種使命感,而這便賦予了拆解的目的與動力。
在精力有限的情況下,確保問題的尺度與問題本身的意義也相當重要,如
“《決戰平安京》與《王者榮耀》有哪些差異?”
這種問題在筆者看來就不適合作為拆解去寫,若是寫到後面羅列眾多,文章內容雜亂無章,也沒什麼興致談論具體設計了,最後拆解只能浮於表面。而若是思考兩者戰鬥系統或是社交系統的差異化設計與體驗,那便有了可行性,因此,對問題進行進一步的拆分,確定其尺度可行後再動筆,亦能夠為拆解的目的性提供良好的支撐。
服務型遊戲與內容型單機的不同分析思路
筆者曾經試著用一些所謂的拆解模板試著對當下的一些商業化手遊的系統進行分析,但是當寫到每個系統的設計寫設計目的時,幾乎是強行寫下了自認為其對玩家體驗起到的正面作用——就比如說命座系統和聖遺物系統這些幾乎很難在老玩家心中贏得好口碑的系統,但是在商業化的角度上取得極大成功的系統,其成功的原因絕非是因為這些系統給玩家帶來了較好的體驗。
這裡筆者就提出了自己的第二個觀點——“分析服務型遊戲與內容型單機時應有不同的思路”。
服務型遊戲的分析應側重付費與留存,尤其是非玩法向的服務型遊戲,當然這裡筆者想表達的不是服務型遊戲不能按照常規思路對玩法設計進行分析了,而是當筆者在實踐的過程當中發現當自己理解了這點,很多“為賦新詞強說愁”的設計分析就有了答案,因為可能這個系統設計其最大的意義便是在商業化上。
實際上在筆者相信如果同時參與開發過商業專案和單機專案的開發者對這一點會有更深的體會,因為商業化專案的任何一個系統,其在商業化層面的考量往往是優先於玩法層面的。
(PS:這一論斷在後原神時代是否能被推翻,有待考量)
先拆再解,自上而下,先整體後部分
在明確了拆解的目的後,如何著手開始拆解呢?
筆者總結了下面兩種大體思路與方法(思路借鑑自《遊戲設計的底層邏輯》):
- 功能分析法
- 體驗還原法
功能往往是一個遊戲直接暴露在外的介面,進行功能分析時,先透過錄制或是文字的方式進行記錄,然後分析能否進一步拆分成子功能,要注意的是功能會存在顯性功能與隱性功能的區別,例如像守望先鋒中的對局結算便是顯性的,而全場最佳這一功能本質是一個隱藏了的一個評分功能。
體驗還原則是從主觀上的體驗入手,試圖整理歸納塑造出這種體驗所涉及到的功能與系統。
從功能開始分析往往更容易上手,並且也更容易尋找系統或功能之間的聯絡,而體驗還原法相對難度更大,因為對一個主觀的抽象概念進行拆解分析,相比對一個實體視覺化的功能進行分析,前者很難確定拆解的顆粒度與準確度,而後者則往往只需要結合著遊戲介面便能羅列個八九不離十。
然而前者所帶來的自上而下從塑造體驗的角度進行拆解,往往能幫助我們更深刻的理解設計。
因此筆者建議交叉使用兩種方法對遊戲進行分析。
深層次的拆解往往會涉及拉表進行數值的反推,因為真正從底層塑造體驗的是遊戲中大大小小的數值,這一步往往要花費大量的時間精力。因此在精力有限的情況下可以優先從有暴露在外的資料的整體部分著手,再進一步考慮部分。這也是筆者認為拆解前確認目的與問題的尺度是關鍵一環的原因之一。
解的部分筆者習慣於從某個規則推出了什麼結論,然後將玩家導向什麼策略入手反推出設計的目的,。“解什麼?”“怎麼解?”,在這點上每個人有自己的風格,因此筆者在這不多贅述。
透過對早期版本和現版本雲頂之奕棋子賣出價格的變化能看出設計師的目的
總結一下,“拆”應當追求細緻與慎密,而“解”則應當追求觀點的獨特性與代表性,若有相應的知識儲備,在“解”的過程中也可以例舉同類遊戲進行對比分析。整體上應遵循——先拆再解、自上而下、先整體再部分的原則。
拆解與體驗(分析評測)的區別
筆者過去一直都難以分清拆解與體驗的區別,實際上也確實沒有必要將兩者劃分的涇渭分明,但若是一定要做出區分,倒也是能夠將兩者區分開來。
從閱讀者的體驗來講
體驗文件往往對沒有玩過該遊戲的讀者會更友好,在閱讀完後能達成一種——即使沒有玩過,但是在看過後能夠了解遊戲的樣貌與遊戲的獨特之處的感覺。
注重美觀,以功能羅列為主
而拆解文件則往往則往往會給閱讀者一種“雖不明,但覺厲”的感覺。
一篇海外開發者在medium釋出的遊戲拆解文件
從寫作目的上來講
體驗文件往往是站在產品和市場的角度,對遊戲中的核心玩法,各個系統進行羅列並分析,輔以主觀的體驗感受,體驗文章的分析往往會停留在體驗層面而不會繼續深入。
拆解文件則會更多從落地的角度出發考慮設計,正如前文所說,“拆解是設計師學習塑造體驗的方式”,在拆解某些具體設計時,我們時常會揣摩設計師的動機與意圖,對個人風格強烈的作品進行拆解就像是直接和創作者進行一場對話一樣生動有趣,當然這往往也意味著大量時間與精力的投入。
結語
筆者認為拆解的本質,就是將抽象的體驗具體成規則,並在歸納與模仿中演繹出自己所期望的體驗。
筆者認為,無論是設計本身還是在學習設計的過程中,都是不存在絕對正確的方法論和思維方式的,如果文中的觀點與螢幕前的你能產生共鳴,那筆者自然是不甚榮幸,而如果你對筆者的觀點持有否定意見,也歡迎一起探討交流。
相關文章
- 學習是ssm框架的一點點感悟與思考SSM框架
- WSL 中學習 Laravel 過程中的一些配置Laravel
- 關於DDD學習過程中的一些疑問
- 分享一些自己的學習過程和學習方法
- 學習和使用 Vue 過程中的一些資源分享Vue
- 關於前端的思考與感悟前端
- 高校天文共享平臺開發過程中的一些思考
- 深度學習的一些思考深度學習
- Java學習過程的一些重點(轉)Java
- 學習自動化測試的一些感悟
- 商業即生活,一些思考和感悟
- 【DATAGUARD 學習】學習DATAGUARD 過程中遇到的問題
- 學習憤怒的小鳥:對Android遊戲的一些思考Android遊戲
- 一些JavaSE學習過程中的思路整理(主觀性強,持續更新中...)Java
- 學習Python中的一些小遊戲Python遊戲
- 關於學習過程中走過的彎路
- 學習vue過程中遇到的問題Vue
- golang中關於死鎖的思考與學習Golang
- 在linux中減小和增大LV的過程與思考Linux
- Hadoop平臺學習過程的一些總結Hadoop
- memcached的學習過程
- java的學習過程Java
- 【筆者感悟】筆者的學習感悟【十】
- 【筆者感悟】筆者的學習感悟【九】
- 學習C過程中的筆記系列-2筆記
- 程式設計中的一些感悟程式設計
- 經驗篇:對商業分析的一些思考和感悟
- 在學習OCLint自定義規則的過程中對AST的一些總結AST
- 《戀與深空》遊戲拆解遊戲
- 如何學習Java? 在學習Java的過程中需要掌握哪些技能?Java
- 遊戲開發雜記(三) 開發及學習過程中的體會遊戲開發
- Java學習過程Java
- 軟體測試過程中的痛點思考
- munium學習過程中問題解決
- docker學習系列16使用過程的一些經驗總結Docker
- DDD學習與感悟——向屎山衝鋒
- DDD 學習與感悟 —— 向屎山衝鋒
- 整理debian安裝過程中的一些問題與方法