戰(zhàn)：從0到1實(shí)現(xiàn)單機(jī)版搶車(chē)位游戲)
簡(jiǎn)介基于C#語(yǔ)言開(kāi)發(fā)的單機(jī)版搶車(chē)位游戲完整源碼面向C#初學(xué)者、面向?qū)ο缶幊虒W(xué)習(xí)者及游戲開(kāi)發(fā)入門(mén)者。以搶車(chē)位玩法為載體完整演示了從玩家、車(chē)輛、車(chē)位等類(lèi)設(shè)計(jì)到用戶(hù)登錄、窗體交互、游戲循環(huán)的開(kāi)發(fā)鏈路適合課程設(shè)計(jì)、個(gè)人練手或畢業(yè)設(shè)計(jì)參考。壓縮包共83個(gè)文件大小6.37MB主要包含15個(gè)cs源碼文件核心邏輯與窗體、37個(gè)png和9個(gè)jpg界面素材、3個(gè)resx與3個(gè)resources資源文件另有exe可執(zhí)行程序、功能說(shuō)明doc文檔和初始化玩家對(duì)象的txt代碼目錄清晰便于運(yùn)行和修改。已有244人學(xué)習(xí)瀏覽。源碼開(kāi)放可直接查看和修改包含Player、Car、ParkingSpace、LoginFrm、ManiFrm等核心類(lèi)模擬隨機(jī)事件、時(shí)間限制與策略決策并涉及線程同步、計(jì)時(shí)器等機(jī)制配套文檔詳細(xì)說(shuō)明了界面布局、按鈕功能和操作流程初始化示例展示了創(chuàng)建玩家對(duì)象、分配初始資源的完整步驟對(duì)理解封裝、繼承、多態(tài)以及多窗體程序組織方式都有直接幫助也能根據(jù)需求擴(kuò)展車(chē)位類(lèi)型或調(diào)整游戲規(guī)則非常適合作為C#實(shí)戰(zhàn)練習(xí)項(xiàng)目。1. 單機(jī)版搶車(chē)位把社交玩法壓進(jìn) C# 的一個(gè)完整閉環(huán)搶車(chē)位這個(gè)玩法經(jīng)歷過(guò)社交平臺(tái)時(shí)代的人都不陌生把車(chē)停到別人車(chē)位賺錢(qián)趁對(duì)方離線時(shí)貼條、拖車(chē)最刺激的就是收益上限卡點(diǎn)前被人清空車(chē)位。放在當(dāng)年這套規(guī)則幾乎全在服務(wù)端本地只負(fù)責(zé)發(fā)請(qǐng)求想把它改成一個(gè)離線可玩、邏輯完整、拿得出手的 C# 項(xiàng)目得把停車(chē)、貼條、拖車(chē)、AI 對(duì)手整個(gè)重寫(xiě)一遍。這份資源做的就是這件事它不是教學(xué) Demo而是一套能直接編譯運(yùn)行、完整玩完一把對(duì)局的課程設(shè)計(jì)級(jí)源碼。適合正在找 C# 題目交差的學(xué)生也適合想從增刪改查跳出來(lái)、認(rèn)真摸一遍游戲狀態(tài)機(jī)寫(xiě)法的初學(xué)者。2. 先拆玩法再拆代碼搶車(chē)位的核心規(guī)則與類(lèi)設(shè)計(jì)2.1 搶車(chē)位到底在搶什么貼條與拖車(chē)的收益閉環(huán)先說(shuō)玩法因?yàn)轭?lèi)設(shè)計(jì)完全由玩法推導(dǎo)出來(lái)。經(jīng)典搶車(chē)位的循環(huán)是這樣地圖上有若干公共車(chē)位玩家的車(chē)停進(jìn)去后按分鐘產(chǎn)出金幣收益有上限停得越久越接近上限。但車(chē)位是有限的別人的車(chē)占著位置你就可以對(duì)他做兩件事貼條沒(méi)收他當(dāng)前累計(jì)收益的一半作為罰金拖車(chē)直接清空累計(jì)收益并把車(chē)送回空閑狀態(tài)進(jìn)入一段冷卻時(shí)間。這兩個(gè)動(dòng)作構(gòu)成了整個(gè)游戲的博弈核心車(chē)位越熱門(mén)、停得越久越容易被針對(duì)。單機(jī)版最大的問(wèn)題在于沒(méi)有真人來(lái)“惡心”你。如果沒(méi)有AI這個(gè)游戲本質(zhì)上就是個(gè)倒計(jì)時(shí)領(lǐng)錢(qián)器五分鐘就沒(méi)勁了。所以這套資源里實(shí)現(xiàn)了AI玩家來(lái)承擔(dān)對(duì)抗角色它會(huì)有三種行為基元尋找空位停車(chē)、給玩家或者其他AI的車(chē)貼條、拖別人的車(chē)。各行為觸發(fā)概率由難度參數(shù)控制后面第4章單獨(dú)講。先把規(guī)則定下來(lái)所有的代碼邏輯都以這張表為準(zhǔn)。動(dòng)作目標(biāo)條件效果罰金公式停車(chē)車(chē)位空閑車(chē)輛不在冷卻車(chē)位被占開(kāi)始累計(jì)收益無(wú)貼條車(chē)位被占且未被貼條沒(méi)收當(dāng)前累計(jì)收益標(biāo)記貼條AccIncome × 50% 20拖車(chē)車(chē)位被占且未被貼條清空累計(jì)收益車(chē)輛進(jìn)冷卻AccIncome × 80%挪車(chē)玩家同一輛車(chē)停到新空位舊車(chē)位釋放累計(jì)收益清零無(wú)這張表是整套源碼的基石后續(xù)所有方法都圍繞它展開(kāi)。注意“挪車(chē)”這條容易被忽略經(jīng)典規(guī)則里把車(chē)從 A 車(chē)位挪到 B 車(chē)位A 車(chē)位釋放但累計(jì)收益清零。這么設(shè)計(jì)是為了防刷錢(qián)——如果挪車(chē)不清零玩家可以把車(chē)停在高級(jí)車(chē)位上賺滿(mǎn)上限再挪到另一個(gè)高級(jí)車(chē)位繼續(xù)賺等于無(wú)限套利。拿到源碼后改功能時(shí)這條規(guī)則建議不要?jiǎng)右粍?dòng)經(jīng)濟(jì)系統(tǒng)就崩。2.2 六張核心類(lèi)圖從 Car 到 GameData 的職責(zé)劃分接下來(lái)看資源里的類(lèi)設(shè)計(jì)。它沒(méi)有用復(fù)雜的框架就是幾個(gè)實(shí)體類(lèi)加一個(gè)游戲管理類(lèi)。實(shí)體類(lèi)全部采用“貧血模型”只存數(shù)據(jù)不寫(xiě)邏輯規(guī)則統(tǒng)一放在 GameManager 里。為什么這么分因?yàn)橥＼?chē)、貼條、拖車(chē)之間交互頻繁貼條要改車(chē)位狀態(tài)、改車(chē)輛收益、改玩家金幣如果規(guī)則散落在實(shí)體類(lèi)里后期調(diào)整 AI 策略時(shí)會(huì)改到懷疑人生。集中管理后規(guī)則的入口只有一個(gè)調(diào)試時(shí)下斷點(diǎn)也只盯 GameManager 一個(gè)類(lèi)。核心實(shí)體類(lèi)的定義如下命名空間統(tǒng)一放在 ParkingGame.Models 下public class Car { public int Id { get; set; } public string Nickname { get; set; } // 車(chē)牌昵稱(chēng)玩家自定義 public int Level { get; set; } // 等級(jí)影響收益加成 public int AccIncome { get; set; } // 當(dāng)前累計(jì)未結(jié)算收益 public int CurrentSpaceId { get; set; } // 當(dāng)前所在車(chē)位Id-1表示閑置 public bool InCooldown { get; set; } // 拖車(chē)后的冷卻標(biāo)志 public DateTime CooldownEnd { get; set; } // 冷卻結(jié)束時(shí)間 } public class ParkingSpace { public int Id { get; set; } public int Row { get; set; } public int Col { get; set; } public int Level { get; set; } // 車(chē)位等級(jí)影響基礎(chǔ)收益倍率 public int ParkedCarId { get; set; } // 停著的車(chē)Id-1表示空閑 public bool HasTicket { get; set; } // 是否被貼條 public DateTime ParkedAt { get; set; } // 停車(chē)時(shí)間用于收益上限計(jì)算 } public class Player { public string Name { get; set; } public int Money { get; set; } public ListCar Cars { get; set; } } public class GameData { public Player HumanPlayer { get; set; } public ListAIPlayer AIPlayers { get; set; } public ListParkingSpace Spaces { get; set; } public int TickSec { get; set; } // 每個(gè)Tick對(duì)應(yīng)的游戲秒數(shù) public bool IsRunning { get; set; } }這段代碼有幾個(gè)細(xì)節(jié)值得說(shuō)。Car 里的 CurrentSpaceId 用 -1 表示閑置而不是用int?原因有兩個(gè)一是 JSON 序列化時(shí) -1 不需要額外處理存檔讀檔更省事二是判斷“這輛車(chē)現(xiàn)在有沒(méi)有停在車(chē)位上”時(shí)寫(xiě)成car.CurrentSpaceId -1一眼就能看懂不會(huì)出現(xiàn) null 判斷漏掉的情況。ParkingSpace 里的 ParkedAt 用的是 DateTime 而不是 tick 計(jì)數(shù)這是為了存檔后不丟收益進(jìn)度——如果你存的是“停了 300 個(gè) tick”讀檔后 Timer 重啟tick 數(shù)就對(duì)不上了DateTime 則能通過(guò)相對(duì)時(shí)間差恢復(fù)。AIPlayer 在資源里單獨(dú)定義它繼承 Player額外帶一組決策權(quán)重字段public class AIPlayer : Player { public int ParkWeight { get; set; } // 停車(chē)行為權(quán)重 public int TicketWeight { get; set; } // 貼條行為權(quán)重 public int TowWeight { get; set; } // 拖車(chē)行為權(quán)重 public int ThinkTick { get; set; } // 每幾Tick決策一次 }這組權(quán)重會(huì)在第 4 章詳細(xì)展開(kāi)?，F(xiàn)在只要知道每個(gè) AI 不是每 Tick 都行動(dòng)而是每隔 ThinkTick 才做一次決策這樣能模擬“思考延遲”也能避免 AI 行動(dòng)過(guò)于頻繁導(dǎo)致玩家毫無(wú)還手之力。想調(diào)出不同性格的 AI就是改這四個(gè)數(shù)字后續(xù)不用動(dòng)任何邏輯代碼。2.3 游戲主循環(huán)Timer 驅(qū)動(dòng)的秒級(jí)收益結(jié)算機(jī)制整個(gè)游戲的調(diào)度核心是一個(gè) System.Windows.Forms.Timer。為什么不用 System.Timers.Timer因?yàn)?WinForms 的 Timer 事件在 UI 線程上觸發(fā)事件里可以直接改控件屬性不需要 Invoke 跨線程System.Timers.Timer 的回調(diào)在線程池線程上改界面必須 this.Invoke寫(xiě)起來(lái)麻煩還容易死鎖。單機(jī)游戲的主循環(huán)沒(méi)有高性能需求Forms.Timer 的毫秒級(jí)精度完全夠用。初始化代碼長(zhǎng)這樣private void InitGameLoop() { gameTimer new Timer(); gameTimer.Interval 200; // 200ms 一次Tick即每秒5次 gameTimer.Tick GameTimer_Tick; gameTimer.Start(); gameData.TickSec 3; // 每個(gè)Tick相當(dāng)于游戲內(nèi)3秒 tickCounter 0; } private void GameTimer_Tick(object sender, EventArgs e) { if (!gameData.IsRunning) return; tickCounter; gameManager.UpdateIncome(gameData); // 第1步所有在停車(chē)輛結(jié)算收益 gameManager.UpdateCooldown(gameData); // 第2步檢測(cè)冷卻結(jié)束恢復(fù)可用 if (tickCounter % aiDecisionInterval 0) // 第3步AI按節(jié)奏做決策 { aiController.Decide(gameData); } if (tickCounter % uiRefreshInterval 0) // 第4步定時(shí)刷新界面不每Tick刷 { RenderBoard(); } }這里有個(gè)容易抄錯(cuò)的地方Interval 為什么用 200 而不是 1000因?yàn)槭找娼Y(jié)算如果每秒才走一次玩家看到的數(shù)字變化是跳變沒(méi)有“金幣在漲”的持續(xù)感反過(guò)來(lái)如果每毫秒結(jié)算一次CPU 浪費(fèi)嚴(yán)重。200ms 一個(gè) Tick每 5 個(gè) Tick 湊成游戲內(nèi) 3 秒需要改游戲速度時(shí)只改 TickSecTimer 本身不用動(dòng)。參數(shù)上aiDecisionInterval 默認(rèn)設(shè) 6意思是 AI 每 6 個(gè) Tick、約 1.2 秒決策一次uiRefreshInterval 默認(rèn)設(shè) 10即約 2 秒刷新一次界面。UI 刷新頻率別設(shè)太高WinForms 里每次改 PictureBox 的 BackColor 都會(huì)觸發(fā)一次重繪48 個(gè)車(chē)位全刷一遍就容易閃爍這個(gè)玄學(xué)問(wèn)題第 5 章再展開(kāi)。3. 把停車(chē)邏輯寫(xiě)成代碼車(chē)位狀態(tài)機(jī)與收益結(jié)算3.1 車(chē)位的四種狀態(tài)與狀態(tài)遷移條件車(chē)位的生命周期可以抽象成四種狀態(tài)空閑、占用未貼條、占用已貼條、冷卻中。嚴(yán)格說(shuō)冷卻屬于車(chē)輛狀態(tài)但它的存在影響了車(chē)位的可停判定所以實(shí)際編碼時(shí)兩個(gè)狀態(tài)要一起判斷。把這四種狀態(tài)畫(huà)成遷移圖邏輯是這樣的空閑狀態(tài)下玩家或 AI 可以停車(chē)進(jìn)入占用占用狀態(tài)下可以被貼條進(jìn)入已貼條占用和已貼條狀態(tài)下都可以被拖車(chē)拖完后車(chē)位回到空閑車(chē)輛進(jìn)入冷卻冷卻結(jié)束車(chē)輛重新可用?？雌饋?lái)簡(jiǎn)單但“貼條之后能不能拖”這個(gè)細(xì)節(jié)很多初版實(shí)現(xiàn)都會(huì)做錯(cuò)資源里明確要求貼條后的車(chē)不能再被拖避免雙重懲罰疊加。核心方法全部收斂在 GameManager 里三個(gè)方法對(duì)應(yīng)三個(gè)玩家動(dòng)作public bool TryPark(GameData data, int carId, int spaceId) { var car FindCar(data, carId); var space data.Spaces[spaceId]; if (space.ParkedCarId ! -1) { return false; // 車(chē)位被占不能停 } if (car.InCooldown) { return false; // 被拖后冷卻中 } if (car.CurrentSpaceId ! -1) { // 自己已有車(chē)停在別處停到新位子時(shí)先把舊車(chē)收回來(lái) var oldSpace data.Spaces[car.CurrentSpaceId]; oldSpace.ParkedCarId -1; oldSpace.HasTicket false; car.AccIncome 0; } space.ParkedCarId carId; space.ParkedAt DateTime.Now; car.CurrentSpaceId spaceId; return true; }注意 TryPark 的返回值是 bool這是給 UI 層用的。玩家點(diǎn)了空車(chē)位但停車(chē)失敗時(shí)UI 層要根據(jù)返回值決定彈提示還是靜默處理如果方法返回 voidUI 層就只能靠猜。另外移動(dòng)舊車(chē)時(shí)把 AccIncome 清零并且把舊車(chē)位的 HasTicket 也重置這兩步缺一不可。漏掉 HasTicket 重置的話舊車(chē)位會(huì)殘留“已貼條”標(biāo)記后續(xù) AI 決策時(shí)以為那里有車(chē)可貼直接空指針或者收益錯(cuò)亂。接下來(lái)是貼條和拖車(chē)public bool TryTicket(GameData data, int spaceId) { var space data.Spaces[spaceId]; if (space.ParkedCarId -1 || space.HasTicket) { return false; // 沒(méi)車(chē)可貼或者已經(jīng)貼過(guò) } var car FindCar(data, space.ParkedCarId); var player FindOwner(data, car.Id); int fine (int)(car.AccIncome * 0.5) 20; // 罰金收入一半加20保底 player.Money - Math.Min(player.Money, fine); // 收益不夠就從本金扣 car.AccIncome 0; space.HasTicket true; return true; } public bool TryTow(GameData data, int spaceId) { var space data.Spaces[spaceId]; if (space.ParkedCarId -1 || space.HasTicket) { return false; // 拖車(chē)只對(duì)未貼條的在停車(chē)輛生效 } var car FindCar(data, space.ParkedCarId); var player FindOwner(data, car.Id); int fine (int)(car.AccIncome * 0.8); player.Money - Math.Min(player.Money, fine); car.AccIncome 0; car.CurrentSpaceId -1; car.InCooldown true; car.CooldownEnd DateTime.Now.AddSeconds(config.TowCooldownSec); space.ParkedCarId -1; space.HasTicket false; return true; }兩個(gè)方法的公共判斷都用條件表達(dá)式合在一行這是故意的貼條和拖車(chē)的目標(biāo)條件高度相似寫(xiě)進(jìn)方法的開(kāi)頭一眼就能看出差異只在 HasTicket 的判斷。罰金里Math.Min(player.Money, fine)的處理要說(shuō)明一下——如果玩家的當(dāng)前金幣小于罰金只扣到 0不讓玩家負(fù)債。課程設(shè)計(jì)答辯時(shí)經(jīng)常會(huì)被問(wèn)到“罰金不夠扣怎么辦”這個(gè)實(shí)現(xiàn)就是標(biāo)準(zhǔn)答案。3.2 點(diǎn)擊命中檢測(cè)用控件數(shù)組而不是算像素坐標(biāo)點(diǎn)擊車(chē)位做交互是初版實(shí)現(xiàn)翻車(chē)率最高的地方。常見(jiàn)的做法是給地圖 Panel 掛一個(gè) MouseClick 事件然后用 e.Location 除以格子寬高算行列。聽(tīng)起來(lái)很合理但實(shí)際跑起來(lái)經(jīng)常點(diǎn)一個(gè)格子響應(yīng)的是旁邊那個(gè)因?yàn)?Panel 有邊框、有 Padding、有 AutoScrollPosition甚至窗體縮放后格子尺寸變了你硬編碼的固定行列全部失效。這個(gè)資源里的做法非常務(wù)實(shí)用 TableLayoutPanel 鋪滿(mǎn) PictureBox 矩陣每個(gè) PictureBox 對(duì)應(yīng)一個(gè) ParkingSpace點(diǎn)擊事件掛在格子上Tag 里存車(chē)位索引。這樣甚至不需要寫(xiě)坐標(biāo)換算鼠標(biāo)點(diǎn)的是哪個(gè) PictureBox就必然是哪一個(gè)車(chē)位。// 初始化 6 行 8 列的網(wǎng)格映射到 GameData.Spaces for (int r 0; r rows; r) { for (int c 0; c cols; c) { var index r * cols c; var pic new PictureBox(); pic.Width cellW; pic.Height cellH; pic.Tag index; // Tag 存車(chē)位索引不存對(duì)象引用 pic.BackColor GetSpaceColor(data.Spaces[index]); pic.Click SpaceCell_Click; tableLayout.Controls.Add(pic, c, r); } } private void SpaceCell_Click(object sender, EventArgs e) { var pic (PictureBox)sender; int spaceIndex (int)pic.Tag; if (currentAction PlayerAction.Park) gameManager.TryPark(gameData, selectedCarId, spaceIndex); else if (currentAction PlayerAction.Ticket) gameManager.TryTicket(gameData, spaceIndex); else if (currentAction PlayerAction.Tow) gameManager.TryTow(gameData, spaceIndex); RenderBoard(); // 操作后立即刷新不等下一個(gè)UI刷新周期 }cellW 和 cellH 不要在初始化時(shí)寫(xiě)死應(yīng)該在 Form 的 Resize 事件里重新計(jì)算cellW (tableLayout.ClientSize.Width - tableLayout.Padding.Horizontal) / cols; cellH (tableLayout.ClientSize.Height - tableLayout.Padding.Vertical) / rows;Tag 里存索引而不是直接存 ParkingSpace 對(duì)象這算是一個(gè)防御性習(xí)慣如果后續(xù)在代碼里替換了整個(gè) Spaces 列表比如讀檔后重建索引仍然有效對(duì)象引用則會(huì)變成懸空引用。用控件數(shù)組方案之后鼠標(biāo)坐標(biāo)計(jì)算這個(gè)“玄學(xué)”環(huán)節(jié)完全消失了代價(jià)僅僅是內(nèi)存里多了幾十個(gè) PictureBox對(duì)單機(jī)游戲來(lái)說(shuō)可以忽略。3.3 收益結(jié)算上限、保底與結(jié)算順序收益結(jié)算是整個(gè)游戲的經(jīng)濟(jì)引擎代碼最短但最容易寫(xiě)歪。資源里的 UpdateIncome 方法在每次 Timer Tick 時(shí)被調(diào)用遍歷所有車(chē)位給停著的車(chē)?yán)奂邮找?。關(guān)鍵有三點(diǎn)收益上限、保底收益、結(jié)算順序。public void UpdateIncome(GameData data) { foreach (var space in data.Spaces) { if (space.ParkedCarId -1) continue; var car FindCar(data, space.ParkedCarId); if (car null || car.CurrentSpaceId ! space.Id) continue; // 收益上限判斷停車(chē)超過(guò) MaxStopSeconds 后不再漲錢(qián) var parkedDuration (DateTime.Now - space.ParkedAt).TotalSeconds; if (parkedDuration config.MaxStopSeconds) { continue; } int baseIncome config.BaseIncomePerMinute; double rate 1.0 car.Level * 0.2 space.Level * 0.1; int income (int)(baseIncome * rate * data.TickSec / 60.0); car.AccIncome Math.Max(income, 1); // 保底 1 金幣避免0收益 } }上限判斷用 DateTime 差值而不是 tick 計(jì)數(shù)器原因在第 2 章說(shuō)過(guò)存檔讀檔時(shí)只有 DateTime 能正確恢復(fù)。rate 的計(jì)算用的是加法稀釋乘法收益倍率 1 車(chē)輛等級(jí)加成 車(chē)位等級(jí)加成這樣后期數(shù)值膨脹速度可控。如果你改成 1.0 * 1.2^Level * 1.1^SpaceLevel指數(shù)增長(zhǎng)會(huì)在 30 分鐘后完全失控這是數(shù)值設(shè)計(jì)上的一個(gè)陷阱。保底 1 金幣必須加原因很實(shí)際TickSec 設(shè)置為 3 秒時(shí)基礎(chǔ)收益如果是 20 金幣/分鐘每個(gè) Tick 的理論收益是 1 金幣如果把 TickSec 改成 1 秒理論收益算下來(lái)是 0 金幣玩家看到車(chē)停了半天一分錢(qián)沒(méi)漲會(huì)認(rèn)為游戲壞了。Math.Max(income, 1)一行解決這個(gè)邊界問(wèn)題代價(jià)是極端低收益時(shí)金幣總量會(huì)略高于理論值但單機(jī)游戲內(nèi)部經(jīng)濟(jì)這點(diǎn)誤差無(wú)所謂。結(jié)算順序上保持“先結(jié)算收益后處理玩家操作”是這套源碼的一個(gè)隱式約定。玩家在兩次 UI 刷新之間點(diǎn)擊貼條貼條方法拿到的是最新結(jié)算過(guò)的 AccIncome罰金計(jì)算是準(zhǔn)的反過(guò)來(lái)如果先執(zhí)行操作再結(jié)算貼條罰金會(huì)少算一個(gè) Tick 的收益雖然單次誤差很小但累計(jì)起來(lái)就是“為什么我總是差幾塊錢(qián)”的詭異問(wèn)題。4. 單機(jī)版不冷場(chǎng)AI 對(duì)手的決策與實(shí)現(xiàn)4.1 三種行為與加權(quán)隨機(jī)為什么 AI 決定要“抽簽”單機(jī)版搶車(chē)位最怕冷場(chǎng)。如果 AI 只是在車(chē)位空著時(shí)去停游戲不會(huì)有任何對(duì)抗感所以資源里的 AI 集成了三種完整行為停車(chē)、貼條、拖車(chē)。但 AI 不能每次決策都做同樣的動(dòng)作否則行為模式很快就會(huì)被玩家摸透于是這里引入加權(quán)隨機(jī)——給每個(gè)行為分配一個(gè)權(quán)重值權(quán)重越大被抽中的概率越高。這樣 AI 的行為有隨機(jī)性但整體傾向可控。public void Decide(GameData data) { foreach (var ai in data.AIPlayers) { if (!ai.IsFree) continue; var action WeightedPick(ai.ParkWeight, ai.TicketWeight, ai.TowWeight); switch (action) { case AiAction.Park: PerformPark(data, ai); break; case AiAction.Ticket: PerformTicket(data, ai); break; case AiAction.Tow: PerformTow(data, ai); break; case AiAction.Wait: break; // 啥也不干模擬“在考慮中” } } } private AiAction WeightedPick(int parkW, int ticketW, int towW) { int total parkW ticketW towW 5; // 最后5是Wait的基礎(chǔ)權(quán)重 int rnd random.Next(total); if (rnd parkW) return AiAction.Park; if (rnd parkW ticketW) return AiAction.Ticket; if (rnd parkW ticketW towW) return AiAction.Tow; return AiAction.Wait; }加權(quán)隨機(jī)實(shí)現(xiàn)的細(xì)節(jié)在區(qū)間劃分。第一段區(qū)間長(zhǎng)度是 parkW第二段是 ticketW以此類(lèi)推。這里有個(gè)很隱蔽的 bug 源random必須是類(lèi)級(jí)別的靜態(tài)實(shí)例不能在 Decide 里new Random()。同一個(gè) Tick 里多個(gè) AI 依次決策如果各自 new Random系統(tǒng)時(shí)鐘種子相同的情況下會(huì)生成完全相同的隨機(jī)序列結(jié)果就是所有 AI 在同一次決策中做出一模一樣的動(dòng)作。這個(gè)資源里把 Random 設(shè)成了 GameManager 的靜態(tài)字段踩過(guò)這個(gè)坑的人都知道我在說(shuō)什么。4.2 決策前先做狀態(tài)快照防止 AI 之間串臺(tái)AI 決策過(guò)程中最容易出問(wèn)題的不是隨機(jī)數(shù)而是數(shù)據(jù)一致性。假設(shè)有 3 個(gè) AI第一個(gè) AI 停進(jìn)了 8 號(hào)車(chē)位第二個(gè) AI 在掃描空閑車(chē)位時(shí)也選中了 8 號(hào)——如果它直接讀實(shí)時(shí)的 data.Spaces會(huì)看到 8 號(hào)已經(jīng)被占然后跳過(guò)但如果它的掃描邏輯是先把所有空閑車(chē)位收集成 List再?gòu)闹须S機(jī)選一個(gè)而這個(gè) List 是決策開(kāi)始時(shí)生成的那它選中的可能正是第一個(gè) AI 剛占掉的車(chē)位最終停車(chē)失敗表現(xiàn)為“AI 莫名其妙發(fā)呆”。這個(gè)資源里的解法是給每次決策做一次數(shù)據(jù)快照所有 AI 基于同一個(gè)快照做判斷而不是基于實(shí)時(shí)變化的 Live 數(shù)據(jù)// AI 決策入場(chǎng)前鎖定一次狀態(tài)避免同一輪內(nèi)相互覆蓋 var snapshot data.Spaces.Select(s new SpaceSnapshot { SpaceId s.Id, ParkedCarId s.ParkedCarId, HasTicket s.HasTicket }).ToArray(); foreach (var ai in data.AIPlayers) { var target ChooseTargetFromSnapshot(snapshot, ai); if (target null) continue; // 真正執(zhí)行時(shí)要重新檢查實(shí)時(shí)狀態(tài)防止快照過(guò)期導(dǎo)致邏輯錯(cuò)亂 if (data.Spaces[target.SpaceId].ParkedCarId -1) { PerformPark(data, ai, target.SpaceId); } }SpaceSnapshot 是一個(gè)輕量結(jié)構(gòu)體只包含判斷所需的三個(gè)字段不引用實(shí)體對(duì)象?？煺盏拇嬖谧屚惠?AI 決策之間互不干擾玩起來(lái)的感覺(jué)就是“三個(gè) AI 在同一秒各自做了自己的決定”這正是單機(jī)版對(duì)多人博弈的模擬。但也要注意快照的時(shí)效執(zhí)行操作前必須回到實(shí)時(shí)數(shù)據(jù)上做一次二次校驗(yàn)否則 AI 的停車(chē)操作會(huì)因?yàn)榭煺者^(guò)期而頻繁失敗失敗率過(guò)高時(shí) AI 看起來(lái)就像一個(gè)傻子。4.3 難度參數(shù)三個(gè)檔位的調(diào)參建議資源內(nèi)置了新手、普通、困難三個(gè)難度檔位實(shí)際改動(dòng)只有一張表參數(shù)新手普通困難ThinkTick決策間隔864ParkWeight停車(chē)權(quán)重706050TicketWeight貼條權(quán)重202530TowWeight拖車(chē)權(quán)重51015AI 收益倍率1.01.01.2調(diào)難度的邏輯有兩條線。第一條是決策頻率ThinkTick 越小AI 行動(dòng)越頻繁玩家剛停下車(chē) 2 秒就被盯上的幾率越大壓迫感直接上升。第二條是行為傾向新手檔拖車(chē)權(quán)重只有 5AI 很少拖車(chē)玩家不會(huì)被突然清空車(chē)位困難檔把拖車(chē)權(quán)重拉高到 15同時(shí)給 AI 加了 1.2 倍收益倍率保證 AI 在頻繁對(duì)抗的同時(shí)自己的經(jīng)濟(jì)也能跟上玩家不會(huì)滾雪球崩盤(pán)。這里有個(gè)容易忽略的細(xì)節(jié)AI 收益倍率不是加在 AI 玩家的初始資金上而是加在 AI 每次收益結(jié)算的產(chǎn)出上。如果只調(diào)初始資金游戲進(jìn)行 10 分鐘后 AI 就會(huì)破產(chǎn)后續(xù)只能靠貼條和拖車(chē)維持行為模式會(huì)變得非常單調(diào)。倍率調(diào)產(chǎn)出才能讓 AI 長(zhǎng)期和玩家保持同層級(jí)的競(jìng)爭(zhēng)力。5. 避坑記錄搶車(chē)位開(kāi)發(fā)中常見(jiàn)的五個(gè)翻車(chē)現(xiàn)場(chǎng)5.1 界面卡死Tick 事件里做了耗時(shí)操作現(xiàn)象游戲運(yùn)行后點(diǎn)擊按鈕沒(méi)有任何反應(yīng)窗口拖動(dòng)時(shí)出現(xiàn)白屏幾秒后才恢復(fù)。原因Timer 事件本身在 UI 線程執(zhí)行如果 Tick 里阻塞了整條消息隊(duì)列全部排隊(duì)所有控件都卡死。當(dāng)時(shí)是在 RenderBoard 里循環(huán)給 48 個(gè) PictureBox 設(shè)置 BackColor 和 Text圖片數(shù)量多時(shí)一次刷新耗時(shí)接近 300ms而 Timer 每隔 200ms 就觸發(fā)一次等于 UI 線程永遠(yuǎn)在趕場(chǎng)。解決把“數(shù)據(jù)更新”和“界面渲染”徹底分層。Tick 事件里只改 GameData 數(shù)據(jù)RenderBoard 統(tǒng)一放在 uiRefreshInterval 控制下實(shí)測(cè)將刷新頻率降到 2 秒一次并把 PictureBox 的 DoubleBuffered 屬性設(shè)為 true界面卡死問(wèn)題完全消失。5.2 收益翻倍重復(fù)創(chuàng)建 Timer 沒(méi)釋放舊實(shí)例現(xiàn)象玩著玩著金幣增速突然變快打開(kāi)日志發(fā)現(xiàn) UpdateIncome 被執(zhí)行了兩次甚至三次。原因?qū)崿F(xiàn)“重新開(kāi)始游戲”功能時(shí)代碼里直接 new 了一個(gè) Timer 再 Start但沒(méi)有 Stop 和 Dispose 舊 Timer。舊實(shí)例還在 Tick 事件里繼續(xù)驅(qū)動(dòng) UpdateIncome新舊兩個(gè) Timer 同時(shí)在跑收益結(jié)算被重復(fù)執(zhí)行。解決新開(kāi)一局前強(qiáng)制執(zhí)行一次gameTimer?.Stop(); gameTimer?.Dispose();再 new 新實(shí)例。從那以后我每次寫(xiě)帶 Timer 的游戲都會(huì)養(yǎng)成習(xí)慣只要出現(xiàn)“重新開(kāi)始”“切換場(chǎng)景”這類(lèi)邏輯第一步永遠(yuǎn)是清理舊的定時(shí)器這個(gè)習(xí)慣幫我省了無(wú)數(shù)次排查時(shí)間。5.3 坐標(biāo)偏差固定行列在窗體縮放后全部錯(cuò)位現(xiàn)象窗口默認(rèn)大小時(shí)點(diǎn)擊正常把窗口拉大后點(diǎn)擊格子響應(yīng)的是旁邊甚至對(duì)角線的車(chē)位。原因初始化時(shí)把格子寬高寫(xiě)死成了默認(rèn)窗口對(duì)應(yīng)的尺寸Resize 后 PictureBox 被 TableLayoutPanel 自動(dòng)拉伸但點(diǎn)擊事件里記錄的車(chē)位索引仍然按初始化時(shí)的順序排列。其實(shí)這個(gè)方案本身沒(méi)有錯(cuò)錯(cuò)的是格子尺寸沒(méi)有跟著重算。解決改用控件數(shù)組方案后把 cellW 和 cellH 的計(jì)算放在 Resize 事件里每次窗體尺寸變化都重新計(jì)算。代碼上只加了幾行但從此坐標(biāo)偏移的問(wèn)題再?zèng)]出現(xiàn)。如果堅(jiān)持用坐標(biāo)手動(dòng)算行列還需要額外減去 Panel 的 Padding 和 Border 寬度那個(gè)組合就是玄學(xué)中的玄學(xué)。5.4 貼條與拖車(chē)同時(shí)生效AI 把玩家打到倒欠金幣現(xiàn)象玩家車(chē)輛先被貼條緊接著又被拖走兩者罰金疊加玩家金幣直接變負(fù)游戲數(shù)值崩壞。原因TryTicket 和 TryTow 都只檢查了車(chē)輛是否存在沒(méi)有互斥檢查。貼條之后車(chē)還在原車(chē)位拖車(chē)邏輯又把它判定為“可拖對(duì)象”兩套罰金疊在一起扣。解決在 TryTow 開(kāi)頭加上if (space.HasTicket) return false;明確貼條和拖車(chē)是互斥動(dòng)作。規(guī)則上貼條后的車(chē)不能被拖這樣罰金只有一筆玩家損失可預(yù)期AI 的連招懲罰也不會(huì)顯得“不講道理”。5.5 讀檔后時(shí)間錯(cuò)亂DateTime 直接序列化導(dǎo)致收益上限失效現(xiàn)象昨晚存檔時(shí)車(chē)才停了 5 分鐘今天打開(kāi)繼續(xù)車(chē)子的收益直接變成 0顯示已到上限。原因存檔時(shí)把 ParkedAt 按 DateTime 序列化讀檔后 DateTime.Now 減去存檔里的 ParkedAt得到的是包含整個(gè)離線時(shí)間段的差值遠(yuǎn)超收益上限系統(tǒng)理所當(dāng)然地認(rèn)為收益已經(jīng)停發(fā)。解決存檔時(shí)不要存 ParkedAt而是存累計(jì)停車(chē)秒數(shù)。讀檔后重建 ParkedAtspace.ParkedAt DateTime.Now.AddSeconds(-space.ParkedElapsedSeconds);這樣離線時(shí)間不會(huì)混入收益時(shí)長(zhǎng)。另一個(gè)坑是 DateTime 在 JSON 里默認(rèn)序列化成帶時(shí)區(qū)的 UTC 字符串讀檔回來(lái)如果不轉(zhuǎn)換成當(dāng)?shù)貢r(shí)間差值也會(huì)錯(cuò)建議統(tǒng)一用 DateTimeOffset 或者干脆在存檔類(lèi)里全用 Unix 時(shí)間戳。6. 越玩越像樣JSON 存檔、車(chē)位升級(jí)與數(shù)值平衡技巧6.1 用 System.Text.Json 做存檔注意版本兼容存檔是課程設(shè)計(jì)里最容易拿加分也最容易丟分的點(diǎn)。資源里沒(méi)有用復(fù)雜的二進(jìn)制格式就是 System.Text.Json 直接序列化 GameData 對(duì)象public void SaveGame(GameData data, string filePath) { var options new JsonSerializerOptions { WriteIndented true, Converters { new JsonStringEnumConverter() } }; var json JsonSerializer.Serialize(data, data.GetType(), options); File.WriteAllText(filePath, json); } public GameData LoadGame(string filePath) { var json File.ReadAllText(filePath); var data JsonSerializer.DeserializeGameData(json); return data; }因?yàn)樗袑?shí)體類(lèi)都是普通對(duì)象序列化不需要額外標(biāo)記。如果以后給類(lèi)加了新字段建議在存檔里加一個(gè) version 字段讀檔時(shí)判斷版本做字段補(bǔ)默認(rèn)值避免舊存檔直接反序列化報(bào)錯(cuò)。這個(gè) version 字段不用參與游戲邏輯只在存檔類(lèi)里額外掛一個(gè)屬性就行。6.2 貼條罰金別寫(xiě) 100%一個(gè)保底公式數(shù)值平衡是整個(gè)單機(jī)版能“玩得下去”的底線。貼條罰金如果設(shè)為當(dāng)前累計(jì)收益的 100%玩家停滿(mǎn)半小時(shí)被貼一次條直接歸零挫敗感強(qiáng)到想刪游戲。資源里的處理方式是 50% 加固定保底int fine (int)(car.AccIncome * 0.5) 20;這樣收益低的階段貼條也有 20 金幣保底收益AI 不會(huì)因?yàn)橥婕臆?chē)上的錢(qián)少而懶得貼條收益高的時(shí)候罰金不會(huì)超過(guò)收入的一半玩家的損失可接受也有動(dòng)力繼續(xù)經(jīng)營(yíng)。拖車(chē)罰金用 80% 而不是 100%也是同樣的道理——拖車(chē)是最強(qiáng)的懲罰手段但直接清零會(huì)讓玩家覺(jué)得“這個(gè)游戲不講道理”。車(chē)位升級(jí)的數(shù)值設(shè)計(jì)也是同理每升一級(jí)花費(fèi)是當(dāng)前等級(jí)金幣的 1.8 倍收益加成只加 10%。這個(gè)曲線保證前期升級(jí)便宜、收益提升明顯后期升級(jí)貴但在玩家可負(fù)擔(dān)范圍內(nèi)。整個(gè)升級(jí)系統(tǒng)給了玩家一個(gè)消耗金幣的出口不然游戲進(jìn)行 20 分鐘后金幣溢出所有懲罰都變得不痛不癢。說(shuō)到車(chē)位升級(jí)順手分享一個(gè)我自己的習(xí)慣每次調(diào)試數(shù)值平衡我都會(huì)強(qiáng)制走一遍“新號(hào)開(kāi)局 10 分鐘、掛機(jī) 1 小時(shí)、AI 困難檔”三個(gè)狀態(tài)的完整流程觀察金幣曲線和玩家挫敗感。這個(gè)項(xiàng)目我拆完后也重跑了一遍貼條保底公式就是從那輪調(diào)試?yán)锟吹降摹P金低于 20 金幣檔位AI 貼條熱情明顯下降。以后再做這類(lèi)模擬經(jīng)營(yíng)小游戲我應(yīng)該都會(huì)先拿這三檔流程測(cè)試一遍再交出去。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取 C#實(shí)戰(zhàn)：從0到1實(shí)現(xiàn)單機(jī)版搶車(chē)位游戲
簡(jiǎn)介基于C#語(yǔ)言開(kāi)發(fā)的單機(jī)版搶車(chē)位游戲完整源碼面向C#初學(xué)者、面向?qū)ο缶幊虒W(xué)習(xí)者及游戲開(kāi)發(fā)入門(mén)者。以搶車(chē)位玩法為載體完整演示了從玩家、車(chē)輛、車(chē)位等類(lèi)設(shè)計(jì)到用戶(hù)登錄、窗體交互、游戲循環(huán)的開(kāi)發(fā)鏈路適合課程設(shè)計(jì)、個(gè)人練手或畢業(yè)設(shè)計(jì)參考。壓縮包共83個(gè)文件大小6.37MB主要包含15個(gè)cs源碼文件核心邏輯與窗體、37個(gè)png和9個(gè)jpg界面素材、3個(gè)resx與3個(gè)resources資源文件另有exe可執(zhí)行程序、功能說(shuō)明doc文檔和初始化玩家對(duì)象的txt代碼目錄清晰便于運(yùn)行和修改。已有244人學(xué)習(xí)瀏覽。源碼開(kāi)放可直接查看和修改包含Player、Car、ParkingSpace、LoginFrm、ManiFrm等核心類(lèi)模擬隨機(jī)事件、時(shí)間限制與策略決策并涉及線程同步、計(jì)時(shí)器等機(jī)制配套文檔詳細(xì)說(shuō)明了界面布局、按鈕功能和操作流程初始化示例展示了創(chuàng)建玩家對(duì)象、分配初始資源的完整步驟對(duì)理解封裝、繼承、多態(tài)以及多窗體程序組織方式都有直接幫助也能根據(jù)需求擴(kuò)展車(chē)位類(lèi)型或調(diào)整游戲規(guī)則非常適合作為C#實(shí)戰(zhàn)練習(xí)項(xiàng)目。1. 單機(jī)版搶車(chē)位把社交玩法壓進(jìn) C# 的一個(gè)完整閉環(huán)搶車(chē)位這個(gè)玩法經(jīng)歷過(guò)社交平臺(tái)時(shí)代的人都不陌生把車(chē)停到別人車(chē)位賺錢(qián)趁對(duì)方離線時(shí)貼條、拖車(chē)最刺激的就是收益上限卡點(diǎn)前被人清空車(chē)位。放在當(dāng)年這套規(guī)則幾乎全在服務(wù)端本地只負(fù)責(zé)發(fā)請(qǐng)求想把它改成一個(gè)離線可玩、邏輯完整、拿得出手的 C# 項(xiàng)目得把停車(chē)、貼條、拖車(chē)、AI 對(duì)手整個(gè)重寫(xiě)一遍。這份資源做的就是這件事它不是教學(xué) Demo而是一套能直接編譯運(yùn)行、完整玩完一把對(duì)局的課程設(shè)計(jì)級(jí)源碼。適合正在找 C# 題目交差的學(xué)生也適合想從增刪改查跳出來(lái)、認(rèn)真摸一遍游戲狀態(tài)機(jī)寫(xiě)法的初學(xué)者。2. 先拆玩法再拆代碼搶車(chē)位的核心規(guī)則與類(lèi)設(shè)計(jì)2.1 搶車(chē)位到底在搶什么貼條與拖車(chē)的收益閉環(huán)先說(shuō)玩法因?yàn)轭?lèi)設(shè)計(jì)完全由玩法推導(dǎo)出來(lái)。經(jīng)典搶車(chē)位的循環(huán)是這樣地圖上有若干公共車(chē)位玩家的車(chē)停進(jìn)去后按分鐘產(chǎn)出金幣收益有上限停得越久越接近上限。但車(chē)位是有限的別人的車(chē)占著位置你就可以對(duì)他做兩件事貼條沒(méi)收他當(dāng)前累計(jì)收益的一半作為罰金拖車(chē)直接清空累計(jì)收益并把車(chē)送回空閑狀態(tài)進(jìn)入一段冷卻時(shí)間。這兩個(gè)動(dòng)作構(gòu)成了整個(gè)游戲的博弈核心車(chē)位越熱門(mén)、停得越久越容易被針對(duì)。單機(jī)版最大的問(wèn)題在于沒(méi)有真人來(lái)“惡心”你。如果沒(méi)有AI這個(gè)游戲本質(zhì)上就是個(gè)倒計(jì)時(shí)領(lǐng)錢(qián)器五分鐘就沒(méi)勁了。所以這套資源里實(shí)現(xiàn)了AI玩家來(lái)承擔(dān)對(duì)抗角色它會(huì)有三種行為基元尋找空位停車(chē)、給玩家或者其他AI的車(chē)貼條、拖別人的車(chē)。各行為觸發(fā)概率由難度參數(shù)控制后面第4章單獨(dú)講。先把規(guī)則定下來(lái)所有的代碼邏輯都以這張表為準(zhǔn)。動(dòng)作目標(biāo)條件效果罰金公式停車(chē)車(chē)位空閑車(chē)輛不在冷卻車(chē)位被占開(kāi)始累計(jì)收益無(wú)貼條車(chē)位被占且未被貼條沒(méi)收當(dāng)前累計(jì)收益標(biāo)記貼條AccIncome × 50% 20拖車(chē)車(chē)位被占且未被貼條清空累計(jì)收益車(chē)輛進(jìn)冷卻AccIncome × 80%挪車(chē)玩家同一輛車(chē)停到新空位舊車(chē)位釋放累計(jì)收益清零無(wú)這張表是整套源碼的基石后續(xù)所有方法都圍繞它展開(kāi)。注意“挪車(chē)”這條容易被忽略經(jīng)典規(guī)則里把車(chē)從 A 車(chē)位挪到 B 車(chē)位A 車(chē)位釋放但累計(jì)收益清零。這么設(shè)計(jì)是為了防刷錢(qián)——如果挪車(chē)不清零玩家可以把車(chē)停在高級(jí)車(chē)位上賺滿(mǎn)上限再挪到另一個(gè)高級(jí)車(chē)位繼續(xù)賺等于無(wú)限套利。拿到源碼后改功能時(shí)這條規(guī)則建議不要?jiǎng)右粍?dòng)經(jīng)濟(jì)系統(tǒng)就崩。2.2 六張核心類(lèi)圖從 Car 到 GameData 的職責(zé)劃分接下來(lái)看資源里的類(lèi)設(shè)計(jì)。它沒(méi)有用復(fù)雜的框架就是幾個(gè)實(shí)體類(lèi)加一個(gè)游戲管理類(lèi)。實(shí)體類(lèi)全部采用“貧血模型”只存數(shù)據(jù)不寫(xiě)邏輯規(guī)則統(tǒng)一放在 GameManager 里。為什么這么分因?yàn)橥＼?chē)、貼條、拖車(chē)之間交互頻繁貼條要改車(chē)位狀態(tài)、改車(chē)輛收益、改玩家金幣如果規(guī)則散落在實(shí)體類(lèi)里后期調(diào)整 AI 策略時(shí)會(huì)改到懷疑人生。集中管理后規(guī)則的入口只有一個(gè)調(diào)試時(shí)下斷點(diǎn)也只盯 GameManager 一個(gè)類(lèi)。核心實(shí)體類(lèi)的定義如下命名空間統(tǒng)一放在 ParkingGame.Models 下public class Car { public int Id { get; set; } public string Nickname { get; set; } // 車(chē)牌昵稱(chēng)玩家自定義 public int Level { get; set; } // 等級(jí)影響收益加成 public int AccIncome { get; set; } // 當(dāng)前累計(jì)未結(jié)算收益 public int CurrentSpaceId { get; set; } // 當(dāng)前所在車(chē)位Id-1表示閑置 public bool InCooldown { get; set; } // 拖車(chē)后的冷卻標(biāo)志 public DateTime CooldownEnd { get; set; } // 冷卻結(jié)束時(shí)間 } public class ParkingSpace { public int Id { get; set; } public int Row { get; set; } public int Col { get; set; } public int Level { get; set; } // 車(chē)位等級(jí)影響基礎(chǔ)收益倍率 public int ParkedCarId { get; set; } // 停著的車(chē)Id-1表示空閑 public bool HasTicket { get; set; } // 是否被貼條 public DateTime ParkedAt { get; set; } // 停車(chē)時(shí)間用于收益上限計(jì)算 } public class Player { public string Name { get; set; } public int Money { get; set; } public ListCar Cars { get; set; } } public class GameData { public Player HumanPlayer { get; set; } public ListAIPlayer AIPlayers { get; set; } public ListParkingSpace Spaces { get; set; } public int TickSec { get; set; } // 每個(gè)Tick對(duì)應(yīng)的游戲秒數(shù) public bool IsRunning { get; set; } }這段代碼有幾個(gè)細(xì)節(jié)值得說(shuō)。Car 里的 CurrentSpaceId 用 -1 表示閑置而不是用int?原因有兩個(gè)一是 JSON 序列化時(shí) -1 不需要額外處理存檔讀檔更省事二是判斷“這輛車(chē)現(xiàn)在有沒(méi)有停在車(chē)位上”時(shí)寫(xiě)成car.CurrentSpaceId -1一眼就能看懂不會(huì)出現(xiàn) null 判斷漏掉的情況。ParkingSpace 里的 ParkedAt 用的是 DateTime 而不是 tick 計(jì)數(shù)這是為了存檔后不丟收益進(jìn)度——如果你存的是“停了 300 個(gè) tick”讀檔后 Timer 重啟tick 數(shù)就對(duì)不上了DateTime 則能通過(guò)相對(duì)時(shí)間差恢復(fù)。AIPlayer 在資源里單獨(dú)定義它繼承 Player額外帶一組決策權(quán)重字段public class AIPlayer : Player { public int ParkWeight { get; set; } // 停車(chē)行為權(quán)重 public int TicketWeight { get; set; } // 貼條行為權(quán)重 public int TowWeight { get; set; } // 拖車(chē)行為權(quán)重 public int ThinkTick { get; set; } // 每幾Tick決策一次 }這組權(quán)重會(huì)在第 4 章詳細(xì)展開(kāi)?，F(xiàn)在只要知道每個(gè) AI 不是每 Tick 都行動(dòng)而是每隔 ThinkTick 才做一次決策這樣能模擬“思考延遲”也能避免 AI 行動(dòng)過(guò)于頻繁導(dǎo)致玩家毫無(wú)還手之力。想調(diào)出不同性格的 AI就是改這四個(gè)數(shù)字后續(xù)不用動(dòng)任何邏輯代碼。2.3 游戲主循環(huán)Timer 驅(qū)動(dòng)的秒級(jí)收益結(jié)算機(jī)制整個(gè)游戲的調(diào)度核心是一個(gè) System.Windows.Forms.Timer。為什么不用 System.Timers.Timer因?yàn)?WinForms 的 Timer 事件在 UI 線程上觸發(fā)事件里可以直接改控件屬性不需要 Invoke 跨線程System.Timers.Timer 的回調(diào)在線程池線程上改界面必須 this.Invoke寫(xiě)起來(lái)麻煩還容易死鎖。單機(jī)游戲的主循環(huán)沒(méi)有高性能需求Forms.Timer 的毫秒級(jí)精度完全夠用。初始化代碼長(zhǎng)這樣private void InitGameLoop() { gameTimer new Timer(); gameTimer.Interval 200; // 200ms 一次Tick即每秒5次 gameTimer.Tick GameTimer_Tick; gameTimer.Start(); gameData.TickSec 3; // 每個(gè)Tick相當(dāng)于游戲內(nèi)3秒 tickCounter 0; } private void GameTimer_Tick(object sender, EventArgs e) { if (!gameData.IsRunning) return; tickCounter; gameManager.UpdateIncome(gameData); // 第1步所有在停車(chē)輛結(jié)算收益 gameManager.UpdateCooldown(gameData); // 第2步檢測(cè)冷卻結(jié)束恢復(fù)可用 if (tickCounter % aiDecisionInterval 0) // 第3步AI按節(jié)奏做決策 { aiController.Decide(gameData); } if (tickCounter % uiRefreshInterval 0) // 第4步定時(shí)刷新界面不每Tick刷 { RenderBoard(); } }這里有個(gè)容易抄錯(cuò)的地方Interval 為什么用 200 而不是 1000因?yàn)槭找娼Y(jié)算如果每秒才走一次玩家看到的數(shù)字變化是跳變沒(méi)有“金幣在漲”的持續(xù)感反過(guò)來(lái)如果每毫秒結(jié)算一次CPU 浪費(fèi)嚴(yán)重。200ms 一個(gè) Tick每 5 個(gè) Tick 湊成游戲內(nèi) 3 秒需要改游戲速度時(shí)只改 TickSecTimer 本身不用動(dòng)。參數(shù)上aiDecisionInterval 默認(rèn)設(shè) 6意思是 AI 每 6 個(gè) Tick、約 1.2 秒決策一次uiRefreshInterval 默認(rèn)設(shè) 10即約 2 秒刷新一次界面。UI 刷新頻率別設(shè)太高WinForms 里每次改 PictureBox 的 BackColor 都會(huì)觸發(fā)一次重繪48 個(gè)車(chē)位全刷一遍就容易閃爍這個(gè)玄學(xué)問(wèn)題第 5 章再展開(kāi)。3. 把停車(chē)邏輯寫(xiě)成代碼車(chē)位狀態(tài)機(jī)與收益結(jié)算3.1 車(chē)位的四種狀態(tài)與狀態(tài)遷移條件車(chē)位的生命周期可以抽象成四種狀態(tài)空閑、占用未貼條、占用已貼條、冷卻中。嚴(yán)格說(shuō)冷卻屬于車(chē)輛狀態(tài)但它的存在影響了車(chē)位的可停判定所以實(shí)際編碼時(shí)兩個(gè)狀態(tài)要一起判斷。把這四種狀態(tài)畫(huà)成遷移圖邏輯是這樣的空閑狀態(tài)下玩家或 AI 可以停車(chē)進(jìn)入占用占用狀態(tài)下可以被貼條進(jìn)入已貼條占用和已貼條狀態(tài)下都可以被拖車(chē)拖完后車(chē)位回到空閑車(chē)輛進(jìn)入冷卻冷卻結(jié)束車(chē)輛重新可用?？雌饋?lái)簡(jiǎn)單但“貼條之后能不能拖”這個(gè)細(xì)節(jié)很多初版實(shí)現(xiàn)都會(huì)做錯(cuò)資源里明確要求貼條后的車(chē)不能再被拖避免雙重懲罰疊加。核心方法全部收斂在 GameManager 里三個(gè)方法對(duì)應(yīng)三個(gè)玩家動(dòng)作public bool TryPark(GameData data, int carId, int spaceId) { var car FindCar(data, carId); var space data.Spaces[spaceId]; if (space.ParkedCarId ! -1) { return false; // 車(chē)位被占不能停 } if (car.InCooldown) { return false; // 被拖后冷卻中 } if (car.CurrentSpaceId ! -1) { // 自己已有車(chē)停在別處停到新位子時(shí)先把舊車(chē)收回來(lái) var oldSpace data.Spaces[car.CurrentSpaceId]; oldSpace.ParkedCarId -1; oldSpace.HasTicket false; car.AccIncome 0; } space.ParkedCarId carId; space.ParkedAt DateTime.Now; car.CurrentSpaceId spaceId; return true; }注意 TryPark 的返回值是 bool這是給 UI 層用的。玩家點(diǎn)了空車(chē)位但停車(chē)失敗時(shí)UI 層要根據(jù)返回值決定彈提示還是靜默處理如果方法返回 voidUI 層就只能靠猜。另外移動(dòng)舊車(chē)時(shí)把 AccIncome 清零并且把舊車(chē)位的 HasTicket 也重置這兩步缺一不可。漏掉 HasTicket 重置的話舊車(chē)位會(huì)殘留“已貼條”標(biāo)記后續(xù) AI 決策時(shí)以為那里有車(chē)可貼直接空指針或者收益錯(cuò)亂。接下來(lái)是貼條和拖車(chē)public bool TryTicket(GameData data, int spaceId) { var space data.Spaces[spaceId]; if (space.ParkedCarId -1 || space.HasTicket) { return false; // 沒(méi)車(chē)可貼或者已經(jīng)貼過(guò) } var car FindCar(data, space.ParkedCarId); var player FindOwner(data, car.Id); int fine (int)(car.AccIncome * 0.5) 20; // 罰金收入一半加20保底 player.Money - Math.Min(player.Money, fine); // 收益不夠就從本金扣 car.AccIncome 0; space.HasTicket true; return true; } public bool TryTow(GameData data, int spaceId) { var space data.Spaces[spaceId]; if (space.ParkedCarId -1 || space.HasTicket) { return false; // 拖車(chē)只對(duì)未貼條的在停車(chē)輛生效 } var car FindCar(data, space.ParkedCarId); var player FindOwner(data, car.Id); int fine (int)(car.AccIncome * 0.8); player.Money - Math.Min(player.Money, fine); car.AccIncome 0; car.CurrentSpaceId -1; car.InCooldown true; car.CooldownEnd DateTime.Now.AddSeconds(config.TowCooldownSec); space.ParkedCarId -1; space.HasTicket false; return true; }兩個(gè)方法的公共判斷都用條件表達(dá)式合在一行這是故意的貼條和拖車(chē)的目標(biāo)條件高度相似寫(xiě)進(jìn)方法的開(kāi)頭一眼就能看出差異只在 HasTicket 的判斷。罰金里Math.Min(player.Money, fine)的處理要說(shuō)明一下——如果玩家的當(dāng)前金幣小于罰金只扣到 0不讓玩家負(fù)債。課程設(shè)計(jì)答辯時(shí)經(jīng)常會(huì)被問(wèn)到“罰金不夠扣怎么辦”這個(gè)實(shí)現(xiàn)就是標(biāo)準(zhǔn)答案。3.2 點(diǎn)擊命中檢測(cè)用控件數(shù)組而不是算像素坐標(biāo)點(diǎn)擊車(chē)位做交互是初版實(shí)現(xiàn)翻車(chē)率最高的地方。常見(jiàn)的做法是給地圖 Panel 掛一個(gè) MouseClick 事件然后用 e.Location 除以格子寬高算行列。聽(tīng)起來(lái)很合理但實(shí)際跑起來(lái)經(jīng)常點(diǎn)一個(gè)格子響應(yīng)的是旁邊那個(gè)因?yàn)?Panel 有邊框、有 Padding、有 AutoScrollPosition甚至窗體縮放后格子尺寸變了你硬編碼的固定行列全部失效。這個(gè)資源里的做法非常務(wù)實(shí)用 TableLayoutPanel 鋪滿(mǎn) PictureBox 矩陣每個(gè) PictureBox 對(duì)應(yīng)一個(gè) ParkingSpace點(diǎn)擊事件掛在格子上Tag 里存車(chē)位索引。這樣甚至不需要寫(xiě)坐標(biāo)換算鼠標(biāo)點(diǎn)的是哪個(gè) PictureBox就必然是哪一個(gè)車(chē)位。// 初始化 6 行 8 列的網(wǎng)格映射到 GameData.Spaces for (int r 0; r rows; r) { for (int c 0; c cols; c) { var index r * cols c; var pic new PictureBox(); pic.Width cellW; pic.Height cellH; pic.Tag index; // Tag 存車(chē)位索引不存對(duì)象引用 pic.BackColor GetSpaceColor(data.Spaces[index]); pic.Click SpaceCell_Click; tableLayout.Controls.Add(pic, c, r); } } private void SpaceCell_Click(object sender, EventArgs e) { var pic (PictureBox)sender; int spaceIndex (int)pic.Tag; if (currentAction PlayerAction.Park) gameManager.TryPark(gameData, selectedCarId, spaceIndex); else if (currentAction PlayerAction.Ticket) gameManager.TryTicket(gameData, spaceIndex); else if (currentAction PlayerAction.Tow) gameManager.TryTow(gameData, spaceIndex); RenderBoard(); // 操作后立即刷新不等下一個(gè)UI刷新周期 }cellW 和 cellH 不要在初始化時(shí)寫(xiě)死應(yīng)該在 Form 的 Resize 事件里重新計(jì)算cellW (tableLayout.ClientSize.Width - tableLayout.Padding.Horizontal) / cols; cellH (tableLayout.ClientSize.Height - tableLayout.Padding.Vertical) / rows;Tag 里存索引而不是直接存 ParkingSpace 對(duì)象這算是一個(gè)防御性習(xí)慣如果后續(xù)在代碼里替換了整個(gè) Spaces 列表比如讀檔后重建索引仍然有效對(duì)象引用則會(huì)變成懸空引用。用控件數(shù)組方案之后鼠標(biāo)坐標(biāo)計(jì)算這個(gè)“玄學(xué)”環(huán)節(jié)完全消失了代價(jià)僅僅是內(nèi)存里多了幾十個(gè) PictureBox對(duì)單機(jī)游戲來(lái)說(shuō)可以忽略。3.3 收益結(jié)算上限、保底與結(jié)算順序收益結(jié)算是整個(gè)游戲的經(jīng)濟(jì)引擎代碼最短但最容易寫(xiě)歪。資源里的 UpdateIncome 方法在每次 Timer Tick 時(shí)被調(diào)用遍歷所有車(chē)位給停著的車(chē)?yán)奂邮找?。關(guān)鍵有三點(diǎn)收益上限、保底收益、結(jié)算順序。public void UpdateIncome(GameData data) { foreach (var space in data.Spaces) { if (space.ParkedCarId -1) continue; var car FindCar(data, space.ParkedCarId); if (car null || car.CurrentSpaceId ! space.Id) continue; // 收益上限判斷停車(chē)超過(guò) MaxStopSeconds 后不再漲錢(qián) var parkedDuration (DateTime.Now - space.ParkedAt).TotalSeconds; if (parkedDuration config.MaxStopSeconds) { continue; } int baseIncome config.BaseIncomePerMinute; double rate 1.0 car.Level * 0.2 space.Level * 0.1; int income (int)(baseIncome * rate * data.TickSec / 60.0); car.AccIncome Math.Max(income, 1); // 保底 1 金幣避免0收益 } }上限判斷用 DateTime 差值而不是 tick 計(jì)數(shù)器原因在第 2 章說(shuō)過(guò)存檔讀檔時(shí)只有 DateTime 能正確恢復(fù)。rate 的計(jì)算用的是加法稀釋乘法收益倍率 1 車(chē)輛等級(jí)加成 車(chē)位等級(jí)加成這樣后期數(shù)值膨脹速度可控。如果你改成 1.0 * 1.2^Level * 1.1^SpaceLevel指數(shù)增長(zhǎng)會(huì)在 30 分鐘后完全失控這是數(shù)值設(shè)計(jì)上的一個(gè)陷阱。保底 1 金幣必須加原因很實(shí)際TickSec 設(shè)置為 3 秒時(shí)基礎(chǔ)收益如果是 20 金幣/分鐘每個(gè) Tick 的理論收益是 1 金幣如果把 TickSec 改成 1 秒理論收益算下來(lái)是 0 金幣玩家看到車(chē)停了半天一分錢(qián)沒(méi)漲會(huì)認(rèn)為游戲壞了。Math.Max(income, 1)一行解決這個(gè)邊界問(wèn)題代價(jià)是極端低收益時(shí)金幣總量會(huì)略高于理論值但單機(jī)游戲內(nèi)部經(jīng)濟(jì)這點(diǎn)誤差無(wú)所謂。結(jié)算順序上保持“先結(jié)算收益后處理玩家操作”是這套源碼的一個(gè)隱式約定。玩家在兩次 UI 刷新之間點(diǎn)擊貼條貼條方法拿到的是最新結(jié)算過(guò)的 AccIncome罰金計(jì)算是準(zhǔn)的反過(guò)來(lái)如果先執(zhí)行操作再結(jié)算貼條罰金會(huì)少算一個(gè) Tick 的收益雖然單次誤差很小但累計(jì)起來(lái)就是“為什么我總是差幾塊錢(qián)”的詭異問(wèn)題。4. 單機(jī)版不冷場(chǎng)AI 對(duì)手的決策與實(shí)現(xiàn)4.1 三種行為與加權(quán)隨機(jī)為什么 AI 決定要“抽簽”單機(jī)版搶車(chē)位最怕冷場(chǎng)。如果 AI 只是在車(chē)位空著時(shí)去停游戲不會(huì)有任何對(duì)抗感所以資源里的 AI 集成了三種完整行為停車(chē)、貼條、拖車(chē)。但 AI 不能每次決策都做同樣的動(dòng)作否則行為模式很快就會(huì)被玩家摸透于是這里引入加權(quán)隨機(jī)——給每個(gè)行為分配一個(gè)權(quán)重值權(quán)重越大被抽中的概率越高。這樣 AI 的行為有隨機(jī)性但整體傾向可控。public void Decide(GameData data) { foreach (var ai in data.AIPlayers) { if (!ai.IsFree) continue; var action WeightedPick(ai.ParkWeight, ai.TicketWeight, ai.TowWeight); switch (action) { case AiAction.Park: PerformPark(data, ai); break; case AiAction.Ticket: PerformTicket(data, ai); break; case AiAction.Tow: PerformTow(data, ai); break; case AiAction.Wait: break; // 啥也不干模擬“在考慮中” } } } private AiAction WeightedPick(int parkW, int ticketW, int towW) { int total parkW ticketW towW 5; // 最后5是Wait的基礎(chǔ)權(quán)重 int rnd random.Next(total); if (rnd parkW) return AiAction.Park; if (rnd parkW ticketW) return AiAction.Ticket; if (rnd parkW ticketW towW) return AiAction.Tow; return AiAction.Wait; }加權(quán)隨機(jī)實(shí)現(xiàn)的細(xì)節(jié)在區(qū)間劃分。第一段區(qū)間長(zhǎng)度是 parkW第二段是 ticketW以此類(lèi)推。這里有個(gè)很隱蔽的 bug 源random必須是類(lèi)級(jí)別的靜態(tài)實(shí)例不能在 Decide 里new Random()。同一個(gè) Tick 里多個(gè) AI 依次決策如果各自 new Random系統(tǒng)時(shí)鐘種子相同的情況下會(huì)生成完全相同的隨機(jī)序列結(jié)果就是所有 AI 在同一次決策中做出一模一樣的動(dòng)作。這個(gè)資源里把 Random 設(shè)成了 GameManager 的靜態(tài)字段踩過(guò)這個(gè)坑的人都知道我在說(shuō)什么。4.2 決策前先做狀態(tài)快照防止 AI 之間串臺(tái)AI 決策過(guò)程中最容易出問(wèn)題的不是隨機(jī)數(shù)而是數(shù)據(jù)一致性。假設(shè)有 3 個(gè) AI第一個(gè) AI 停進(jìn)了 8 號(hào)車(chē)位第二個(gè) AI 在掃描空閑車(chē)位時(shí)也選中了 8 號(hào)——如果它直接讀實(shí)時(shí)的 data.Spaces會(huì)看到 8 號(hào)已經(jīng)被占然后跳過(guò)但如果它的掃描邏輯是先把所有空閑車(chē)位收集成 List再?gòu)闹须S機(jī)選一個(gè)而這個(gè) List 是決策開(kāi)始時(shí)生成的那它選中的可能正是第一個(gè) AI 剛占掉的車(chē)位最終停車(chē)失敗表現(xiàn)為“AI 莫名其妙發(fā)呆”。這個(gè)資源里的解法是給每次決策做一次數(shù)據(jù)快照所有 AI 基于同一個(gè)快照做判斷而不是基于實(shí)時(shí)變化的 Live 數(shù)據(jù)// AI 決策入場(chǎng)前鎖定一次狀態(tài)避免同一輪內(nèi)相互覆蓋 var snapshot data.Spaces.Select(s new SpaceSnapshot { SpaceId s.Id, ParkedCarId s.ParkedCarId, HasTicket s.HasTicket }).ToArray(); foreach (var ai in data.AIPlayers) { var target ChooseTargetFromSnapshot(snapshot, ai); if (target null) continue; // 真正執(zhí)行時(shí)要重新檢查實(shí)時(shí)狀態(tài)防止快照過(guò)期導(dǎo)致邏輯錯(cuò)亂 if (data.Spaces[target.SpaceId].ParkedCarId -1) { PerformPark(data, ai, target.SpaceId); } }SpaceSnapshot 是一個(gè)輕量結(jié)構(gòu)體只包含判斷所需的三個(gè)字段不引用實(shí)體對(duì)象?？煺盏拇嬖谧屚惠?AI 決策之間互不干擾玩起來(lái)的感覺(jué)就是“三個(gè) AI 在同一秒各自做了自己的決定”這正是單機(jī)版對(duì)多人博弈的模擬。但也要注意快照的時(shí)效執(zhí)行操作前必須回到實(shí)時(shí)數(shù)據(jù)上做一次二次校驗(yàn)否則 AI 的停車(chē)操作會(huì)因?yàn)榭煺者^(guò)期而頻繁失敗失敗率過(guò)高時(shí) AI 看起來(lái)就像一個(gè)傻子。4.3 難度參數(shù)三個(gè)檔位的調(diào)參建議資源內(nèi)置了新手、普通、困難三個(gè)難度檔位實(shí)際改動(dòng)只有一張表參數(shù)新手普通困難ThinkTick決策間隔864ParkWeight停車(chē)權(quán)重706050TicketWeight貼條權(quán)重202530TowWeight拖車(chē)權(quán)重51015AI 收益倍率1.01.01.2調(diào)難度的邏輯有兩條線。第一條是決策頻率ThinkTick 越小AI 行動(dòng)越頻繁玩家剛停下車(chē) 2 秒就被盯上的幾率越大壓迫感直接上升。第二條是行為傾向新手檔拖車(chē)權(quán)重只有 5AI 很少拖車(chē)玩家不會(huì)被突然清空車(chē)位困難檔把拖車(chē)權(quán)重拉高到 15同時(shí)給 AI 加了 1.2 倍收益倍率保證 AI 在頻繁對(duì)抗的同時(shí)自己的經(jīng)濟(jì)也能跟上玩家不會(huì)滾雪球崩盤(pán)。這里有個(gè)容易忽略的細(xì)節(jié)AI 收益倍率不是加在 AI 玩家的初始資金上而是加在 AI 每次收益結(jié)算的產(chǎn)出上。如果只調(diào)初始資金游戲進(jìn)行 10 分鐘后 AI 就會(huì)破產(chǎn)后續(xù)只能靠貼條和拖車(chē)維持行為模式會(huì)變得非常單調(diào)。倍率調(diào)產(chǎn)出才能讓 AI 長(zhǎng)期和玩家保持同層級(jí)的競(jìng)爭(zhēng)力。5. 避坑記錄搶車(chē)位開(kāi)發(fā)中常見(jiàn)的五個(gè)翻車(chē)現(xiàn)場(chǎng)5.1 界面卡死Tick 事件里做了耗時(shí)操作現(xiàn)象游戲運(yùn)行后點(diǎn)擊按鈕沒(méi)有任何反應(yīng)窗口拖動(dòng)時(shí)出現(xiàn)白屏幾秒后才恢復(fù)。原因Timer 事件本身在 UI 線程執(zhí)行如果 Tick 里阻塞了整條消息隊(duì)列全部排隊(duì)所有控件都卡死。當(dāng)時(shí)是在 RenderBoard 里循環(huán)給 48 個(gè) PictureBox 設(shè)置 BackColor 和 Text圖片數(shù)量多時(shí)一次刷新耗時(shí)接近 300ms而 Timer 每隔 200ms 就觸發(fā)一次等于 UI 線程永遠(yuǎn)在趕場(chǎng)。解決把“數(shù)據(jù)更新”和“界面渲染”徹底分層。Tick 事件里只改 GameData 數(shù)據(jù)RenderBoard 統(tǒng)一放在 uiRefreshInterval 控制下實(shí)測(cè)將刷新頻率降到 2 秒一次并把 PictureBox 的 DoubleBuffered 屬性設(shè)為 true界面卡死問(wèn)題完全消失。5.2 收益翻倍重復(fù)創(chuàng)建 Timer 沒(méi)釋放舊實(shí)例現(xiàn)象玩著玩著金幣增速突然變快打開(kāi)日志發(fā)現(xiàn) UpdateIncome 被執(zhí)行了兩次甚至三次。原因?qū)崿F(xiàn)“重新開(kāi)始游戲”功能時(shí)代碼里直接 new 了一個(gè) Timer 再 Start但沒(méi)有 Stop 和 Dispose 舊 Timer。舊實(shí)例還在 Tick 事件里繼續(xù)驅(qū)動(dòng) UpdateIncome新舊兩個(gè) Timer 同時(shí)在跑收益結(jié)算被重復(fù)執(zhí)行。解決新開(kāi)一局前強(qiáng)制執(zhí)行一次gameTimer?.Stop(); gameTimer?.Dispose();再 new 新實(shí)例。從那以后我每次寫(xiě)帶 Timer 的游戲都會(huì)養(yǎng)成習(xí)慣只要出現(xiàn)“重新開(kāi)始”“切換場(chǎng)景”這類(lèi)邏輯第一步永遠(yuǎn)是清理舊的定時(shí)器這個(gè)習(xí)慣幫我省了無(wú)數(shù)次排查時(shí)間。5.3 坐標(biāo)偏差固定行列在窗體縮放后全部錯(cuò)位現(xiàn)象窗口默認(rèn)大小時(shí)點(diǎn)擊正常把窗口拉大后點(diǎn)擊格子響應(yīng)的是旁邊甚至對(duì)角線的車(chē)位。原因初始化時(shí)把格子寬高寫(xiě)死成了默認(rèn)窗口對(duì)應(yīng)的尺寸Resize 后 PictureBox 被 TableLayoutPanel 自動(dòng)拉伸但點(diǎn)擊事件里記錄的車(chē)位索引仍然按初始化時(shí)的順序排列。其實(shí)這個(gè)方案本身沒(méi)有錯(cuò)錯(cuò)的是格子尺寸沒(méi)有跟著重算。解決改用控件數(shù)組方案后把 cellW 和 cellH 的計(jì)算放在 Resize 事件里每次窗體尺寸變化都重新計(jì)算。代碼上只加了幾行但從此坐標(biāo)偏移的問(wèn)題再?zèng)]出現(xiàn)。如果堅(jiān)持用坐標(biāo)手動(dòng)算行列還需要額外減去 Panel 的 Padding 和 Border 寬度那個(gè)組合就是玄學(xué)中的玄學(xué)。5.4 貼條與拖車(chē)同時(shí)生效AI 把玩家打到倒欠金幣現(xiàn)象玩家車(chē)輛先被貼條緊接著又被拖走兩者罰金疊加玩家金幣直接變負(fù)游戲數(shù)值崩壞。原因TryTicket 和 TryTow 都只檢查了車(chē)輛是否存在沒(méi)有互斥檢查。貼條之后車(chē)還在原車(chē)位拖車(chē)邏輯又把它判定為“可拖對(duì)象”兩套罰金疊在一起扣。解決在 TryTow 開(kāi)頭加上if (space.HasTicket) return false;明確貼條和拖車(chē)是互斥動(dòng)作。規(guī)則上貼條后的車(chē)不能被拖這樣罰金只有一筆玩家損失可預(yù)期AI 的連招懲罰也不會(huì)顯得“不講道理”。5.5 讀檔后時(shí)間錯(cuò)亂DateTime 直接序列化導(dǎo)致收益上限失效現(xiàn)象昨晚存檔時(shí)車(chē)才停了 5 分鐘今天打開(kāi)繼續(xù)車(chē)子的收益直接變成 0顯示已到上限。原因存檔時(shí)把 ParkedAt 按 DateTime 序列化讀檔后 DateTime.Now 減去存檔里的 ParkedAt得到的是包含整個(gè)離線時(shí)間段的差值遠(yuǎn)超收益上限系統(tǒng)理所當(dāng)然地認(rèn)為收益已經(jīng)停發(fā)。解決存檔時(shí)不要存 ParkedAt而是存累計(jì)停車(chē)秒數(shù)。讀檔后重建 ParkedAtspace.ParkedAt DateTime.Now.AddSeconds(-space.ParkedElapsedSeconds);這樣離線時(shí)間不會(huì)混入收益時(shí)長(zhǎng)。另一個(gè)坑是 DateTime 在 JSON 里默認(rèn)序列化成帶時(shí)區(qū)的 UTC 字符串讀檔回來(lái)如果不轉(zhuǎn)換成當(dāng)?shù)貢r(shí)間差值也會(huì)錯(cuò)建議統(tǒng)一用 DateTimeOffset 或者干脆在存檔類(lèi)里全用 Unix 時(shí)間戳。6. 越玩越像樣JSON 存檔、車(chē)位升級(jí)與數(shù)值平衡技巧6.1 用 System.Text.Json 做存檔注意版本兼容存檔是課程設(shè)計(jì)里最容易拿加分也最容易丟分的點(diǎn)。資源里沒(méi)有用復(fù)雜的二進(jìn)制格式就是 System.Text.Json 直接序列化 GameData 對(duì)象public void SaveGame(GameData data, string filePath) { var options new JsonSerializerOptions { WriteIndented true, Converters { new JsonStringEnumConverter() } }; var json JsonSerializer.Serialize(data, data.GetType(), options); File.WriteAllText(filePath, json); } public GameData LoadGame(string filePath) { var json File.ReadAllText(filePath); var data JsonSerializer.DeserializeGameData(json); return data; }因?yàn)樗袑?shí)體類(lèi)都是普通對(duì)象序列化不需要額外標(biāo)記。如果以后給類(lèi)加了新字段建議在存檔里加一個(gè) version 字段讀檔時(shí)判斷版本做字段補(bǔ)默認(rèn)值避免舊存檔直接反序列化報(bào)錯(cuò)。這個(gè) version 字段不用參與游戲邏輯只在存檔類(lèi)里額外掛一個(gè)屬性就行。6.2 貼條罰金別寫(xiě) 100%一個(gè)保底公式數(shù)值平衡是整個(gè)單機(jī)版能“玩得下去”的底線。貼條罰金如果設(shè)為當(dāng)前累計(jì)收益的 100%玩家停滿(mǎn)半小時(shí)被貼一次條直接歸零挫敗感強(qiáng)到想刪游戲。資源里的處理方式是 50% 加固定保底int fine (int)(car.AccIncome * 0.5) 20;這樣收益低的階段貼條也有 20 金幣保底收益AI 不會(huì)因?yàn)橥婕臆?chē)上的錢(qián)少而懶得貼條收益高的時(shí)候罰金不會(huì)超過(guò)收入的一半玩家的損失可接受也有動(dòng)力繼續(xù)經(jīng)營(yíng)。拖車(chē)罰金用 80% 而不是 100%也是同樣的道理——拖車(chē)是最強(qiáng)的懲罰手段但直接清零會(huì)讓玩家覺(jué)得“這個(gè)游戲不講道理”。車(chē)位升級(jí)的數(shù)值設(shè)計(jì)也是同理每升一級(jí)花費(fèi)是當(dāng)前等級(jí)金幣的 1.8 倍收益加成只加 10%。這個(gè)曲線保證前期升級(jí)便宜、收益提升明顯后期升級(jí)貴但在玩家可負(fù)擔(dān)范圍內(nèi)。整個(gè)升級(jí)系統(tǒng)給了玩家一個(gè)消耗金幣的出口不然游戲進(jìn)行 20 分鐘后金幣溢出所有懲罰都變得不痛不癢。說(shuō)到車(chē)位升級(jí)順手分享一個(gè)我自己的習(xí)慣每次調(diào)試數(shù)值平衡我都會(huì)強(qiáng)制走一遍“新號(hào)開(kāi)局 10 分鐘、掛機(jī) 1 小時(shí)、AI 困難檔”三個(gè)狀態(tài)的完整流程觀察金幣曲線和玩家挫敗感。這個(gè)項(xiàng)目我拆完后也重跑了一遍貼條保底公式就是從那輪調(diào)試?yán)锟吹降摹P金低于 20 金幣檔位AI 貼條熱情明顯下降。以后再做這類(lèi)模擬經(jīng)營(yíng)小游戲我應(yīng)該都會(huì)先拿這三檔流程測(cè)試一遍再交出去。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取