用Javascript給學生做個隨機發牌的案例。需要撲克的圖片素材。找到一張圖片，所有撲克圖案以6行9列的方式平均分布在整張圖片上。現在需要將其拆分為54個圖片。為此，向chatGPT提出如下要求：

用python編寫代碼，將圖片文件 allpokers.jpg 拆分為54張圖片。尺寸按照6行9列的方式平均拆分。拆分出的圖片以行號加列號命名保存。

以下是chatGPT將圖片文件 `allpokers.jpg` 拆分為 54 張圖片并保存的 Python 代碼。

以上代碼中，`split_image` 函數接受圖片文件路徑、行數和列數作為參數。它使用 PIL 庫打開圖片并獲取圖片的寬度和高度。然后，根據行數和列數計算每個拆分圖塊的寬度和高度。接下來，使用雙重循環遍歷每個圖塊的位置，并使用 `crop` 方法從原始圖片中提取圖塊。最后，將每個圖塊保存為以行號加列號命名的圖片文件。

請確保代碼和圖片文件 `allpokers.jpg` 在同一目錄下，并且安裝了 Pillow 庫（可以使用 `pip install Pillow` 安裝）。執行代碼后，將會生成 54 張按照行號和列號命名的圖片文件。

克的玩法非常多，常見的就有斗地主、跑得快、五十K、拖拉機、等等。在國內的不同地方，同類游戲的玩法也有不同講究。粗略估計，國內的撲克玩法，超過上百種。

要短期內開發出這么多款撲克游戲，需要先對大多數撲克游戲進行系統的分析，歸納總結，然后打造一條流水線，每一款游戲都使用相同的框架，使用通用的零組件，等等。本文主要內容就是講述這個設計過程。

1.算法庫

撲克游戲的歷史很悠久，能夠廣為流行的一個原因就是上手比較容易。就算在今天，如果說一個人沒讀過書就學不會打撲克，這沒人會相信。所以我估計撲克游戲的算法，都是比較簡單的。歸納一下，一般包括：

- 牌的大小（包括數字、花色等）；牌的數目和分數；判斷幾張牌相同或連續；

- 還需要一些對一組牌進行操作的算法，比如取出、合并等等。

基于以上的分析，我們估計可以完成一套通用的撲克的算法庫，能滿足所有撲克游戲。最后實踐證明，撲克算法庫比預期稍微復雜一點，但仍在可接受范圍內。

此外，我們很容易發現，很多流行的手游的玩法、功能層出不窮，開發團隊頻繁升級迭代。相反，撲克游戲的玩法相對固定，演化相對較慢。所以，在系統設計上，我們假定撲克游戲的數量有限，玩法有限，發展慢。這樣的好處是流水線設計好之后，以后改動很小，維護工作量也比較小。

2.交互UI庫

撲克游戲可以歸納出3個核心要素：牌、規則、人（玩家）。對撲克游戲的一種高度抽象的描述是：**按照一定的流程和規則，每個人通過選擇選項、選擇牌、選擇數值，來爭取獲勝的一種游戲。**

歸納了一下，玩家的行為包括以下3種：

- 對游戲流程中的選項，做出選擇

比如斗地主中的叫地主、不搶，都是玩家自己要做的一種選擇。出牌的時候選擇不出，也是一種選擇。后續會將“選項”稱之為“命令”。

- 按照游戲規則，對牌進行選擇。

- 比如選擇要出的牌，分組擺牌等。

- 對數值(分數)進行選擇。

以上三種玩家的行為，決定了游戲客戶端需要提供哪些業務級UI庫，對應下面幾種：

- 一組按鈕

由玩家選擇其中一個按鈕；在業務層，稱為**命令選擇器**。

- 選牌或牌分組的UI

> 允許玩家在一組牌中選出符合要求的牌。牌分組UI則允許玩家將牌放入不同分組或按不同順序排布。這2種在業務層都稱為**牌選擇器**。

- 選擇數值的UI

> 可以用滑動條，也有用按鈕的。在業務層稱為**值選擇器**。

以上我們抽象出了撲克游戲的3個核心要素，以及玩家使用的3類UI。現在我們思考一下撲克游戲還需要哪些UI。

除了牌、規則、人，實際上我們還需要房間（桌子）、椅子（座位）。

一款撲克游戲有很多界面、子界面；我們大體將其分為：房間內，房間外。房間內就是一個桌面，UI都顯示到桌面上。房間外包括一些撲克游戲的常用界面和功能：注冊、登錄、用戶信息；房間列表；查詢（分數記錄、排名等）；其他比如：公告、幫助、設置。這些都可以做成通用的幾套，不同游戲選擇其中的一套即可。房間內除了3類選擇器，還需要下面一些界面UI：座位、牌（比如公共牌、出牌）、定時器、圖片、文本（用于顯示數值或文字）。這里除了一些業務級別的UI對象，也包含一些基礎的UI對象。

3.管理員與通訊庫

現實中，幾個朋友坐一桌打撲克的時候，每個人都按照流程和規則來，大家共同監督。而對于線上的撲克游戲，其實有一個規則執行者,不妨稱之為**管理員**（我們前面將選項稱之為“命令”，可以理解為：管理員下達出牌的命令，由玩家選擇出牌還是不出。所以，“選項”是站在玩家角度，“命令”是站在管理員角度）。那么前文的說法，可以進一步升級為：**撲克游戲就是由管理員控制一套流程規則，特定的時候交由玩家來選擇選項、選擇牌、選擇值，這樣一種競賽游戲。**這里我們引入了管理員的概念。

下面說通訊庫：

幾個朋友坐一桌打撲克的時候，比如發牌，每個人收到的牌，其他人不能看到；再比如一個人出牌，是要給其他人看到。現實中打牌，我們是靠視覺來看，相當于靠光線傳播數據（圖像），而對于網絡游戲，則需要的是一個通訊庫通過網絡傳輸數據。我們不能僅僅提供一個簡單的基于socket、websocket、http封裝（比如常見的封裝接口有

read_cmd,read_version,read_int,read_string....），這太底層了，我們需要的是一個業務級別的通訊庫。

比如你跟你老婆說：晚上加班要11點回去，你老婆說“好的”。通訊庫應該是這樣的：

創建一問一答的異步請求，發給老婆；

請求分類是告假（晚上晚回）；參數是11點；

答復選項是3種：好的；不行；超時；（如果你老婆不是話癆的話）

再比如人事部給每個員工發短信，內容是本月工資明細。通訊庫就是群發短信，格式相同，但內容不同。

通過分析一些撲克游戲，我們從這樣幾個層面進行設計抽象：通訊方向、是否應答、發送目標、單發還是群發。其中：不需要答復的，我們叫通知；需要答復的，我們叫“命令”或“請求”。從客戶端發向管理員，稱之為“客戶端請求”；從管理員向客戶端發送，稱之為“服務端命令”；最終，我們把通訊歸納成5種模板：**客戶端請求；服務端命令；服務端廣播；服務端私有通知；服務端公開通知；**

有了通訊庫，我們需要往里面塞數據，數據包括：通訊類型名稱、命令選項、數值、牌。實際上數據內容也正是對應了**選擇選項、選擇牌、選擇數值**。

舉個例子：比如輪到一個玩家出牌了，我們使用**服務端命令**定義了一個出牌命令，這是一問一答的通訊，管理員發送時，不攜帶數據。客戶端答復時，選項包括：出、不出；如果出牌，則需要攜帶出的牌。

再舉一個例子：游戲結束時需要通知輸贏，這時可以使用**服務端公開通知**，就是服務端給每一個玩家發送通知，通知內容是這一局輸了還是贏了，贏了多少金幣。那么，這個通訊中，攜帶的就是贏的金幣（如果為負值，則表明是輸）

總結一下：套用這5種模板，通過定義名稱、攜帶的數據，來定義游戲中特定的通訊過程。比如拖拉機游戲中有以下幾種通訊的定義：發牌公開通知、亮主請求、亮主結果廣播、扣底牌命令、扣底牌通知、出牌命令、出牌結果廣播、結算通知。此外所有游戲都會用到一些公共的通訊定義：坐下請求、站起請求、一局開始廣播、一局結束廣播、聊天等。

在通訊中，還涉及到數據對不同客戶端的可見性的問題，這里就不再深入介紹了。

4.流程

通過分析數十款不同特點的撲克游戲，整理了下面一種思路：

所有撲克游戲，在概念上，可以這樣劃分：

- **一局**

比如斗地主，從發牌，到出牌，到結束，這是一局。一局結束后，開始下一局。

- **階段**

一局游戲可以劃分成幾個階段，比如發牌階段，出牌階段，結算階段；

- **一輪**

大多數撲克游戲都是每個人輪著來的。還有一些游戲（或者游戲中的某個環節）是允許搶先的（比如拖拉機的亮主）。在技術上，一輪就是一個異步循環，提供很多參數和控制。

以上是為了方便而從概念上劃分的，并不絕對，使用這樣一種套路，開發不同撲克游戲時，可以更加統一了。

5.組裝

到目前為止，我們已經完成了下面的成品模塊、框架、零組件。

- 一套撲克算法庫

- 房間內的UI庫

命令選擇器；牌選擇器；值選擇器；頭像、牌、圖片、文本；

- 房間外的幾套成品模塊

注冊、登錄、用戶信息；房間列表；查詢（分數記錄、排名等）；其他比如：公告、幫助、設置。

- 5種通訊類模板

客戶端請求；服務端命令；服務端廣播；服務端私有通知；服務端公開通知；

- 流程庫

提供一局、階段、一輪等控制；

對于不同撲克游戲，我們首先要把游戲玩法弄清楚，然后用這些成品模塊、框架、零組件，通過配置，通過編寫一些代碼來進行粘合，從而實現一個完整的游戲。

在實際的開發過程中我們驗證了：對于簡單的游戲，三五天就可以完成，對于極其復雜的游戲，一般在1\~2周（比如拖拉機這類游戲）。這里說的是一個人，同時也包含自測時間。

為了提升粘合的效率，開發一個圖形化編程工具，這里附上一些截圖供參考：

- 主界面

- 函數庫

除了算法庫、UI庫以外，還包含了編程語言級別的函數、流程控制函數等。

- 牌型算法的例子

> 有了這個工具，寫牌型算法就快多了。

- 流程控制

這個圖中的例子，包括了對一副牌進行洗牌，每次取出17張牌，在一個循環中，給每一個玩家發牌。下面是用英文顯示函數的樣子：

實際使用過程中，還是習慣英文編程。切換到中文相當于看看文檔。

- 調試

調試的時候，可以隨時看一組牌是什么牌，這樣很方便，對開發效率的提升很明顯。

以上介紹的圖形化開發工具，已經具備的工程管理、圖形化編程（編輯）、調試、發布、以及界面設置等輔助功能為一體的集成化開發環境。是圖形化編程的一次有益的嘗試。

6.測試

技術人員自己可以搞定的測試是：單元測試；功能測試；性能測試（壓力測試）;我們還請了專業的測試團隊進行了游戲內測。

簡單的公測：找老家親戚朋友拉微信群，有些朋友人脈廣，可以拉很多人。然后每天集中半小時搞一次測試，玩5局發10元紅包,連續測試一周就差不多了。這種測試還挺有效，而且投入不大。

7.進展

目前，項目已經基本達成了技術目標，所有撲克游戲使用了同一套算法庫（C++代碼使用emscripten轉為javascript）、同一套UI庫（html5/pixi.js）、兩套標準的大廳，同一個服務器程序（C++），同一套通訊庫（javascript）。另外還有：管理和監控后臺；服務器更新；客戶端更新；html5錯誤上報；C++錯誤上報等等。

除C++代碼未開源，其他代碼都開源了，文檔齊全，放在gitee上了，歡迎大家下載使用，歡迎提意見和交流。

（在html5瀏覽器兼容性方面有一些問題，比如UC瀏覽器、搜狗瀏覽器，特別需要熟悉這塊的同學能給與一些幫助.）

[gitee.com/szcuipeng/public](https://gitee.com/szcuipeng/public)

8.作者的話

作者風馬9年前進入到游戲行業，也有幸在一家上市游戲公司擔任技術副總監，并承擔過游戲引擎主程的工作。如果有機會，我很想去加入古劍或河洛的團隊中去學習。我大學出來后大部分時間里，從事的是GIS（地圖編輯、空間分析、圖形）開發，也有一部分跟AutoCAD有關，都是windows客戶端。一個團隊40多號人，開發企業用大型客戶端，當時在國內也頗為壯觀。現在看到米國禁止咱們大學用MATLAB，我也很想投入到這些領域中。

自己一直喜歡干技術，雖然早已是大齡，但也一直堅持干技術，是因為從大學時候起，就想在技術上干出一點名堂來。那時自己仰望一些技術大牛，就像小蝦米仰望14本天書中的大俠一樣，希望有一天像他們一樣，成為技術界的俠之大者，成為對社會對行業有用的人。