簡介面向Java游戲開發(fā)入門者與計算機專業(yè)學生的回合制游戲源碼包圍繞輪流行動機制拆解戰(zhàn)斗流程、角色建模與面向對象設計。內容以管理器類統(tǒng)籌回合調度、狀態(tài)更新和輸入處理士兵類承載生命值、攻擊力、防御力及攻防移動等行為Boss類在此基礎上擴展高血量、特殊技能與階段變化并涉及工廠、策略、狀態(tài)等設計模式的落地思路同時可參考Git、IDE、Maven/Gradle與JUnit等工具鏈組織代碼和驗證邏輯。壓縮包為rar格式體積約1KB文件總數(shù)記錄為0類型明細暫未提供下載前可留意包體完整性。已有1016人學習適合通過小體量示例理解回合制游戲的核心骨架、角色繼承關系與Boss AI擴展方式并為后續(xù)補充完整工程、練習單元測試和梳理類職責劃分提供切入點。1. 回合制游戲源碼不是那段 while 循環(huán)先看清這套包里真正值錢的四層結構很多人拿到回合制游戲源碼第一反應是改數(shù)值、換皮、加兩個技能結果戰(zhàn)斗能跑一加 Buff 就崩一斷線重連就錯位。這套包真正有價值的不是主循環(huán)那幾十行而是把行動隊列、效果結算、配置導表、回放校驗拆成了四層可替換模塊源碼和配套工具都能單獨拎出來用。它適合想快速搭出可維護戰(zhàn)斗框架的獨立開發(fā)者也適合接手老項目、需要把「玄學戰(zhàn)斗」拆開看的人。2. 戰(zhàn)斗狀態(tài)機怎么落地從行動隊列到結算的四個關鍵類回合制戰(zhàn)斗看起來簡單寫起來很容易變成一個巨大的while誰先動、放什么技能、傷害多少、什么時候播動畫全塞在一個函數(shù)里。項目小的時候沒事一旦加入追擊、反擊、延遲傷害、Buff 到期結算這個循環(huán)就會變成一團解不開的線。這套源碼的處理方式是把「戰(zhàn)斗」拆成一個可暫停的狀態(tài)機加一條按行動值排序的隊列再配一個只產(chǎn)出事件、不碰表現(xiàn)的效果結算器。下面按「為什么這么設計 → 類怎么分 → 一次普攻怎么走完 → 參數(shù)怎么調」四步拆。2.1 為什么回合制要用「事件驅動 隊列」而不是 while 循環(huán)while循環(huán)的問題不在于性能而在于它把三件本該分開的事綁死了邏輯推進、玩家輸入、動畫播放?；睾现茟?zhàn)斗天然要等——等玩家選技能、等動畫播完、等服務器確認。用循環(huán)寫就只能靠回調或者協(xié)程硬掰掰到最后沒人說得清一次傷害到底在哪一行算的。事件驅動的做法是反過來的結算階段只做純計算把「誰對誰造成了多少傷害、觸發(fā)了什么效果」寫成一條條事件塞進一個事件列表表現(xiàn)層再從這個列表里取事件決定播什么動畫、彈什么字。這樣做有三個直接好處。第一服務器可以只跑邏輯、不跑動畫同一份代碼在小霸王服務器上也能算出結果。第二斷線重連只需要把事件列表重放一遍不需要保存每一幀的動畫狀態(tài)。第三回放和戰(zhàn)報是同一套數(shù)據(jù)不用另寫一套日志。隊列解決的是「誰先動」的問題。最土的辦法是每回合按速度排序一次但這樣處理不了「行動值」類的機制——速度快的單位在兩回合之間多動一次、被減速后行動條回退、某些技能強行插隊。用行動值隊列每個單位持有一個action_value每次行動后按BASE / speed重新累加隊列按值從小到大取插隊只需要臨時改一下這個值或者給一個更高的優(yōu)先級。這套模型能覆蓋絕大多數(shù)回合制變體改起來也只動一個數(shù)字。注意事件列表必須是「只追加、不修改」的。一旦允許結算過程中回頭改已經(jīng)產(chǎn)出的事件回放就一定對不上而且這種 bug 極難復現(xiàn)。2.2 核心類的職責劃分與最小可運行骨架這套源碼把戰(zhàn)斗拆成六個角色每個角色只干一件事邊界清楚到可以直接替換實現(xiàn)。模塊職責明確不該做的事BattleContext持有單位表、隊列、隨機源、事件列表、當前階段不寫具體傷害公式Unit單位屬性、Buff 容器、技能列表、當前行動值不直接改別的單位ActionQueue按行動值排序、取出、重新入隊、插隊不判斷技能是否合法EffectResolver把技能配置翻譯成一系列效果并結算不碰動畫和 UIEventBus收集結算事件供表現(xiàn)層和回放消費不做業(yè)務判斷RandomService帶種子的確定性隨機按固定順序消費不在表現(xiàn)層被調用這里最容易寫歪的是Unit。很多人習慣讓單位自己算傷害、自己找目標結果單位之間互相引用測試一個技能要造一整個戰(zhàn)場。正確的做法是單位只暴露屬性和 Buff 查詢接口所有「打誰、打多少」都由EffectResolver拿著上下文來算。這樣寫單測時造兩個假單位、一個假隨機源就能跑不需要啟動整個戰(zhàn)斗。RandomService單獨拎出來是血淚經(jīng)驗。隨機數(shù)一旦散落在各個類里回放就會因為調用順序不同而漂移。統(tǒng)一到一個帶種子的隨機源所有命中、暴擊、Buff 概率都從它取順序固定回放才能一比一還原。骨架大概長這樣核心是tick只推進一個階段不包辦所有事# battle/engine.py from dataclasses import dataclass, field from enum import Enum class Phase(Enum): WAIT_INPUT 1 # 等玩家指令或 AI 決策 RESOLVING 2 # 純邏輯結算禁止碰表現(xiàn) ANIMATING 3 # 客戶端按事件列表播表現(xiàn) FINISHED 4 dataclass class BattleContext: units: dict # unit_id - Unit queue: ActionQueue rng: RandomService events: list field(default_factorylist) phase: Phase Phase.WAIT_INPUT round_no: int 0 # 大回合計數(shù)僅用于展示和部分 Buff def tick(ctx: BattleContext): 每次調用只推進一步調用方?jīng)Q定節(jié)奏。 if ctx.phase is not Phase.RESOLVING: return actor ctx.queue.pop() if actor is None: ctx.phase Phase.FINISHED return action actor.take_action(ctx) # 玩家指令或 AI 決策 for event in action.execute(ctx): # 結算器只產(chǎn)出事件 ctx.events.append(event) ctx.queue.push_back(actor) # 按行動值重新入隊 ctx.phase Phase.ANIMATING # 交給表現(xiàn)層消費事件這段代碼的關鍵點不在語法而在三個約束。tick一次只處理一個行動者調用方可以是服務器定時器也可以是客戶端協(xié)程節(jié)奏完全解耦。action.execute返回事件而不是直接改狀態(tài)保證了結算過程可記錄、可重放。phase顯式區(qū)分結算和表現(xiàn)避免有人在結算階段去讀動畫進度。參數(shù)上round_no只在所有單位都行動過一次后加一不要用「隊列走一圈」來算否則插隊會打亂回合計數(shù)。2.3 把一次普攻拆成七個結算階段一次普通攻擊看著就是「扣血」實際要經(jīng)過前置校驗、目標選取、命中判定、暴擊判定、傷害計算、效果附加、死亡結算七步。每一步都可以被 Buff 修改所以必須拆開寫不能一行公式糊過去。下面這段是簡化后的實現(xiàn)保留了階段劃分和事件產(chǎn)出# battle/effect.py def resolve_attack(ctx, caster, target, skill): events [] # 1. 前置校驗沉默、眩暈、目標已死亡都直接返回 if not caster.can_act() or target.is_dead(): return events # 2. 目標選取單體技能直接鎖目標群體技能在調用方展開 if skill.target_type single and target is None: return events # 3. 命中判定命中率減去目標閃避結果裁剪到 [0.05, 0.95] hit_rate clamp(caster.hit - target.dodge, 0.05, 0.95) if ctx.rng.next_float() hit_rate: events.append(Event(miss, castercaster.id, targettarget.id)) return events # 4. 暴擊判定暴擊率同樣要裁剪避免出現(xiàn)必暴或永不暴 crit ctx.rng.next_float() clamp(caster.crit, 0.0, 1.0) # 5. 傷害計算走獨立函數(shù)方便單測和數(shù)值調整 damage calc_damage(caster, target, skill, crit) # 6. 效果附加技能攜帶的 Buff、持續(xù)傷害、驅散都在這里掛 for effect in skill.effects: effect.apply(ctx, caster, target, events) # 7. 死亡結算統(tǒng)一在這里判死避免每個效果各寫一遍 target.hp - damage events.append(Event(damage, castercaster.id, targettarget.id, valuedamage, critcrit)) if target.hp 0: target.hp 0 events.append(Event(death, targettarget.id)) return events七個階段的順序不能隨便換。命中在暴擊之前是因為「未命中就不該消耗暴擊隨機數(shù)」——這個細節(jié)直接決定回放能不能對上。效果附加放在傷害之后是為了讓「受到傷害時觸發(fā)」的 Buff 能讀到正確的血量。死亡結算統(tǒng)一放在最后避免一個 AOE 里第一個目標死了、后面的效果還在給尸體加 Buff。參數(shù)上有三個地方最容易翻車。hit_rate的下限不能設成 0否則高閃避單位會變成無敵上限不能設成 1否則命中屬性堆滿后戰(zhàn)斗失去懸念。暴擊率同理裁剪區(qū)間建議[0, 1]但在配置層限制投放。calc_damage里所有中間結果用整數(shù)或者定點數(shù)浮點數(shù)在客戶端和服務器上可能因為編譯優(yōu)化產(chǎn)生末位差異回放對不上時第一個要懷疑的就是這里。2.4 行動值、速度與插隊規(guī)則怎么定行動值模型的核心公式只有一個action_value BASE / speed。BASE取 10000 是個經(jīng)驗值能讓速度 80 到 200 的單位都有足夠的區(qū)分度又不至于讓行動值小數(shù)位太多。每次單位行動完把它的action_value重新設為BASE / speed隊列按值升序取最小值。速度 100 的單位每 100 點行動值動一次速度 200 的單位每 50 點動一次兩回合里多動一次符合直覺。插隊規(guī)則建議只用兩種優(yōu)先級插隊和行動值插隊。優(yōu)先級插隊給「必定先手」這類技能用實現(xiàn)上是在隊列里臨時插入一個priority1的節(jié)點取的時候先比優(yōu)先級再比行動值。行動值插隊給「推條」「拉條」用直接改目標或自己的action_value改完重新排序。不要引入第三種插隊方式否則行動順序會變成沒人能預測的黑匣子。還有一個容易被忽略的參數(shù)同值排序。兩個單位行動值完全相同時必須有一個穩(wěn)定的兜底規(guī)則常見做法是先比速度再比隊伍位次最后用戰(zhàn)斗種子派生一個固定隨機數(shù)。順序一旦確定就不能改改了之后所有歷史回放都會錯位。3. 數(shù)值與技能配置Excel 表怎么變成運行時可用的數(shù)據(jù)戰(zhàn)斗邏輯寫完之后真正拖慢迭代的是配置。策劃改一個技能倍率程序要重新導表、重啟客戶端、重新打一場一天下來改不了幾個數(shù)。這套源碼配了一套導表工具把 Excel 拆成技能、效果、Buff 三張表導出成 JSON 加二進制兩份運行時熱重載。下面講表結構怎么設計、導表腳本怎么寫、熱重載怎么保證不串場。3.1 技能、效果、Buff 三張表的關系很多人把技能和效果寫在一張表里結果一個技能帶三段傷害就要加三列加第四段就得改代碼。正確的拆法是三層技能表描述「誰、在什么條件下、放什么」效果表描述「具體做什么」Buff 表描述「持續(xù)多久、疊幾層、什么時候觸發(fā)」。技能表的關鍵字段字段類型說明skill_idint主鍵全局唯一不要復用target_typeenumsingle / all_enemy / all_ally / selfeffect_idsint[]按順序執(zhí)行的效果 ID 列表costint消耗的行動值或資源cooldownint冷卻回合數(shù)0 表示無冷卻priorityint插隊優(yōu)先級默認 0效果表的核心是effect_type常見取值有damage、heal、add_buff、remove_buff、dispel、summon。每種類型對應一組參數(shù)字段用 JSON 存額外參數(shù)比開一堆空列更好維護。Buff 表則要寫清max_stack、stack_policy疊加、刷新、獨立、duration、trigger_timing行動前、行動后、受傷時、死亡時。三張表的關系是技能引用效果效果可以引用 BuffBuff 不反向引用技能。這條單向依賴很重要它保證了改 Buff 不會影響技能表的解析也保證了導表時可以用拓撲順序校驗外鍵。3.2 導表腳本從 xlsx 到 json 的轉換與校驗導表工具最怕的是「導出來了但導錯了」。所以腳本不能只做格式轉換必須帶校驗必填字段為空直接報錯、外鍵找不到直接報錯、枚舉值不在白名單直接報錯、數(shù)值超出策劃約定的區(qū)間給警告。下面是一個最小可用的版本# tools/export_config.py import json import openpyxl REQUIRED { skill: [skill_id, target_type, effect_ids], effect: [effect_id, effect_type], buff: [buff_id, duration, max_stack], } ENUMS { target_type: {single, all_enemy, all_ally, self}, effect_type: {damage, heal, add_buff, remove_buff}, } def load_sheet(path, sheet_name): wb openpyxl.load_workbook(path, data_onlyTrue) ws wb[sheet_name] rows list(ws.iter_rows(values_onlyTrue)) header rows[0] return [dict(zip(header, row)) for row in rows[1:] if row[0] is not None] def validate(table_name, rows, id_set): errors [] for i, row in enumerate(rows, start2): for field in REQUIRED[table_name]: if row.get(field) in (None, ): errors.append(f{table_name} 第 {i} 行缺少 {field}) for field, allowed in ENUMS.items(): if field in row and row[field] not in allowed: errors.append(f{table_name} 第 {i} 行 {field}{row[field]} 非法) if table_name skill: for eid in row.get(effect_ids, []): if eid not in id_set[effect]: errors.append(f技能 {row[skill_id]} 引用不存在的效果 {eid}) return errors def export(xlsx_path, out_dir): skills load_sheet(xlsx_path, skill) effects load_sheet(xlsx_path, effect) buffs load_sheet(xlsx_path, buff) id_set { effect: {r[effect_id] for r in effects}, buff: {r[buff_id] for r in buffs}, } errors [] for name, rows in ((skill, skills), (effect, effects), (buff, buffs)): errors validate(name, rows, id_set) if errors: raise SystemExit(\n.join(errors)) # 有錯就不出包避免臟數(shù)據(jù)進運行時 for name, rows in ((skill, skills), (effect, effects), (buff, buffs)): with open(f{out_dir}/{name}.json, w, encodingutf-8) as f: json.dump(rows, f, ensure_asciiFalse, indent2)這段腳本的校驗邏輯比轉換邏輯更重要。REQUIRED保證必填字段不為空空值進到運行時往往表現(xiàn)為「技能放出來沒反應」排查成本極高。ENUMS把拼寫錯誤擋在導表階段all_enemies和all_enemy這種差異靠人眼是看不出來的。外鍵校驗放在最后統(tǒng)一做是因為技能表可能先于效果表加載邊加載邊校驗會誤報。參數(shù)上data_onlyTrue必須加否則讀到的是公式而不是計算值。id_set要在三張表都加載完之后再構建避免順序依賴。導出格式選 JSON 是為了可讀和便于 diff真到包體敏感的階段可以再加一份二進制但 JSON 要保留出問題時靠它定位。3.3 熱重載雙緩沖、版本號和失敗回滾熱重載最容易出的問題是「改到一半讀到半份配置」。這套源碼的做法是雙緩沖加版本號新配置先加載到一個獨立的字典里全部校驗通過后原子替換當前引用同時把版本號加一。正在進行的戰(zhàn)斗持有舊版本引用新戰(zhàn)斗拿新版本互不干擾。具體實現(xiàn)上ConfigRepository對外只暴露get_skill(skill_id)這樣的查詢方法內部持有current和pending兩個字典。重載時先填pending校驗通過后執(zhí)行current, pending pending, current。引用計數(shù)用來決定舊版本什么時候真正釋放每場戰(zhàn)斗開始時retain()結束時release()計數(shù)歸零才回收。這樣即使重載時正好有戰(zhàn)斗在跑也不會出現(xiàn)「技能放到一半配置沒了」。失敗回滾同樣重要。校驗不通過時pending直接丟棄current不受影響同時把錯誤寫進日志并推給導表工具。不要讓「加載失敗」變成「運行時靜默使用空配置」后者會表現(xiàn)成所有技能傷害為 0比直接報錯難查十倍。提示熱重載只適用于配置數(shù)據(jù)不要用它熱更戰(zhàn)斗邏輯代碼。邏輯和配置的生命周期不一樣混在一起會讓回放版本徹底失控。3.4 傷害公式的參數(shù)化寫法傷害公式建議寫成「基礎值 × 技能倍率 固定值再乘一系列修正」每個修正單獨一個函數(shù)方便單獨測試和單獨開關。常見的形式是def calc_damage(caster, target, skill, crit): base caster.atk * skill.ratio skill.flat # 防御減傷用除法而不是減法避免高防單位完全免傷 defense_factor 1000 / (1000 target.def) element_factor ELEMENT_TABLE.get((skill.element, target.element), 1.0) crit_factor 1.5 if crit else 1.0 raw base * defense_factor * element_factor * crit_factor # 統(tǒng)一取整最小傷害保底 1避免出現(xiàn) 0 傷害的觀感問題 return max(1, int(raw))defense_factor用除法是這套源碼和很多手寫項目的關鍵差別。減法減傷在高防單位身上會直接歸零戰(zhàn)斗變成「誰防高誰贏」除法減傷是漸進曲線防御再高也不會完全免傷數(shù)值上限可控。1000這個常數(shù)決定減傷曲線的陡峭程度防御堆到 1000 時減傷 50%堆到 3000 時減傷 75%適合大部分中等數(shù)值規(guī)模的回合制。ELEMENT_TABLE用字典存克制關系鍵是「攻擊屬性、防御屬性」的二元組值是倍率。不要用一長串 if-else屬性一多就沒法維護。crit_factor固定 1.5 是常見做法但如果項目有暴擊傷害屬性應該改成1.5 caster.crit_damage并且同樣做區(qū)間裁剪。取整放在最后一步、只取一次是所有數(shù)值計算的紅線。中間步驟各自取整會導致誤差累積客戶端和服務器算出來的結果差一點回放就會在某個回合開始漂移。4. 客戶端表現(xiàn)與服務器校驗同一場戰(zhàn)斗怎么兩邊算得一樣單機回合制怎么算都行一旦涉及聯(lián)網(wǎng)問題就變成「客戶端算的和服務器算的不一致怎么辦」。這套源碼的答案是邏輯只有一份表現(xiàn)是邏輯的投影服務器不相信客戶端傳來的任何結果只相信指令。下面講分離方式、確定性隨機、回放重連和校驗點設計。4.1 邏輯與表現(xiàn)分離事件流是唯一的橋梁戰(zhàn)斗邏輯跑完之后產(chǎn)出的是一串事件客戶端拿到事件之后做三件事查表、播動畫、更新 UI。這個過程中客戶端不能回頭改邏輯狀態(tài)也不能自己算傷害。所有數(shù)值都從事件里讀事件里沒有的就是不需要表現(xiàn)的。這樣做的好處是客戶端可以「演」得比服務器慢。服務器一次性算完整個回合客戶端按事件順序慢慢播玩家看到的是動畫服務器看到的是結果。中間如果玩家斷線重連時服務器把事件流重新發(fā)一遍客戶端從頭播或者從快照接著播邏輯狀態(tài)不會丟。實現(xiàn)上事件要帶足夠的信息不能只帶「傷害 100」。至少要帶施法者 ID、目標 ID、數(shù)值、是否暴擊、技能 ID、效果類型?？蛻舳烁鶕?jù)這些字段決定播哪個特效、彈什么數(shù)字、要不要震屏。事件里不要塞指針或者對象引用必須是可序列化的純數(shù)據(jù)否則回放和網(wǎng)絡傳輸都會出問題。4.2 確定性隨機種子、消費順序和禁止跨層調用回放對不上的頭號原因是隨機數(shù)。兩個客戶端用同樣的種子但調用次數(shù)不一樣結果就完全不同。解決辦法有三條所有隨機走同一個RandomService隨機的消費順序在邏輯層固定表現(xiàn)層禁止調用隨機。隨機算法本身用哪個不重要LCG、xorshift、PCG 都可以重要的是可復現(xiàn)。下面是一個最簡的 xorshift 實現(xiàn)夠用且快# battle/random.py class RandomService: def __init__(self, seed: int): self.state seed 0xFFFFFFFF or 1 # 種子不能為 0 def next_u32(self) - int: x self.state x ^ (x 13) 0xFFFFFFFF x ^ (x 17) x ^ (x 5) 0xFFFFFFFF self.state x 0xFFFFFFFF return self.state def next_float(self) - float: # 除以 2^32結果落在 [0, 1) return self.next_u32() / 4294967296.0 def next_int(self, low: int, high: int) - int: # 閉區(qū)間注意 high - low 1 不能為 0 return low self.next_u32() % (high - low 1)state不能為 0 是 xorshift 的硬性要求種子為 0 時整個序列恒為 0表現(xiàn)為「所有隨機都失敗」。next_float用除法而不是取模是為了避免低位周期性問題。next_int用取模會有極其輕微的分布偏差回合制里可以忽略如果介意可以換成拒絕采樣。消費順序上建議在戰(zhàn)斗開始時就把「本場戰(zhàn)斗的隨機種子」寫進戰(zhàn)斗記錄所有隨機都從這個種子派生。命中、暴擊、Buff 觸發(fā)、掉落各用一個獨立的子種子互相不影響。這樣即使某個版本多消耗了一次暴擊隨機也不會把后面的掉落全部打亂。4.3 戰(zhàn)斗回放與斷線重連回放的本質是「種子 指令序列」。戰(zhàn)斗開始時記錄種子和雙方陣容之后每次玩家或 AI 做出決策就把指令追加到列表里?；胤艜r新建一個戰(zhàn)斗上下文用同樣的種子、同樣的陣容按順序喂指令跑出來的事件流應該和原始戰(zhàn)斗完全一致。斷線重連比重放簡單一點但要求更快。常見做法是服務器每隔幾個回合存一個快照快照里包含所有單位的血量、Buff、行動值、隨機源狀態(tài)。玩家重連時服務器發(fā)最近一個快照加上之后的指令列表客戶端從快照恢復再重放不用從第一回合開始。# battle/replay.py def replay(seed, lineup, commands, snapshotNone): ctx BattleContext.new(seedseed, lineuplineup) if snapshot: ctx.restore(snapshot) # 恢復到最近快照 for cmd in commands: ctx.apply_command(cmd) # 指令驅動不是直接改狀態(tài) while ctx.phase is Phase.RESOLVING: tick(ctx) ctx.phase Phase.RESOLVING return ctx.eventscommands里存的必須是「玩家選了什么技能、打誰」這種決策而不是「造成了多少傷害」這種結果。存結果的話一旦公式調整歷史回放全部失效存決策的話公式改了回放會算出新結果但這反而方便對比版本差異。snapshot里的隨機源狀態(tài)必須包含否則重放時隨機序列會從頭開始和原始戰(zhàn)斗對不上。4.4 校驗點設計哪些數(shù)據(jù)必須服務器復核服務器不能相信客戶端的任何計算結果但也不需要每一步都重算。合理的做法是客戶端上報指令服務器用同一份邏輯跑一遍然后比對關鍵校驗點。校驗點是否必須說明行動順序必須客戶端改順序是最常見的作弊方式技能合法性必須冷卻、消耗、目標是否存活傷害數(shù)值必須允許極小誤差超出即判定異常隨機結果建議命中、暴擊由服務器種子決定Buff 層數(shù)必須層數(shù)錯了后續(xù)全錯配置版本必須版本不一致直接拒絕戰(zhàn)斗比對時不要用浮點數(shù)相等用整數(shù)或者定點數(shù)并且允許配置層面的容差。出現(xiàn)不一致時服務器以自己算的為準同時記錄一條異常日志日志里帶上種子、指令序列和雙方版本號方便事后復現(xiàn)。5. 避坑與排查五個讓戰(zhàn)斗「看起來能跑」卻上線翻車的問題下面這五個問題每一個都曾經(jīng)讓一套看起來跑得好好的戰(zhàn)斗在真機上翻車。共同點是本地測試很難復現(xiàn)線上日志又不夠用。每條按「現(xiàn)象 → 原因 → 解決」寫方便對照排查。5.1 現(xiàn)象同樣的陣容兩次戰(zhàn)斗結果不一樣原因隨機源沒有統(tǒng)一或者隨機的消費順序依賴了字典遍歷順序。Python 3.7 之后字典有序但很多項目從別的語言遷過來習慣性用set或者無序容器遍歷每次順序都可能不同隨機數(shù)就被消耗到了不同的地方。解決所有涉及隨機的循環(huán)先把候選目標按unit_id排序再遍歷。隨機源只允許在邏輯層調用表現(xiàn)層的粒子、音效、飄字抖動一律用不依賴戰(zhàn)斗結果的偽隨機。排查時在每次隨機調用處打一條日志帶上調用點和消耗后的狀態(tài)兩次戰(zhàn)斗 diff 一下就能定位。5.2 現(xiàn)象Buff 到期后屬性沒還原原因Buff 加屬性時直接改了unit.atk到期時減回去但中間如果發(fā)生了「按當前攻擊力重新計算」的邏輯減回去的數(shù)值就不對了。更隱蔽的情況是 Buff 疊加時加了一次、到期時按層數(shù)減了多次。解決屬性不要直接改改成「基礎值 修正列表」的計算屬性。每個 Buff 持有一個修正項讀屬性時實時求和Buff 移除時把修正項摘掉天然不會算錯。這套源碼里Unit的atk是個 property內部遍歷modifiers求和改起來麻煩一點但省掉了后面所有的還原邏輯。5.3 現(xiàn)象技能連攜時傷害少算一次原因效果結算用了「邊遍歷邊修改」的列表。比如技能 A 命中后觸發(fā)被動 BB 又往效果列表里追加了一個效果而遍歷用的是for effect in effects新追加的項不會被處理或者在某些語言里直接拋異常。解決結算用一個顯式的效果隊列處理完一個就 pop 一個新效果追加到隊尾。隊列空之前一直循環(huán)并且設一個最大迭代次數(shù)比如 100防止無限連鎖。最大次數(shù)這個參數(shù)很重要沒有它兩個互相觸發(fā)的被動能把服務器跑死。5.4 現(xiàn)象熱重載后舊戰(zhàn)斗讀不到新配置原因熱重載直接替換了全局配置字典正在跑的戰(zhàn)斗持有的是舊引用但某些查詢走的是全局單例于是同一場戰(zhàn)斗里前半段用舊配置、后半段用新配置。解決戰(zhàn)斗上下文在創(chuàng)建時就把配置倉庫的當前版本引用住整場戰(zhàn)斗只讀這一個版本。重載只影響新創(chuàng)建的戰(zhàn)斗。如果確實需要中途生效必須顯式地結束當前戰(zhàn)斗再重建不要試圖在運行中混用兩個版本。5.5 現(xiàn)象回放對不上日志里找不到原因原因日志只記了結果沒記輸入。傷害對不上時只能看到「打了 100」看不到當時的攻擊力、防御、Buff 層數(shù)、隨機值。解決每條傷害事件都把參與計算的中間值帶上至少包括攻擊、防御、技能倍率、各類修正、隨機數(shù)。日志按戰(zhàn)斗 ID 聚合回放時用同樣的種子重跑逐條比對事件。這套源碼里事件結構體留了debug字段線上關掉、內網(wǎng)打開排查效率差好幾個數(shù)量級。6. 用工具把驗證成本壓下來批量模擬腳本與驗收清單戰(zhàn)斗邏輯寫到能跑只是完成了一半。真正決定上線質量的是「改一個數(shù)值能不能在十分鐘內知道它有沒有把平衡性搞崩」。這套源碼附帶的批量模擬工具就是干這個的不起客戶端、不播動畫直接跑邏輯統(tǒng)計勝率和回合數(shù)分布。6.1 批量模擬一萬場戰(zhàn)斗跑出勝率分布模擬腳本的關鍵是「無表現(xiàn)、可并行、結果可聚合」。下面這個版本跑 N 場相同陣容的對戰(zhàn)統(tǒng)計勝率和平均回合數(shù)用來快速判斷一次數(shù)值改動的影響# tools/simulate.py from collections import Counter from battle.engine import BattleContext, tick, Phase def run_one(seed, lineup_a, lineup_b): ctx BattleContext.new(seedseed, lineup_alineup_a, lineup_blineup_b) ctx.phase Phase.RESOLVING steps 0 while ctx.phase is not Phase.FINISHED and steps 500: tick(ctx) steps 1 winner ctx.winner() # 0 平局1 左勝2 右勝 return winner, ctx.round_no def simulate(n10000, lineup_aNone, lineup_bNone): counter Counter() rounds [] for seed in range(1, n 1): winner, r run_one(seed, lineup_a, lineup_b) counter[winner] 1 rounds.append(r) total sum(counter.values()) print(f左勝率 {counter[1] / total:.2%}右勝率 {counter[2] / total:.2%} f平局 {counter[0] / total:.2%}) print(f平均回合數(shù) {sum(rounds) / len(rounds):.1f} f最長 {max(rounds)}最短 {min(rounds)}) if __name__ __main__: simulate(n10000)steps 500是死循環(huán)保護沒有它兩個高回復單位能把腳本跑到天荒地老。winner的判定要放在ctx里不要在腳本里臨時判斷否則模擬結果和線上不一致。種子從 1 遞增而不是隨機是為了保證每次跑出來的結果可復現(xiàn)改完數(shù)值前后對比才有意義。跑完之后看三個數(shù)勝率偏離 50% 太多說明陣容或數(shù)值有明顯傾斜平均回合數(shù)突然變長說明出現(xiàn)了拖回合的組合最長回合數(shù)逼近上限說明有無限循環(huán)的風險。這三個信號比單看一場戰(zhàn)斗靠譜得多。6.2 上線前的驗收清單檢查項通過標準同種子回放事件流逐條一致無偏差斷線重連從快照恢復后結果與原戰(zhàn)斗一致配置版本客戶端與服務器版本號一致才允許開戰(zhàn)Buff 疊加疊滿、刷新、獨立三種策略各測一遍死亡結算AOE 溢出傷害不作用于已死目標隨機消費命中失敗時不消耗暴擊隨機數(shù)清單里最容易被跳過的是「同種子回放」。本地跑十場都一致不代表沒問題要跑夠一千場并且覆蓋連攜、反擊、復活這些邊緣路徑。這套源碼的回放工具支持從日志文件直接重跑改完邏輯先跑一遍歷史戰(zhàn)斗比重新造場景快得多。我現(xiàn)在改任何一行結算代碼都會先把歷史戰(zhàn)斗日志重放一遍再跑一萬場模擬看勝率曲線有沒有跳變。剛開始覺得這一步多余直到有一次改了個「小優(yōu)化」把暴擊隨機的消費順序挪了一位線上回放全部對不上查了整整兩天。從那以后回放和模擬這兩步就再也沒省過。希望幫到你。本文還有配套的精品資源點擊獲取