手把手教你做遊戲玩法開發

#01：遊戲玩法開發的定義

遊戲玩法開發的定義比較模糊，目前在業界未有完全的定論，主要是指與玩家互動行為相關的遊戲功能和行為的開發。


技術與設計的銜接

中國的遊戲團隊，在傳統上認為遊戲玩法開發是技術與設計的交叉點，是MMORPG（Massive Multiplayer Online Role-Playing Game，大型多人線上角色扮演遊戲）時代的工作習慣導致的。在MMORPG時代，遊戲玩法是以數值為核心，結合流水線思維開發的產物。由於我國工業化時間較短，藝術和文娛行業經歷過斷代，所以遊戲開發參考工業發展歷程，從而衍生流水線思維。

技術與設計的融合

而西方團隊，一般認為遊戲玩法開發是技術和設計的融合，其中融合部分更多的包括技術和設計部分。最初，因為西方遊戲開發團隊規模小，並沒有遊戲設計師的概念。所以在FC時代，甚至PS時代，很多遊戲團隊的設計工作，都是由程式設計師和美術師兼職完成。基於此，西方遊戲團隊更傾向於用創作者的思維進行遊戲玩法開發。而且因為現代獨立遊戲的興盛，西方很多人會對工業化流水線的流程反感。

技術、設計與藝術的統一

技術、設計與藝術的統一，是遊戲開發的終極形態，少數頂尖開發者可以做到。這個要求其實並非嚴苛，因為遊戲玩法開發團隊需要作為核心部分，從確定願景開始，參與遊戲的原始設計以及遊戲的開發週期，會銜接眾多的生產環節。例如美術、聲音，甚至是運營、市場等，這些環節都是與遊戲玩法直接相關的。所以，遊戲玩法開發需要一個真正的多面手來完成。


#02：建立願景

建立願景，是所有遊戲專案開發過程的第一步，也是最重要的一步。無論是做單人開發者的簡單小型獨立遊戲，還是成百上千人的大型專案，第一步都是需要有願景。


願景的定義

願景是描述遊戲最核心、最重要的部分。清晰的願景是專案成功的保障，但問題在於，願景本身可能比較模糊。所以，很多時候需要通過迭代、通過專案的進展來解決願景模糊的問題，隨著專案進展，願景可能會隨之變化。

很多專案會有一個負責人作為Vision Holder，例如著名的遊戲製作人小島秀夫，例如頑皮狗工作室的最後生還者，有一個比較清晰的製作人；但也有很多遊戲的製作人並不明確，例如《使命召喚（Call of Duty）》。

一個遊戲專案是否有一個人作為明確的Vision Holder，其實沒有那麼重要。因為願景是否清晰的標準，在於執行者是否清晰。

另一方面，不是隻有Creative Director才可以考慮願景，願景也不是僅存在於大型遊戲專案中。我們做一個很小的東西也有願景，例如子系統。

傳達願景的方式

傳達願景的方式多種多樣，不僅限於專案文件。國內團隊，在很多情況下喜歡用Excel、Word、網頁或長篇大論的設計文件來傳達設計願景，但如果執行者不看或者沒有看懂文件，也是無意義的。

無論如何，評價設計願景的標準依然是：執行者是否清晰。因此，願景最重要的是存在於執行者的心裡。我們應該運用表演、寫、畫、舉例參考等一切途徑去儘可能清晰地傳達願景。

傳達願景之後，需要傳達者和執行者一起達到結論與共識。執行者通過結論與共識，才能最後執行這個過程，所以結論與共識也是在遊戲中看到的最後狀態。但是，在落實到實際工作中時，還會有不同的情況和變化。

三消願景

下面通過三消遊戲的例項，來講解具體如何建立願景。

在做三消遊戲前，首先嚐試建立願景。按照標準的三消遊戲，大致玩法如下：當磚塊下落，玩家可以交換磚塊的位置，三個顏色相同的磚塊連在一起就會消失。

但清晰地傳達願景並不容易，可能僅通過描述遊戲玩法和具體的流程圖，也並不能明確願景是什麼。例如三消遊戲，如果大家沒有玩過，當看到遊戲玩法描述和流程圖時，只能想到俄羅斯方塊遊戲。


我們參照一個已經存在的三消遊戲進行描述，或許會對三消遊戲的願景更加清晰一些。比如：

① 首先，解釋這是一個N×M尺寸的、佈滿磚塊的板子；

② 然後給三消和Match下定義。三個或三個以上同色磚塊連成一線叫Match，形成Match的磚塊會消除並加分；

③ 最後，闡釋玩家的操作是可以交換相鄰兩磚塊的位置來形成Match，消除後的空位，會由上方的磚塊自動下落補充。

通過一個其它遊戲的例子，可以更加明晰願景。但明確願景之後，它仍然只有大概輪廓，具體的細節仍不明確。

因此，下一步需要用到分治策略。分治策略是遊戲玩法開發中比較重要的一個思維方式，比如程式設計中的很多演算法的實現都會用到此策略。

分治策略

分治策略（Divide and Conquer），簡單來講就是將一個大的任務分解成幾個小的任務，從而一個個去攻克。對於願景來說，分治是按照個人或團隊的工作習慣，將其分拆為易於實現的模組。

分治策略也可以用於分析成品遊戲，例如大家比較熟悉的遊戲《超級瑪麗》：


根據上方的圖片，我們使用分治策略，大概能拆出關卡、地形、主角、敵人、水管、金幣、分數等元素。如果我們要做這個遊戲，當使用拆分方法與團隊的其他成員一起討論時，可能會面臨一些問題：例如

① 分數是應該算給主角還是敵人？

② 水管只是水管，還是算關卡或者地形的一部分？

③ 關於火球和飛錘，做飛行物的程式設計師會認為兩者屬於同一類，都是在做飛行物系統時所用的。但其他人可能認為，漂浮在空中的金幣，也算一種飛行物。

其實，這些問題沒有絕對的答案。新團隊可能會因此陷入爭吵，但並沒有必要糾結這些，此階段最重要的是往下推動程式。

三消拆解


仍然以三消遊戲為例做三消遊戲的拆解，其要素大致分為：世界、板子、磚塊、計分板、選單。

世界是整個遊戲的容器，包括關卡、道具、玩家形象等；板子是每一個關卡的靜態要素之和；磚塊是畫面中掉落和玩家會去拖動的東西，即畫面中的動態要素。

但這樣拆解後，則會出現一些問題和矛盾：例如

① 磚塊會佔據一個格子，如果磚塊消除了，剩下的格子是什麼呢？它可以算是板子的一部分嗎？

② 假如遊戲沒有關卡，只有一關，板子和世界是一起的，還是獨立的呢？

③ 假如遊戲有勝利的規則，如何界定遊戲勝利，是消除到達一定分數還是時間結束為零？勝利的規則是由世界管理還是由板子管理？

這些問題可以暫不做爭論，我們介紹一個簡單的原則：K.I.S.S.。

K.I.S.S.（Keep It Simple and Stupid）

K.I.S.S.，指的是Keep It Simple and Stupid（保持最簡）。當有A、B、C三個可供選擇的方案時，我們不確定A、B、C哪一個方案是好的，此時可以選擇一個最簡單的方案，先做最好做的方案。

雖然有人認為這種做法太缺乏計劃性，但是在遊戲專案，尤其是在玩法開發上，不確定性是非常突出的特點。遊戲玩法開發並不是一個單純的技術性工作，當出現不確定性時，團隊可能會爭論，甚至產生一種恐懼感。爭論和恐懼感便會影響團隊決策，進而導致專案無法推進並且按時完成，最終可能會導致遊戲無法上線。很多時候，我們不知道外部環境會怎樣變化，也不清楚現在對於未來思考的決策，將來是否能奏效，所以不如使用此原則：Keep It Simple and Stupid（保持最簡）。

除了K.I.S.S.之外，在業界比較流行的概念，還包括：

① YAGNI-You ain’t gonna need it（忌引而不發），主要指我們為未來做的一些準備工作，如果現在不用，將來很有可能會用不上。所以，基於“忌引而不發”的原則，我們沒有必要過多提前準備，可以等需要的時候再去做。

② If it ain’t broke don’t fix it（忌未雨綢繆），主要指做的內容有瑕疵時，先不用急著解決，待出現問題時再解決。


使用K.I.S.S.原則，對拆解的三消元素進行簡化。例如如果板子不確定，可以先把它放到世界中，不單獨列出來；磚塊所佔的格子不確定，也可以先放到世界中。這樣便只剩下世界和磚塊兩部分內容。

世界是所有靜態要素，磚塊是所有動態要素。此時，很多不確定性問題都已解決，同時專案的Scope（邊界）也會變得清晰。

#03：劃定邊界


對於一個專案來說，Scope（邊界）是非常重要的一部分，因為Scope決定了我們需要的資源，包括時間、金錢等。

無論是一個人的獨立遊戲，還是一千人做的大型遊戲，都需要確定Scope，Scope與Vision是兩個最重要的事情。


接下來，便可以開始實際動手寫程式碼，這裡展示的程式碼都是簡單的虛擬碼而不是實際程式碼。


上圖是磚塊類別和World類的虛擬碼。

左側程式碼，將磚塊的類別按顏色進行定義。這裡我們犯了“引而未發”的錯誤，我們假設將來有合成炸彈的機制，但在整個三消遊戲完成之後，也沒有用到。

世界類也比較簡單，我們可以先用一個map對映，把它與實際的影像對應起來，然後再定義世界的大小，例如10×10，最後寫一個相機定義解析度。

在這裡，介紹一個我個人的經驗，即快速上屏原則：通過越少的工作量，儘早的在螢幕上看到雛形，專案就會推進得越順利。因為我們在看到具象的內容之後，才能與別人開始討論並且有目的地改進它，而不是紙上談兵。程式碼本身也只是一種文件，它經過編譯後無論是變成機器碼還是什麼形態，最終只有執行起來，才是我們要的結果。

#04：迭代

迭代的核心想法就是快速試錯，面對設計的不確定性，我們應該去擁抱它。這與上文的K.I.S.S.原則也是一致旳。

因為直到遊戲專案上線之前，遊戲設計都會遇到很多不確定性因素。設計的不確定性，本質上是因為現有的資訊不足以支撐決策。“想好就不要改了”的狀態是很難實現的，市場一直在變，玩家一直在變，專案的狀態也會一直變。


迭代迴圈

由設計出發，到實現、體驗、反饋，最後再到設計形成一個迴圈，是一次迭代；多次迴圈此過程，就是迭代迴圈。

如果要進行快速試錯，則需降低單次的迴圈成本。迭代，本質上是時間上的一種分治策略。每當完成一個階段時，都需要反覆問自己：What’s Next（下一步是什麼）?其目的是推進專案的快速進行、順利完成專案。

物件導向


物件導向，是程式設計中的一種把資料和邏輯打包的思想正規化。

例如，皮卡丘這一個體，它對應的種類就是皮卡丘，有等級、生命值、攻擊、閃避、進化等屬性，把相關的程式碼打包在一起，構成一個類，這個類就是一個物件。把相關的程式碼集中管理，其目的是便於維護和重用。現代很多商業引擎便是如此，Unity和Unreal中，有Actor、GameObject等。它是把影像、模型、聲音等所有元素都放在一起，把程式碼也放在其中，這就是一個物件。

物件是可以繼承的。假如皮卡丘進化成了雷丘，雷丘的攻擊等行為就可以直接繼承皮卡丘的屬性。

但物件導向並不是唯一的正規化。例如《使命召喚》的引擎，不是C++，而是純C語言。C語言則不是一個物件導向的語言，它的編輯器也不是物件導向的。


以上表為例，如果不從程式的角度看，它並不是一個物件導向的正規化。遊戲策劃可能並不在乎每一個物件裡面所包含的內容；他在乎的，是每一個物件裡的幾類重要內容以及它們之間的關係。

所以，設計不一定必須物件導向。很多時候，物件導向並不一定是最好的解決辦法，大家要把正確的工具用在正確的地方。


磚塊，是一個比較自然的、可重複出現的個體，而且我們關注它的值。所以我們先把磚塊寫成一個物件。如上圖，程式碼上半部分是磚塊的屬性，下半部分是磚塊的起點、終點和移動方向等。磚塊的移動，則需用插值函式完成。

插值（Interpolation）


插值相關的術語有：Lerp（Linear Interpolation，線性插值）、Interp,、MapRange、 Bezier/Hermite curve（貝塞爾/埃爾米特曲線）等。

插值，簡單講就是一條直線或曲線，當X變化時Y發生相應的變化。它屬於很基礎的內容，但應用範圍很廣泛，在平常的工作中可以解決大部分的“過渡”問題。螢幕上大量炫酷的動畫，都可以用插值來完成。如上圖中的例子，藝術師就只做了幾個關鍵幀，中間過程則由插值完成。無論是三十幀、六十幀還是九十幀，都可以看起來很平滑，這其實也是一種Divide And Conquer的概念。

玩家輸入


關於磚塊的交換行為，有兩種設計思路：第一種，是玩家點選選中磚塊，再選擇相鄰磚塊，將二者互換；第二種，是玩家向某方向拖拽磚塊，磚塊與相鄰的該方向磚塊交換位置。

第一種設計比較容易實現，但將複雜性留給了玩家。如果是用手機玩此遊戲，玩家可能會遇到點錯、點不中或手滑的問題。

第二種設計比較複雜，因為玩家的手勢判斷很難確定。此時，我們可以做一個折中方案，在方案二的基礎上進行簡化。不做標準的拖拽動作，而改用摁下（MouseDown）和抬起（MouseUp），並明確邊界：一共四個方向，只考慮從摁下去到抬起來的點，這個點落在哪個區間，磚塊就與該區間的相鄰磚塊交換位置。這種折中的方案沒有比第一種複雜太多，只多了一點數學計算，但是又大致實現了第二種思路。這裡是KISS原則的一個體現。

磚塊銷燬


最後，我們需要做的是磚塊的出生和銷燬。銷燬的實現，只需刪除並加一個簡單的特效就可以。實際的程式碼中，則需要處理一些引用關係，例如某個磚塊刪除後會留下空位，某個磚塊有引用指向，另外一個磚塊需要跟它交換，這些情況都需要進行處理。

假如我們做了一個很好的刪除和播放的特效，但前提是磚塊需要三消，必須要攢齊三個才能觸發。此時，我們可以先暫時不用處理，可以先寫一些臨時的測試邏輯。三消遊戲的情況比較簡單，可能不需要寫測試邏輯，但也會有其他更復雜的情況。

例如《絕地求生》遊戲裡有可以在山坡上開的摩托車，我們做好車之後去和團隊交流，可能發現車做好了但是玩家部分還沒做好。此時，雖然工作量很大，但一般情況下，我們也需要再寫一個複雜的邏輯，來讓玩家一進入到關卡，立刻就能開上摩托車。經常驗證，也是一種分治的概念。它可以防止我們把所有東西都留在上線或驗收之前一起驗收，以防所有東西一起驗證出現問題。

磚塊下落


磚塊消除後，相鄰磚塊會有下落的動作。磚塊下落有兩種處理方式：

空位上方的所有磚塊共同下落、磚塊一個個下落。共同下落的處理方式有些複雜，我們可以讓磚塊一個個下落補空位。其優點就是可以套用磚塊的交換邏輯，不用再寫複雜的下落邏輯，把上下磚塊相互調換或調一調數值即可，下落效果還是不錯的。但在其中可能會有特別多bug，例如某個黃色磚塊落到它下面的格子，假如它落下的位置相鄰兩個格子都是黃色磚塊，這行在下落的過程中、整個畫面還沒有穩定時，就直接消除了。因為消除的邏輯是在每一次下落以後檢查Match Three，落一格檢查一次，這時就會出現bug。

生成新磚塊


如果有空格子，上面的磚塊會落下，然後頂端會生成新的磚塊一起落下來。把按照空位數量在頂端生成新磚塊和磚塊下落作為一個問題太複雜，我們可以簡化成讓磚塊一個個生成，這樣的處理方式還可以解決第一屏的問題。

第一屏問題，是指一開始螢幕裡生成了所有的磚塊後，有可能出現三個同色相連的磚塊，但MatchThree程式是在磚塊下落的時候才進行檢測，所以已有的程式無法消除這三個磚塊。但我們可以讓磚塊一排排生成，待頂端生成一排再下落，然後再生成一排下落，這樣就可以解決此問題。

檢測三消（MatchThree）


檢測三消是觸發磚塊銷燬的過程，此過程僅在磚塊移動後發生，其實也是對演算法的一種優化。此演算法的執行代價比較昂貴，假如有一萬個磚塊，如果只能對磚塊一個一個檢測，這個檢測演算法可能需要執行千萬次。在實際玩法中會經常遇到這種情況，所以需要想辦法對其優化。優化也是一種分治策略，包括時間分治和空間分治。

優化檢測屬於在時間上分治，如果在特定事件發生以後再執行操作，就不會出現每一幀、每一個都要檢測的情況，在時間上檢測發生的機率也就小很多。

但我們做的三消檢測仍是有一個bug：如果某個磚塊下落，它右邊相鄰格子不同色，但左邊相鄰兩個個格子同色，這種情況下不會發生消除。因為演算法只檢測下落磚塊的上下左右四個方向，所以需要多檢測幾次。

測試和除錯


簡單的測試程式碼有很多用處。

首先，可以在功能完整實現之前，消除一部分錯誤。這樣可以避免所有錯誤集中到一起。

其次，我們可以有意地修改一些程式碼，幫助重現bug。因為有些bug比較特殊，只有在外部條件非常複雜時才會出現，但它出現的機率又不夠小，可能是萬分之一而不是百萬分之一。當遊戲中有百萬玩家的時候，則會有很多玩家碰到此bug。此時，我們需要進行測試，在擁有充足資訊的前提下，知道bug產生依賴的邏輯線，便可以進行修改，使程式只走這條邏輯線，從而幫助測試程式碼。

此外，還有一種更極端的方式，是有些遊戲的客戶端和伺服器是分開的，客戶端負責渲染，伺服器給客戶端發包指導客戶端進行操作。假如客戶端的邏輯是確定性的，即每次只要進行同樣的輸入，它會執行同樣的輸出。在這樣的條件下，可以把外部環境錄製下來。例如有些遊戲中錄影功能可以進行回放，假如在回放過程中渲染端出了任何的Bug，則都可以用比較高階的開發工具快速debug。

最後，有時測試甚至可以幫助迭代，加快個人的迭代速度。

雖然Log（螢幕訊息）被認為是原始社會的產物，但它有很多好處，它與debugger是兩種共存的元素。

debugger的優點在於，善於追蹤更深一層的邏輯樹，例如在一個點中看到的bug，實際邏輯不一定在這點發生了，可能是之前或之後的某一個資料出了問題。此時我們用Log（螢幕訊息）debug會非常困難，需要加很多內容以後，才會可能看到某些有問題的資料，而且在使用Log的過程中，還會出現打得過多，找不到要點的情況，但debugger就可以很好地發現問題資料。

但Log也有自身的優勢，它可以很清楚地看到bug，在大型團隊裡，非程式技術人員可以隨時開關Log把bug顯示在螢幕上，不用藉助編輯器，便可以直接截圖發給負責程式的人員，來簡單快速地進行debug。此外，許多遊戲發售之後，Log可能是唯一有效的執行手段。假如使用者崩潰了，我們可以獲取的只有一個Log。

輔助圖形（Debug Draw），就是在螢幕上畫一些條條框框，它與Log有相似之處。遇到bug直接截圖，並將相關的Debug Draw一起傳送給技術人員，技術人員就能直接明確問題出現在哪裡。

Debug Draw也可以進行輔助開發。例如一個敵人AI，其構成複雜，可能是機器人、殭屍、動物和人類的結合體，它的行為也比較複雜，可以使用十八般兵器。這時敵人AI做了一個動作，Creative Director認為在這個時間點不應該做此動作，便需要程式設計師去找原因。此時，假如我們把AI各個系統裡的引數、評估函式的結果等都畫出來，輸出到AI腦袋上方，我們或許就能明白動作的緣由。

斷言（Assert），是在寫一個函式時把值的預設提前寫出來。例如值應該是在0到1之間，或者值不應該是負的，當把它寫程式序時，如果程式崩潰出現問題，就會報錯，之後便可以明確出錯的問題。

但是程式崩潰也會造成新的問題，例如，正在做的編輯器希望設計師在文字框填一個0到1之間的數字，在寫了斷言後，設計師填上數字2之後編輯器直接崩潰了；如果在遊戲邏輯中寫了一個斷言，別人做了改動後，遊戲直接崩潰，最後會發現斷言失去作用了。這種情況下，常用的處理方式是自己寫一個斷言庫，出現斷言時只是把Call Stack（呼叫堆疊）調出來，而編輯器不會崩潰。

#05：拋光Polish


遊戲設計的最後一步是拋光，拋光是遊戲從功能到藝術的過程。

遊戲設計有一個MDA模型，指的是Mechanics, Dynamics, Aesthetics。例如，按下按鍵后角色走動，叫做Mechanics；如果角色身上著火，角色走動時把身邊的樹叢點著，不同系統之間引燃的互動，叫Dynamics（動態）；Aesthetics是從玩家視角描述的，比如我們剛才說玩家的走動和著火，其實從開發視角來看，只是某個屬性和特效從玩家轉移到樹叢上，而火/水的概念，就是Aesthetics的概念。

#06：開發者視角和玩家視角

開發者視角，從開發的角度看MDA，是以功能為基礎，再進行系統之間的動態互動，最後才是美的層面。

玩家視角，首先接觸到的是美學層面，然後再理解動態和功能，有一些玩家甚至不會理解功能。

所以，玩家與遊戲開發者看到的質量是有所區別的。玩家會很在乎小數值的不平衡、bug、卡頓崩潰等質量問題。例如，《刺客信條：大革命》遊戲，遊戲完整地還原了巴黎聖母院。但當它剛發售時，玩家因為頭髮系統、臉系統等出現問題、則會因為這些小bug對遊戲打出非常低的評分。但這些bug，對於開發者來說，可能感覺不是那麼嚴重，只是一些顯示錯誤而已。

拋光就是解決這個問題的。最重要的一點，在於開發者需要留出足夠的時間。因為功能做完後，其實並不算將整個遊戲做完，還需要做出遊戲的藝術效果。

來源：騰訊遊戲學堂
原文：https://mp.weixin.qq.com/s/7dz18aTtBS0unrA2OzkLtg