[[172015]]

在這個系列中，我們基于多人游戲 貪吃蛇 來制作一個異步的 Python 程序。上一篇文章聚焦于編寫游戲循環(huán)上，而本系列第 1 部分則涵蓋了如何異步化。

• 代碼戳這里 

4、制作一個完整的游戲 

4.1 工程概覽

在此部分，我們將回顧一個完整在線游戲的設計。這是一個經(jīng)典的貪吃蛇游戲，增加了多玩家支持。你可以自己在 (http://snakepit-game.com) 親自試玩。源碼在 GitHub 的這個倉庫。游戲包括下列文件：

• server.py - 處理主游戲循環(huán)和連接。
• game.py - 主要的 Game 類。實現(xiàn)游戲的邏輯和游戲的大部分通信協(xié)議。
• player.py - Player 類，包括每一個獨立玩家的數(shù)據(jù)和蛇的展現(xiàn)。這個類負責獲取玩家的輸入并相應地移動蛇。
• datatypes.py - 基本數(shù)據(jù)結構。
• settings.py - 游戲設置，在注釋中有相關的說明。
• index.html - 客戶端所有的 html 和 javascript代碼都放在一個文件中。

4.2 游戲循環(huán)內(nèi)窺

多人的貪吃蛇游戲是個用于學習十分好的例子，因為它簡單。所有的蛇在每個幀中移動到一個位置，而且?guī)苑浅５偷念l率進行變化，這樣就可以讓你就觀察到游戲引擎到底是如何工作的。因為速度慢，對于玩家的按鍵不會立馬響應。按鍵先是記錄下來，然后在一個游戲循環(huán)迭代的最后計算下一幀時使用。

現(xiàn)代的動作游戲幀頻率更高，而且通常服務端和客戶端的幀頻率是不相等的。客戶端的幀頻率通常依賴于客戶端的硬件性能，而服務端的幀頻率則是固定的。一個客戶端可能根據(jù)一個游戲“嘀嗒”的數(shù)據(jù)渲染多個幀。這樣就可以創(chuàng)建平滑的動畫，這個受限于客戶端的性能。在這個例子中，服務端不僅傳輸物體的當前位置，也要傳輸它們的移動方向、速度和加速度。客戶端的幀頻率稱之為 FPS(每秒幀數(shù)(frames per second))，服務端的幀頻率稱之為 TPS(每秒滴答數(shù)(ticks per second))。在這個貪吃蛇游戲的例子中，二者的值是相等的，在客戶端顯示的一幀是在服務端的一個“嘀嗒”內(nèi)計算出來的。

我們使用類似文本模式的游戲區(qū)域，事實上是 html 表格中的一個字符寬的小格。游戲中的所有對象都是通過表格中的不同顏色字符來表示。大部分時候，客戶端將按鍵的碼發(fā)送至服務端，然后每個“滴答”更新游戲區(qū)域。服務端一次更新包括需要更新字符的坐標和顏色。所以我們將所有游戲邏輯放置在服務端，只將需要渲染的數(shù)據(jù)發(fā)送給客戶端。此外，我們通過替換通過網(wǎng)絡發(fā)送的數(shù)據(jù)來減少游戲被破解的概率。

4.3 它是如何運行的?

這個游戲中的服務端出于簡化的目的，它和例子 3.2 類似。但是我們用一個所有服務端都可訪問的 Game 對象來代替之前保存了所有已連接 websocket 的全局列表。一個 Game 實例包括一個表示連接到此游戲的玩家的 Player 對象的列表(在 self._players 屬性里面)，以及他們的個人數(shù)據(jù)和 websocket 對象。將所有游戲相關的數(shù)據(jù)存儲在一個 Game 對象中，會方便我們增加多個游戲房間這個功能——如果我們要增加這個功能的話。這樣，我們維護多個 Game 對象，每個游戲開始時創(chuàng)建一個。

客戶端和服務端的所有交互都是通過編碼成 json 的消息來完成。來自客戶端的消息僅包含玩家所按下鍵碼對應的編號。其它來自客戶端消息使用如下格式：

[command, arg1, arg2, ... argN ] 

來自服務端的消息以列表的形式發(fā)送，因為通常一次要發(fā)送多個消息 (大多數(shù)情況下是渲染的數(shù)據(jù))：

[[command, arg1, arg2, ... argN ], ... ] 

在每次游戲循環(huán)迭代的最后會計算下一幀，并且將數(shù)據(jù)發(fā)送給所有的客戶端。當然，每次不是發(fā)送完整的幀，而是發(fā)送兩幀之間的變化列表。

注意玩家連接上服務端后不是立馬加入游戲。連接開始時是觀望者(spectator)模式，玩家可以觀察其它玩家如何玩游戲。如果游戲已經(jīng)開始或者上一個游戲會話已經(jīng)在屏幕上顯示 “game over” (游戲結束)，用戶此時可以按下 “Join”(參與)，來加入一個已經(jīng)存在的游戲，或者如果游戲沒有運行(沒有其它玩家)則創(chuàng)建一個新的游戲。后一種情況下，游戲區(qū)域在開始前會被先清空。

游戲區(qū)域存儲在 Game._field 這個屬性中，它是由嵌套列表組成的二維數(shù)組，用于內(nèi)部存儲游戲區(qū)域的狀態(tài)。數(shù)組中的每一個元素表示區(qū)域中的一個小格，最終小格會被渲染成 html 表格的格子。它有一個 Char 的類型，是一個 namedtuple ，包括一個字符和顏色。在所有連接的客戶端之間保證游戲區(qū)域的同步很重要，所以所有游戲區(qū)域的更新都必須依據(jù)發(fā)送到客戶端的相應的信息。這是通過 Game.apply_render() 來實現(xiàn)的。它接受一個 Draw 對象的列表，其用于內(nèi)部更新游戲區(qū)域和發(fā)送渲染消息給客戶端。

我們使用 namedtuple 不僅因為它表示簡單數(shù)據(jù)結構很方便，也因為用它生成 json 格式的消息時相對于 dict 更省空間。如果你在一個真實的游戲循環(huán)中需要發(fā)送復雜的數(shù)據(jù)結構，建議先將它們序列化成一個簡單的、更短的格式，甚至打包成二進制格式(例如 bson，而不是 json)，以減少網(wǎng)絡傳輸。

Player 對象包括用 deque 對象表示的蛇。這種數(shù)據(jù)類型和 list 相似，但是在兩端增加和刪除元素時效率更高，用它來表示蛇很理想。它的主要方法是 Player.render_move()，它返回移動玩家的蛇至下一個位置的渲染數(shù)據(jù)。一般來說它在新的位置渲染蛇的頭部，移除上一幀中表示蛇的尾巴的元素。如果蛇吃了一個數(shù)字變長了，在相應的多個幀中尾巴是不需要移動的。蛇的渲染數(shù)據(jù)在主類的 Game.next_frame() 中使用，該方法中實現(xiàn)所有的游戲邏輯。這個方法渲染所有蛇的移動，檢查每一個蛇前面的障礙物，而且生成數(shù)字和“石頭”。每一個“嘀嗒”，game_loop() 都會直接調(diào)用它來生成下一幀。

如果蛇頭前面有障礙物，在 Game.next_frame() 中會調(diào)用 Game.game_over()。它后通知所有的客戶端那個蛇死掉了 (會調(diào)用 player.render_game_over() 方法將其變成石頭)，然后更新表中的分數(shù)排行榜。Player 對象的 alive 標記被置為 False，當渲染下一幀時，這個玩家會被跳過，除非他重新加入游戲。當沒有蛇存活時，游戲區(qū)域會顯示 “game over” (游戲結束)。而且，主游戲循環(huán)會停止，設置 game.running 標記為 False。當某個玩家下次按下 “Join” (加入)時，游戲區(qū)域會被清空。

在渲染游戲的每個下一幀時也會產(chǎn)生數(shù)字和石頭，它們是由隨機值決定的。產(chǎn)生數(shù)字或者石頭的概率可以在 settings.py 中修改成其它值。注意數(shù)字的產(chǎn)生是針對游戲區(qū)域每一個活的蛇的，所以蛇越多，產(chǎn)生的數(shù)字就越多，這樣它們都有足夠的食物來吃掉。

4.4 網(wǎng)絡協(xié)議

從客戶端發(fā)送消息的列表：

從服務端發(fā)送消息的列表：

典型的消息交換順序：

5. 總結

說實話，我十分享受 Python 最新的異步特性。新的語法做了改善，所以異步代碼很容易閱讀。可以明顯看出哪些調(diào)用是非阻塞的，什么時候發(fā)生 greenthread 的切換。所以現(xiàn)在我可以宣稱 Python 是異步編程的好工具。

SnakePit 在 7WebPages 團隊中非常受歡迎。如果你在公司想休息一下，不要忘記給我們在 Twitter 或者 Facebook 留下反饋。