如何利⽤結構化思考，去設計遊戲系統？

前言

在遊戲設計中，思考方式本身不存在孰優孰劣，但在某些應用場景中，更適合的思考方式能夠更容易得出更健壯的結果。

本文無意爭論思維方式的好與壞，只是分享一種思考的方式，供設計師們參考。

什麼是結構化思考？

我所認為的結構化思考更多是一種將事物本質進行結構分類，以及將各部分結構之間聯絡梳理清楚的思考方式。

以一個簡單例子說明，在一般遊戲公司中，

一般會把負責遊戲設計的人員稱之為“策劃”，

負責美術製作稱之為“美術”，

負責遊戲實現稱之為“開發”，

同樣的還有運營市場等等······

這種劃分方式叫做組織“結構”劃分，這其實就是典型的”結構化“分類。

將事物本質按照特定的邏輯關係，分類成不同結構，並且將結構之間的邏輯聯絡梳理清楚，這就是我所理解的結構化思考。

當然，按照上述例子而言，每個結構之下可以繼續進行細分分類，譬如策劃可以分為系統、數值等，只要有需要，理論上可以無限拆分。

那麼何時為思考完成呢？

因人、因事而異，當設計者認為當前結果已經足夠完善即可。

怎麼用 —— 以房間系統為例項

回到正題，那麼在遊戲系統設計中，如何利用結構化思考呢？

我個人而言會從三點去進行：

• 按照一定邏輯關係拆分結構。
• 簡單將結構聯絡起來（不需要太精準）。
• 深入拆解結構之間的資料的輸入輸出。
• 基於第三步的結果，進一步優化結構或者生成有必需的分支結構。
• 重複上述2,3,4步，直至結構以及結構之間的聯絡是足夠精準的。
  

上面幾點有不說人話的嫌疑。

下面以一個簡單遊戲系統，房間系統為例子，講述整個過程。

先說房間系統的需求，用相對淺顯的語言描述就是，

“房間是為彙集不同玩家成一個個小群體而提供臨時場所，它提供的是玩家進入遊戲前的過度”。

但實際上，這依舊是一個相對模糊的需求，怎麼樣的“”不同玩家”？不同玩家是怎麼樣分類的？需要怎麼樣的過度？過度是為了什麼？

梳理問題，以及解決問題，可能這本身就是設計師的工作。

讓我們開始吧。

首先，先分析需求的本質，房間目的是為了分類不同玩家，讓符合一定標準的玩家更好地一起進行遊戲。

那麼，第一步，房間系統的主體結構可以拆分為：


第二步，簡單將結構聯絡起來。


結構相互之間關係為，使用者進入到房間，房間將聚集好的使用者輸入到戰鬥中，戰鬥完成後，將結果反饋到使用者當中。

這裡的結構之間聯絡肯定是不夠周全的，但先從最明顯的關係出發。

第三步，深入拆解結構之間聯絡。

先從使用者—>房間開始，使用者是以怎麼樣的方式進入到房間呢？


對於房間來說，使用者的進入，可以理解為不同的使用者資料輸入，這部分資料需要按照一定標準進行分類，目的是把玩家分成不同群體，每個群體即為一個房間。

這裡需要一種對使用者資料的篩選處理方式，一般情況下有下面三種，

匹配：按照一定規則，將使用者特徵相符合的玩家聚集在一起；適用大部分公平競技遊戲。

房間號：提供房間號，將輸入相同房間號的玩家聚集在一起（好友邀請進入同理）；適用於個性化房間，即方便玩家自由組隊。

房間列表：玩家建房間，客戶端提供可用房間列表，其他玩家進行挑選；適用於有模式或者地圖選擇的遊戲，如CSGO。

一般情況下，如果沒有對整體結構有清晰認知，房間系統的設計往往約等於匹配系統設計或者房間列表設計，執著於具體的篩選方式。當然，這部分或許是整個房間系統最重要的部分，但是也只是一部分，一個完整的系統需要完整的閉環。

經過篩選後，符合條件的使用者就會變成一個房間，房間需要輸出房間資料，而不符合要求的玩家，則需要駁回到使用者。

根據上述思路，我們可以得出以下結構：


第四步，在第三步的思考的基礎上，實際上需要一分支結構。

思考到這個階段，很容易就出現了疑惑，單純把玩家聚集在一起，就足夠了嗎？

但實際上很多情況下，玩家進入到房間，實際上還有非常多操作需要進行，譬如在MOBA遊戲當中選擇英雄和技能等。

既然使用者有相當大的一部分資料是需要在房間內進行的，因此這部分房間資料實際上需要返回給使用者，使用者再進入下一個階段，我稱之為使用者準備階段。

使用者完成準備階段後，實際上是將房間內的使用者個人資料、房間資訊、準備流程資料一起輸出到遊戲戰鬥中，戰鬥模組根據該部分資訊生成戰鬥。

根據上述思路，我們可以得出以下結構：


根據遊戲種類的不同，使用者在房間內的準備流程各不相同，流程基準是能夠產生生成戰鬥所需的必須資料資訊。

第五步，需要從第二步開始，重複2,3,4步，繼續深化結構與結構之間的聯絡。

當房間完成其任務後，自然將其輸出的資料，輸入到遊戲戰鬥模組當中，去生成戰鬥。

此時要做的是，深化房間—>戰鬥的聯絡。


戰鬥模組各不相同，實際上只要保證生成戰鬥的必須資料，房間能夠提供即可。

可得出以下結構：


同理，繼續深化戰鬥與使用者之間的聯絡。


當戰鬥結束後，產生的結果需要給予使用者反饋，譬如誰勝利了，拿了多少分等等，這些可能在戰鬥流程就完成，但也有可能需要在戰鬥外處理。

除了結果外，戰鬥還會對現有資訊產生一些變更，如使用者的個人資訊（KDA，勝率，常用槍支角色等等），這些資料，需要使用者系統自行進行處理。

可以得出以下結構：


當思考到這一步後，我們繼續重複第四步，有可能的分支漏了嗎？

一個非常明顯的問題，戰鬥結果的資訊需要返回給房間嗎？房間部分需要戰鬥的一些資訊嗎？


實際上，是需要的。房間在戰鬥結束後，需不需要根據結果的資料，保留房間還是銷燬房間？房間內的角色是否缺失了？房間內的陣營這些資訊會影響玩家準備階段嗎，還是直接可以帶入到下一盤當中？

顯然這些疑問都需要戰鬥產生的結果資訊反饋到房間當中，所以實際的優化結構是：


戰鬥反饋結果到房間的結構是：


在此為止，整個房間系統就完成自我的系統閉環，可暫時視為已經完成結構化思考。當然，因為是介紹限制，在實際使用中，還可以繼續對結構進行深化，直到達到自己認為完善的標準。

在達到自己認為完善的標準後，就可以對結構中每一部分進行深化了，譬如，到底是用匹配規則還是房間列表方式，使用者資料有哪些，組成房間後，內部準備流程是怎麼樣的等等······基於結構進行詳細設計的過程，會使整個設計脈絡更加清晰。

總結 —— 結構化思考的優缺點

結構化思考並不能直接得出一個完整的系統，可做的是將整個系統骨骼搭建起來，為之後的互動規則、具體機制設計提供支撐。

對於一些十分熟練的設計師，可能稍顯浪費時間，但結構化思考是存在一定價值的，下面將會總結一下結構化思考的優缺點。

首先，談談優點。

• 比較易懂，清晰，好用，**起來沒煩惱。無論是主策還是實際設計落地的設計師，基於整個結構化進行討論（**），都會更加有效率。在系統設計前期，討論太多的互動細節容易擾亂其他人思維，同時，清晰的系統結構確定後，會極大減少返工的可能性，這一點無論是實際設計，還是實際開發中，都很重要。
• 邏輯點不容易漏。在結構化思考的過程中往往比較容易查漏補缺，就像上述房間系統需求當中，在深化結構與結構之間的聯絡過程中，往往能夠排查出思考過程少了的部分。
• 擴充套件性強。當以後有新的需求需要加入時，可以很清楚瞭解新需求應該加入到哪一部分當中，結構的哪一部分變更了，從而更加直接找出需要變更修改的地方。
• 系統排錯能力強。當實際驗收過程中，發現錯誤時，大部分錯誤能夠根據結構流程，快速找出其導致錯誤的原因，腦海裡會比較清晰瞭解到底是哪部分結構卡殼了導致現有問題。
  

當然，這種思維方式肯定存在缺點。

• 只適合確定性比較強的遊戲功能系統，對創造性需求較強的結果效果比較弱。對未見過，認知比較少，或者需要較強創造性的需求時，效果不好，特別是遊戲藝術部分，但對一些確定性比較強的部分，譬如好友、公會等系統，結構化思考的優勢就會顯然易見了。
• 思考容易受限，特別是在結構化基本成型後。思考的邊界往往擺脫不了現有已經成型的結構，這也是為什麼結構化思考不太適合藝術創作的原因，突破思考邊界的最有效的方式往往是交流。
• 結構一旦出錯，往往都不是什麼小事。這個，可能不用多說了。
  

結論：

我很喜歡埃隆·馬斯克所提倡的“第一性原理“思考的法則，我認為結構化思考的本身就是第一性原理思考的延伸。

結構化思考帶來的是整個系統的設計支撐，它本身不會直接輸出一個完整的結果，如果說遊戲開發是基於設計者的設計圖，去開發整個系統，那麼結構化思考更多是”設計圖“本身的“設計”。

如前言所描述的，在遊戲設計中，思考方式本身不存在孰優孰劣，但是合適的思考方式，幫助我們更容易的得出更周全的結果。希望這次分享的思維方式能夠幫到你，也希望能夠交流不一樣的思考方式。

我是三季人，歡迎關注遊戲設計思維（知乎號、微訊號同名）。

筆者是遊戲從業者，專注於遊戲和遊戲設計，歡迎交流互噴，一起共同成長。

一片赤誠之心，致我們熱愛的遊戲。