簡介本資源是基于Python實現(xiàn)的國際數(shù)棋3×3井字棋綜合項目面向Python初學者與游戲開發(fā)入門者覆蓋圖形界面、網(wǎng)絡(luò)對戰(zhàn)及AI博弈三大核心能力訓(xùn)練。項目采用Pygame構(gòu)建可視化交互界面結(jié)合多線程實現(xiàn)雙人實時聯(lián)網(wǎng)對戰(zhàn)并通過α-β剪枝算法優(yōu)化AI決策效率完整呈現(xiàn)從UI渲染、邏輯分離前后端解耦、網(wǎng)絡(luò)通信到智能策略的全棧開發(fā)流程。壓縮包共44個文件含12個核心Python源碼如solo.py、AI.py、Web.py、houduan.py等、20個編譯后pyc文件、7個音效wav文件、1個背景jpg圖、1份PPT算法講解文檔及配置說明txt等總大小6.71MB結(jié)構(gòu)清晰模塊職責明確。目前已有844人學習下載提供可直接運行的完整工程、帶注釋的AI估值函數(shù)estimate.py、前后端分離設(shè)計范例及配套音效資源是掌握Pygame游戲開發(fā)、基礎(chǔ)網(wǎng)絡(luò)編程與博弈算法實踐的理想學習樣本。 我最初做國際數(shù)棋的Python版本純粹是因為在技術(shù)社區(qū)看到一個討論帖——有位老師想找一款帶圖形界面的數(shù)棋軟件給學生上課用結(jié)果翻遍全網(wǎng)都沒找到合適的。我當時正好在折騰Python游戲開發(fā)順手就把這個項目接了下來。后來一步步從單機版做到局域網(wǎng)對戰(zhàn)版又加了AI對戰(zhàn)打包成zip分發(fā)給了不少人。這個項目雖然不算大但麻雀雖小五臟俱全圖形界面、網(wǎng)絡(luò)通信、博弈AI三塊硬骨頭都啃了一遍過程中踩的坑和總結(jié)的經(jīng)驗我覺得值得單獨寫一篇文章分享出來。如果你正打算用Python做一個帶界面的小游戲或者對棋類AI的實現(xiàn)思路感興趣又或者想了解一個完整的Python項目從單機到聯(lián)機再到AI的演進路徑這篇文章應(yīng)該能給你一些實打?qū)嵉膮⒖肌?. 國際數(shù)棋的規(guī)則與項目定位為什么這個游戲適合拿來練手國際數(shù)棋可能很多人沒聽過它和象棋圍棋不一樣是一種結(jié)合了數(shù)學運算和策略規(guī)劃的棋類游戲。棋盤一共15個格位分四個區(qū)兩端各有7個棋子分別標有0到6的數(shù)字。開局時雙方棋子按固定順序排列在各自陣營走棋靠骰子決定步數(shù)棋子可以平移也可以跳躍跳躍時路徑上經(jīng)過的棋子數(shù)字可以做加減乘除運算結(jié)果等于跳躍距離就能落子。這個規(guī)則聽起來簡單但實際玩起來非?？简灁?shù)值運算能力和路徑規(guī)劃能力。為什么我推薦拿它來做Python項目練手因為它足夠小眾但規(guī)則完整實現(xiàn)難度適中。對比五子棋——規(guī)則太簡單AI邏輯容易圖形界面也沒啥挑戰(zhàn)對比象棋圍棋——規(guī)則復(fù)雜AI實現(xiàn)難度極高新手根本啃不動。國際數(shù)棋的復(fù)雜度恰好卡在中間圖形界面需要一個像樣的棋盤和一個可交互的棋子移動機制網(wǎng)絡(luò)版需要處理回合同步和狀態(tài)一致性AI版需要設(shè)計評估函數(shù)和搜索算法每個模塊都有真實的技術(shù)含量但又不會難到讓人放棄。再說技術(shù)選型。圖形界面我用的是Python自帶的tkinter沒有上PyQt或者Pygame原因有三點第一項目目標用戶是普通玩家和老師他們不一定有精力裝PyQt這類大型依賴庫內(nèi)置的tkinter打開即用第二數(shù)棋的交互不算復(fù)雜不涉及流暢的場景切換和粒子特效tkinter的Canvas足夠勝任第三打包分發(fā)時tkinter的兼容性最好不會因為底層庫版本不一致出問題。網(wǎng)絡(luò)版用的是Python的socket套接字加JSON協(xié)議沒有引入twisted或asyncio這類異步框架理由和上面一樣——局域網(wǎng)對戰(zhàn)場景下客戶端就兩三個同步阻塞式的socket反而更直觀邏輯清晰容易調(diào)試。AI版采用了經(jīng)典的minimax加alpha-beta剪枝評估函數(shù)自己做了一套位置價值表這塊后面我會詳細展開。2. 圖形界面版的設(shè)計拆解從棋盤繪制到棋子交互界面部分看起來只是把棋盤畫出來、讓棋子能點能拖但如果一開始不把邏輯和顯示分離后面加網(wǎng)絡(luò)版和AI版時絕對會想哭。我第一版確實把規(guī)則判斷直接寫在Canvas的回調(diào)函數(shù)里結(jié)果一個函數(shù)動不動就上百行改一個bug牽連三個功能。后來痛定思痛整個重構(gòu)成了三層架構(gòu)規(guī)則層、狀態(tài)層、表現(xiàn)層這個思路在后續(xù)擴展時幫了大忙。2.1 棋盤的三層架構(gòu)規(guī)則、狀態(tài)與表現(xiàn)分離規(guī)則層負責所有游戲邏輯的判定包括擲骰子的步數(shù)生成、當前玩家可以走哪些格子、棋子移動是否合法、跳躍路徑上的數(shù)字運算是否成立。這一層不關(guān)心棋子在屏幕上長什么樣也不關(guān)心走棋的消息是從鼠標點擊來的還是從網(wǎng)絡(luò)來的它只接收標準化的動作指令并返回結(jié)果。狀態(tài)層保存的是當前對局的完整快照黑白雙方的棋子排列、當前輪到誰、當前骰子點數(shù)、游戲是否結(jié)束。網(wǎng)絡(luò)同步時傳輸?shù)木褪沁@份狀態(tài)數(shù)據(jù)AI計算時讀取的也是這份狀態(tài)數(shù)據(jù)。表現(xiàn)層就是用戶直接看到的界面棋盤繪制、棋子渲染、動畫效果、鼠標事件。它的職責是解析用戶操作并轉(zhuǎn)換成標準的動作指令交給規(guī)則層處理然后根據(jù)狀態(tài)層的變化刷新界面。這三層之間用簡單的觀察者模式解耦狀態(tài)層發(fā)生變化時自動通知表現(xiàn)層更新。剛開始會覺得多寫了很多代碼但當我把網(wǎng)絡(luò)版接入時只需要在狀態(tài)層變化后增加一步——把新狀態(tài)廣播給對手整個網(wǎng)絡(luò)同步就完成了。AI接入時只需要讓AI模塊讀取當前狀態(tài)、計算出動作指令并推入輸入隊列界面根本不需要感知AI的存在。2.2 tkinter畫布的坐標計算與棋子動畫棋盤的15個格位我畫在一個Canvas組件上Canvas寬度設(shè)置為300像素每個格位是一個半徑22像素的圓形。格位的坐標我是寫死的列表常量每個元素是一個二元組表示圓心的x和y坐標。這樣反而最簡單可靠因為數(shù)棋的棋盤布局是固定的不像某些游戲需要動態(tài)生成寫死坐標表比任何動態(tài)計算都高效。棋子是Canvas上創(chuàng)建的oval圖形對象每個棋子對象用tag屬性標識歸屬和數(shù)字比如black_3表示黑方的3號棋子。移動棋子時我用了最簡單的線性插值動畫——把移動過程拆成20幀每幀更新一次圓心坐標間隔10毫秒。這里有一個細節(jié)值得注意tkinter的update和update_idletasks方法要慎用直接在主循環(huán)里調(diào)用update會卡界面正確做法是使用after方法調(diào)度動畫幀把控制權(quán)交還給事件循環(huán)。def animate_move(self, item, start_pos, end_pos, steps20): dx (end_pos[0] - start_pos[0]) / steps dy (end_pos[1] - start_pos[1]) / steps current list(start_pos) def frame(i): if i steps: current[0] dx current[1] dy self.canvas.coords(item, current[0] - 20, current[1] - 20, current[0] 20, current[1] 20) self.canvas.after(10, frame, i 1) frame(1)骰子的交互設(shè)計做了個小創(chuàng)新玩家點擊擲骰按鈕后骰子數(shù)字會快速變化0.5秒再定格這個效果其實是用after每50毫秒隨機刷新一次骰子顯示文字實現(xiàn)的代碼只有五行但視覺反饋特別好玩家能明顯感受到“擲”的過程而不是干巴巴地跳出一個數(shù)字。2.3 合法性判斷的前置提示減少誤操作的交互優(yōu)化數(shù)棋有個容易讓人困惑的點骰子擲出后當前玩家往往有多個子可以走但具體能走到哪個格位需要經(jīng)過計算。如果玩家點了不能走的棋子新手往往會以為游戲卡了。我在界面加了一個“可走棋提示”功能骰子點數(shù)確定后規(guī)則層會計算出所有合法的走法并把對應(yīng)棋子的輪廓描成高亮顏色。這個功能的實現(xiàn)難點在于規(guī)則層要導(dǎo)出一個“指示”接口——不實際移動棋子只返回所有合法目標位置列表。有了這個接口AI模塊后續(xù)也能復(fù)用它需要知道當前有哪些走法可選。def get_legal_moves(self, dice_value, player): moves [] for piece in self.board.pieces[player]: for target in self.get_move_targets(piece.position, dice_value): if self.is_move_valid(player, piece.position, target): moves.append((piece.position, target)) return moves交互細節(jié)上還有一個經(jīng)驗棋子移動后如果目標格位上已經(jīng)有對方的棋子規(guī)則允許吃掉對方棋子并將它移回對方陣營的起始位置。這個“吃子遣返”的動畫我特意做成了兩步——先移動進攻棋子再將被吃棋子飛回起始點中間間隔250毫秒比同時移動看起來清楚得多。3. 從單機到聯(lián)機網(wǎng)絡(luò)版的同步機制與狀態(tài)一致性方案本地版跑通之后很多朋友問我能不能兩個人遠程對戰(zhàn)于是網(wǎng)絡(luò)版就提上了日程。做網(wǎng)絡(luò)版最難的不是傳輸數(shù)據(jù)而是保證兩臺電腦上的游戲狀態(tài)始終一致。棋類游戲不像動作游戲需要每幀同步它屬于狀態(tài)同步里的回合制場景只需要在每次狀態(tài)變化后把完整快照發(fā)給對手即可。3.1 主機-客戶端架構(gòu)與socket通信協(xié)議設(shè)計我采用的是經(jīng)典的主機-客戶端模式。主機負責權(quán)威判定客戶端發(fā)來動作指令后主機運行規(guī)則層邏輯確認這個動作合法然后更新全局狀態(tài)再把新狀態(tài)廣播給所有客戶端。這個設(shè)計的好處是避免了兩個人同時操作導(dǎo)致的沖突——主機就是唯一的真相來源。通信協(xié)議我定義了五種消息類型JOIN請求加入、MOVE走棋操作、DICE擲骰子結(jié)果、STATE同步狀態(tài)快照、GAME_OVER游戲結(jié)束。所有消息都用JSON序列化格式統(tǒng)一如下{ type: MOVE, player: black, piece_id: 3, from: 2, to: 7, timestamp: 1691234567 }JSON雖然沒有二進制協(xié)議高效但勝在可讀性強調(diào)試時可以直接打印消息內(nèi)容定位問題。局域網(wǎng)內(nèi)一次序列化和反序列化不過一兩毫秒對回合制棋類游戲來說完全夠用。3.2 關(guān)鍵問題如何避免狀態(tài)不同步導(dǎo)致的“你走的棋我看不到”狀態(tài)同步最容易出幺蛾子的是時序問題。比如玩家A在主機上走了一步棋主機把新狀態(tài)廣播給玩家B但網(wǎng)絡(luò)有延遲廣播還沒到玩家B本地又顯示了一次骰子動畫。如果處理不當兩臺電腦的界面就會逐漸分叉。我的策略是引入“版本號”機制。每份狀態(tài)快照都帶有一個遞增的版本號客戶端收到的狀態(tài)版本號必須比本地當前版本號大才接受否則直接丟棄。走棋操作發(fā)出后客戶端本地不立即更新狀態(tài)而是等主機廣播回新狀態(tài)再刷新界面。這種做法的代價是操作反饋有一點延遲但對局域網(wǎng)游戲來說幾十毫秒的延遲玩家基本感知不到。斷線重連是這個模塊里最頭疼的部分。我最初沒做這個功能結(jié)果一臺電腦網(wǎng)絡(luò)波動斷線后只能重開一局。后來設(shè)計了一個簡單的恢復(fù)流程客戶端重連后發(fā)送JOIN消息攜帶自己斷線前的狀態(tài)版本號主機收到后從歷史緩沖區(qū)里找到對應(yīng)版本的快照補發(fā)所有后續(xù)狀態(tài)。歷史緩沖區(qū)只存最近50個版本超過的舊版本就丟棄避免內(nèi)存無限增長。關(guān)于主機和客戶端的判定我還加了一個防作弊思路所有走棋動作的合法性判定都放在主機端客戶端只是發(fā)指令。這樣想修改代碼來作弊的人只能改自己本地的顯示真正決定游戲進程的還是主機。4. AI版的核心評估函數(shù)設(shè)計與搜索算法調(diào)優(yōu)AI模塊是最后才做的也是技術(shù)含量最高的部分。國際數(shù)棋的AI思路本質(zhì)上和其他棋類AI一樣——搜索所有可能走法用評估函數(shù)衡量局面優(yōu)劣選出評分最高的走法。區(qū)別在于評估函數(shù)怎么定義搜索深度怎么控制。4.1 為什么不直接用深度學習而選擇minimax加alpha-beta剪枝我明確沒有考慮深度學習方案。原因很實際第一國際數(shù)棋沒有現(xiàn)成的棋譜數(shù)據(jù)集想訓(xùn)練一個神經(jīng)網(wǎng)絡(luò)得先自己造數(shù)據(jù)成本太高第二棋類AI用蒙特卡洛樹搜索或minimax在中小規(guī)模博弈中效果已經(jīng)很好不需要上重型武器第三目標用戶是在普通電腦上運行深度學習推理有GPU依賴不符合場景。最終采用minimax加alpha-beta剪枝搭配自定義評估函數(shù)。minimax的思路是假設(shè)雙方都足夠聰明我方尋找評分最高的走法對方會選擇讓我方評分最低的應(yīng)對由此反向推導(dǎo)當前最優(yōu)走法。alpha-beta剪枝在這個基礎(chǔ)上砍掉大量不可能被選中的分支將搜索效率提升數(shù)倍。4.2 評估函數(shù)的權(quán)重設(shè)計從棋子價值到位置潛力評估函數(shù)是決定AI強弱的核心。我設(shè)計了四個維度的加權(quán)評分每個維度權(quán)重通過實際對局測試調(diào)整評估維度權(quán)重說明棋子數(shù)量優(yōu)勢10存活棋子越多控盤能力越強位置前進度8棋子越接近對方陣營威脅越大可移動性5當前位置可走的合法走法數(shù)量運算潛力3附近格位上存在可做運算的棋子組合位置前進度這張表我手工調(diào)了很久。數(shù)棋的棋盤是左右對稱的黑棋從左側(cè)往右進攻白棋從右側(cè)往左進攻。每個格位對進攻方和防守方有不同的戰(zhàn)略價值。舉例來說靠近中場的格位前進度評分高因為相當于過了河但也不是越靠前越好太靠前的格位容易被對方吃子遣返所以我在評分函數(shù)里對這一層做了折減處理。接下來還要處理一個特殊情況——必勝局和必敗局的判斷。如果一方棋子數(shù)為0直接返回極大和極小值不進入常規(guī)評分函數(shù)。這一步必須在搜索入口處理否則評估函數(shù)在終局狀態(tài)下會給出誤導(dǎo)性評分。def evaluate(self, board, player): if board.piece_count(player) 0: return -10000 if board.piece_count(opponent(player)) 0: return 10000 score 0 score 10 * (board.piece_count(player) - board.piece_count(opponent(player))) score 8 * (self.position_score(board, player) - self.position_score(board, opponent(player))) score 5 * (self.mobility_score(board, player) - self.mobility_score(board, opponent(player))) score 3 * (self.operation_score(board, player) - self.operation_score(board, opponent(player))) return score4.3 搜索深度、時間控制與難度分級搜索深度對棋力的影響非常直接。我實測過不同深度下的表現(xiàn)深度1就是貪心算法只會走當前局面對自己最有利的一步很容易被對手計算深度3能考慮到兩步之后的變化已經(jīng)能打敗不少普通玩家深度5對戰(zhàn)局的理解明顯上了一個臺階但搜索時間也變得不可控。國際數(shù)棋的分支因子比象棋小得多每步合法走法平均在5到10個之間所以深度5在大多數(shù)情況下可以秒出結(jié)果。但某些局面分支特別多時深度5的搜索時間可能飆到3秒以上這在回合制游戲里雖然能接受但體驗不好。我加了一個時間控件預(yù)設(shè)每步最多思考2秒2秒內(nèi)如果深度5還沒搜完就截斷返回當前最優(yōu)解。實際測試下來這個策略在99%的情況下都能跑完完整深度5搜索只有極少數(shù)復(fù)雜局面會觸發(fā)截斷。難度分級也是通過搜索深度實現(xiàn)的簡單難度搜索深度1相當于閉眼下棋新手拿來練手剛好中等難度深度3適合有基礎(chǔ)的玩家困難難度深度5加上完整評估函數(shù)電腦明顯比大多數(shù)玩家強。4.4 實戰(zhàn)效果AI對弈中的策略特征分析深度5的AI在實際對弈中展現(xiàn)出了幾個有趣的特征。第一它非常會用跳躍運算來推進棋子——有時候明明可以平移到更靠前的位置但它會選擇走出一個復(fù)雜的跳躍路徑利用沿途的數(shù)字做乘除運算因為評估函數(shù)里運算潛力維度的加權(quán)讓它覺得這種走法整體收益更高。第二它明顯懂得保護后方陣營的棋子不會輕易把所有棋子都推上前線因為可移動性維度的評分讓孤立無援的棋子分數(shù)偏低。第三面對吃子威脅時它會優(yōu)先移動被威脅的棋子而不是繼續(xù)進攻這個策略在深度3以下很難穩(wěn)定出現(xiàn)。當然深度5的AI也有明顯的盲區(qū)。如果連續(xù)多個回合擲出小點數(shù)骰子1或2它的優(yōu)勢會慢慢被消耗另外它的評估函數(shù)對終局前的“致命一擊”計算不夠精確有時候會因為過于追求局部優(yōu)勢而錯失直接獲勝的機會。這些坑在后續(xù)版本里可以通過優(yōu)化評估函數(shù)部分解決但考慮到項目定位是教學和娛樂目前的強度已經(jīng)夠用了。5. 實測中的高頻坑位編碼、卡頓、粘包與線程講完三個版本的核心實現(xiàn)我必須把開發(fā)過程中遇到的坑集中列出來——這些坑基本是Python做帶界面項目時的通病很多沒有提前接觸過的人大概率會再踩一遍。5.1 中文顯示亂碼問題tkinter在Windows上默認編碼是gbk如果代碼文件保存為UTF-8字符串里包含中文時某些系統(tǒng)環(huán)境下會顯示成方塊或亂碼。我的解決方案是所有源碼文件開頭明確聲明編碼格式并在界面初始化時設(shè)置字體為微軟雅黑或宋體這兩個字體在Windows下對中文支持最好。另外打包成exe時也要注意在spec文件里處理好編碼資源。# -*- coding: utf-8 -*- root tk.Tk() root.option_add(*Font, (Microsoft YaHei, 12))5.2 動畫卡頓問題tkinter的動畫性能確實一般但如果操作得當20幀的棋子移動動畫完全流暢。卡頓的主要原因是有人直接在動畫循環(huán)里調(diào)用time.sleep這個操作會把整個tkinter事件循環(huán)堵住表現(xiàn)就是動畫一卡一卡拖動窗口都沒反應(yīng)。正確的做法是堅持用after方法調(diào)度動畫幀這是tkinter推薦的異步定時方式。5.3 socket粘包與分包局域網(wǎng)通信中用TCP時最常見的就是粘包和分包問題。粘包指多個消息黏在一起到達分包指一個消息被拆成多段到達。簡單地在接收端做recv(1024)解析JSON很快就會出bug。我的解決方案是在每個JSON消息前加4字節(jié)的消息長度前綴接收端先讀取長度字段再按長度精確接收完整消息。def send_msg(self, sock, msg): data json.dumps(msg).encode(utf-8) sock.sendall(len(data).to_bytes(4, big) data) def recv_msg(self, sock): length int.from_bytes(sock.recv(4), big) chunks [] received 0 while received length: chunk sock.recv(length - received) chunks.append(chunk) received len(chunk) return json.loads(b.join(chunks).decode(utf-8))5.4 AI搜索導(dǎo)致界面假死深度5的AI搜索雖然不是每秒都耗時但在某些復(fù)雜局面下需要計算兩三秒這段時間如果放在主線程里執(zhí)行整個界面會凍住玩家會以為程序崩潰了。解決辦法是引入threading模塊把AI計算放到后臺線程執(zhí)行啟動線程時將界面上的按鈕禁用防止玩家重復(fù)點擊計算結(jié)束后線程回調(diào)主線程更新界面。但要注意tkinter的組件不能在子線程里直接操作必須通過隊列或者after調(diào)度回到主線程執(zhí)行。我用了queue.Queue存放AI計算結(jié)果然后主線程每隔100毫秒輪詢隊列一次有結(jié)果就刷新界面。這套方案實現(xiàn)簡單也不會引入復(fù)雜的線程通信問題。5.5 打包分發(fā)時的環(huán)境差異打包成zip分發(fā)后有用戶反饋打開界面顯示不出棋盤排查后發(fā)現(xiàn)是屏幕分辨率縮放比例的問題。Windows系統(tǒng)如果設(shè)置了125%或150%的縮放tkinter默認不會自動適配導(dǎo)致部分界面元素超出屏幕。解決方案是顯式設(shè)置tkinter的縮放屬性或者用tkinter的tk scaling方法根據(jù)系統(tǒng)DPI動態(tài)調(diào)整。這個坑沒有統(tǒng)一的解決方案因為不同電腦的DPI設(shè)置不一樣比較穩(wěn)妥的做法是在程序啟動時讀取系統(tǒng)縮放比例并調(diào)整默認字體和組件尺寸。6. 代碼結(jié)構(gòu)復(fù)盤如何讓一個Python項目易于擴展維護項目做完整理了一份最終版的代碼結(jié)構(gòu)每次回過頭看都覺得當初的重構(gòu)決策是關(guān)鍵轉(zhuǎn)折點。如果沒有一開始就把邏輯和顯示分離后面加網(wǎng)絡(luò)模塊時大概率會推翻重來。number-chess/ ├── main.py # 入口文件負責選擇單機/聯(lián)機/AI模式 ├── game/ │ ├── __init__.py │ ├── board.py # 棋盤狀態(tài)與棋子操作 │ ├── rules.py # 走棋規(guī)則合法性判定 │ └── evaluator.py # 局面評估函數(shù) ├── gui/ │ ├── __init__.py │ ├── window.py # 主窗口框架 │ ├── canvas_widget.py # 棋盤畫布組件 │ └── dialogs.py # 模式選擇、設(shè)置等對話框 ├── network/ │ ├── __init__.py │ ├── server.py # 主機端網(wǎng)絡(luò)線程 │ ├── client.py # 客戶端網(wǎng)絡(luò)處理 │ └── protocol.py # 消息封包與解析 ├── ai/ │ ├── __init__.py │ ├── minimax.py # 搜索算法核心 │ └── search.py # 走法生成與剪枝優(yōu)化 └── assets/ ├── config.json # 游戲配置如搜索深度、棋盤主題色 └── positions.json # 棋盤格位坐標表接口設(shè)計上有一個原則貫穿始終每個模塊盡量只通過公開方法暴露必要的功能內(nèi)部細節(jié)不對外暴露。例如棋盤類只提供get_piece_at、move_piece、is_game_over等方法底層棋子的存儲結(jié)構(gòu)是列表還是字典調(diào)用方完全不用關(guān)心。配置項集中放在config.json的好處是玩家想改AI難度、棋盤配色、動畫速度直接編輯配置文件就行不需要改代碼重新打包。這個細節(jié)很多業(yè)余項目都會忽略但實際使用中反饋率極高——不少用戶都在問怎么調(diào)速度、怎么換顏色。7. 實測數(shù)據(jù)與調(diào)優(yōu)記錄搜索深度、勝率與響應(yīng)時間最后展示一組我實測的調(diào)優(yōu)數(shù)據(jù)供做棋類AI的朋友參考。測試環(huán)境是i5-8250U處理器8GB內(nèi)存Windows 10系統(tǒng)。搜索深度平均響應(yīng)時間與深度1對戰(zhàn)勝率觀感評價110ms基線顯得很蠢容易送子250ms約60%有基本防守意識3450ms約80%能打出基礎(chǔ)配合41600ms約90%大部分局面表現(xiàn)穩(wěn)健52800ms約97%有明顯進攻套路從數(shù)據(jù)能看出深度從3提升到4時勝率有較大躍升而深度4到5的提升幅度開始放緩但響應(yīng)時間幾乎翻倍。這個趨勢符合棋類AI的一般規(guī)律隨著深度增加邊際收益遞減時間成本遞增。所以我把默認難度設(shè)為深度4這個檔位在體驗和棋力之間最平衡。評估函數(shù)的權(quán)重也做過一組對比實驗。初始版本四個維度的權(quán)重是10-5-3-1AI棋風偏向猛沖猛打經(jīng)常把棋子全部押上前線。后來調(diào)整為10-8-5-3之后AI開始注重棋子的活性和配合整體棋力上升了約15%。這個調(diào)整給我最大的啟發(fā)是在棋類AI中一味追求棋子數(shù)量優(yōu)勢往往不如位置優(yōu)勢和機動性重要這個經(jīng)驗在其他的策略類游戲AI設(shè)計里也有參考價值。本文還有配套的精品資源點擊獲取