整合營銷服務商

          電腦端+手機端+微信端=數據同步管理

          免費咨詢熱線:

          chatGPT 輔助備課案例-撲克圖片拆分

          chatGPT 輔助備課案例-撲克圖片拆分

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

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

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


          chatGPT生成的圖片分割代碼


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

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

          程派微信號:codingpy

          如何實現撲克牌游戲?怎樣去表示卡牌、手牌、牌堆等概念?發牌等概念又該如何實現?

          本文不會細致去講這些問題,因為這是《Think Python 2e》第18章的具體內容。請點擊“閱讀原文”,或者訪問http://codingpy.com/books/thinkpython2/18-inheritance.html 查看最新更新。

          第18章的題目是繼承,作者以實現撲克牌游戲為例,繼續深入講解了面向對象編程的這個重要特性。

          作者還在這章中介紹了一種新的開發計劃:

          1. 首先編寫讀取全局變量的函數(如有必要)。

          2. 一旦你讓程序跑起來了,開始查找全局變量和使用它們的函數的聯系。

          3. 封裝相關的變量作為一個對象的屬性。

          4. 轉換相關函數為新類的方法。

          貢獻者:

          翻譯:@bingjin

          校對:@bingjin aka EarlGrey

          參考:@carfly

          最后,歡迎大家指正譯文中可能存在的錯誤,或是將此中譯版分享給更多的人。

          克的玩法非常多,常見的就有斗地主、跑得快、五十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本天書中的大俠一樣,希望有一天像他們一樣,成為技術界的俠之大者,成為對社會對行業有用的人。


          主站蜘蛛池模板: 在线成人综合色一区| 亚洲福利视频一区二区| 韩国精品一区二区三区无码视频| 99国产精品欧美一区二区三区| 日韩高清一区二区三区不卡| 天天爽夜夜爽人人爽一区二区| 亚洲AV日韩精品一区二区三区| 亚洲夜夜欢A∨一区二区三区| 国产精品一区二区久久国产| 国产精品日本一区二区不卡视频| 91秒拍国产福利一区| 亚洲av成人一区二区三区观看在线 | 成人区人妻精品一区二区三区 | 日本一区二区三区在线视频 | 亚欧成人中文字幕一区| 午夜视频在线观看一区二区| 东京热无码一区二区三区av| 亚洲综合无码一区二区三区| 高清在线一区二区| 久久99精品一区二区三区| 在线免费视频一区二区| 文中字幕一区二区三区视频播放| 国产肥熟女视频一区二区三区 | 91在线一区二区三区| 风流老熟女一区二区三区| 亚洲国产日韩在线一区| 精品亚洲一区二区三区在线观看| 日韩免费无码视频一区二区三区| 精品3d动漫视频一区在线观看| 亚洲狠狠久久综合一区77777| 国产一区二区三区精品久久呦| 亚洲国产精品一区二区久久hs| 国产精品一区二区电影| 中文字幕在线看视频一区二区三区| 琪琪see色原网一区二区| 亚洲中文字幕一区精品自拍 | 国产高清在线精品一区小说| 无码丰满熟妇一区二区| 少妇无码一区二区二三区| 成人免费一区二区三区| 丝袜美腿高跟呻吟高潮一区|