07 — Tiến trình & bộ khung Manager

Nguồn: chưng cất từ restore SOT com.Chodun.CatGunner 1.1.59 (BardCat). Mọi C# ở đây là L1 ANALYSIS, không phải source gốc. Prestige/Rebirth có tài liệu riêng: 09-prestige-rebirth.md.

1. Câu hỏi tài liệu này trả lời

Một game idle thương mại là rất nhiều hệ thống nhỏ đan vào nhau: nâng cấp, gacha, pet, relic, skin, nhiệm vụ, xếp hạng, buff, sự kiện hằng ngày. CatGunner tổ chức tất cả bằng 35 singleton X_manager. Tài liệu này mô tả bộ khung đó, các hệ thống tiến trình cốt lõi, và ranh giới rõ ràng giữa gameplay và dịch vụ bên ngoài.

2. Stable truths

2.1 Bộ khung manager

2.2 Nâng cấp (trong vòng chơi)

2.3 Súng: gacha + auto-merge

2.4 Buff, Relic, Skin

2.5 Nhiệm vụ

2.6 Tính toàn vẹn / chống gian lận (NGOÀI PHẠM VI, ghi để nhận diện)

2.7 Ranh giới R1 — dịch vụ ngoài

2.8 Hệ save/load — bản đồ restore đã chứng minh từng field (đợt 3)

Nguồn: [evidence codegen: FIELD_MAP.md] (Hex-Rays dec_ContinueLoad.c 765 dòng + disasm thô, mỗi hàng có trích dẫn), ledger G290–G330. Đây là phần đóng UNKNOWN "cấu trúc SaveData" của §5.

| 6 getter inline là stub (G389 — ĐÃ ĐIỀN đợt 9, G391) — gốc rễ thật của residual ngày tháng: Buff_manager.MoneyBuffTime/PowerBuffTime ⇒ 0f (0x2AE4170/78), FreeCash_manager.LinkRewardReceived/RewardAdRemoved ⇒ false (0x2A6307C/0x2A62158), Time_manager.LastTrustedUtc getter null / setter no-op (0x2AD016C), Time_manager.UtcNow ⇒ default (0x2AD32BC). UtcNow = năm 1 đầu độc SanitizeYear: mọi ngày 2026 lệch ≥ 400 năm ⇒ bị dịch −543 ⇒ bị loại ⇒ default — đó là nguyên nhân thật của residual (1) batch 13 (không phải guard Adventure) và gần chắc của G437 (NewUser_Reload: Today.AddDays(−1) trên DateTime mặc định ⇒ AddTicks ném, InitNewGame dừng giữa chừng trên save mới). Ghi save với UtcNow này sẽ phá 8 field ngày | disasm-proven (đường đọc) | G389, G386 | | Bỏ sót phía ĐỌC trong ContinueLoad (phát hiện nhờ mô hình round-trip, không phải diff nghiệm thu): Lv_Now (dec:418), Mission_StageClear/Rebirth/PlayMine_Value (dec:593-595), Mission_is_Luxury (dec:596), vòng Mission_ExpGet/_Luxury (dec:608-651) — bản đồ 35 field ở §2.8 thiếu các hàng này; một lần ghi trung thực sẽ xoá chúng (StageClear_Value 10 → 0 trên file thật). Phải sửa trước khi bật Save() — đã restore (G391): Monster_manager.Lv_Now, Mission StageClear/Rebirth/PlayMine_Value, Mission_manager.is_Luxury (static, cặp với is_Vip), hai vòng Mission_Exp_Get/_Luxury (chặn theo cả hai độ dài) | disasm-proven | G389, G391 | | Buff bị KẸP khi nạp: Buff_manager.LoadBuffTimes = NEON Clamp(x, 0, 900) (vcltz xoá âm, vbsl/vcgt chặn ở 0x44610000 = 900f) ⇒ save cũ/sửa tay không thể hồi sinh buff vô hạn; trần 15 phút được áp ngay lúc nạp. Bẫy thứ tự tham số: ContinueLoad đọc PowerBuffTime@0x2AC trước MoneyBuffTime@0x2A8 rồi gọi LoadBuffTimes(money, power) — đảo so với thứ tự offset | disasm-proven | G291 | | Danh tính khách được ghi TRƯỚC khi đăng ký: Rank_manager.Login (0x2ABC454) — không có credential thì sinh "user_" + Random.Range(10000000, 99999999) + "@guest.com", mật khẩu Guid.NewGuid().ToString("N").Substring(0, 16), tên "User_" + n, và ghi cả ba vào save tại 0x2ABC7A8/0x2ABC7FC/0x2ABC81C — TRƯỚC lời gọi RegisterPlayFabUser (0x2ABC91C), không nằm trong callback thành công ⇒ danh tính ổn định qua các lần chạy offline, lần sau đi nhánh LOGIN. Trong bản restore hai nhánh đi qua ServiceLocator.Login.SignIn (R1) | disasm-proven | G322, G323 | | DiaPig.Init (0x2B278AC) cố ý bất đối xứng: save null ⇒ Dia_Now = 0 và chỉ neo lại đồng hồ tick, bỏ qua Tick_Accumulate ⇒ save bị xoá/thiếu không thể đúc dia offline; chỉ nhánh restore mới tích luỹ. Timestamp parse DateTimeStyles.RoundtripKind và chuyển về UTC (không giả định) ⇒ chuỗi mang offset không thể thổi phồng cửa sổ. Đính chính (G377): SOT không đóng dấu lại _lastTickTime khi nạp — giữ giá trị file (UTC hoá, chỉ kẹp nếu ở tương lai = chống vặn giờ tới, 0x2B27994); thứ được đóng dấu lại lúc nạp là _lastTickMono (mốc đồng hồ đơn điệu gate việc tích luỹ). Nghiệm thu DiaPig_LastTick = giá trị file là đúng | disasm-proven | G327, G377 | | Fish_Tank.ReloadAll (0x2B0142C): tank đang inactive ⇒ hoãn qua _pendingReload (xếp cá cần RectTransform sống; làm khi ẩn sẽ ra vị trí rác); refill bị chặn bởi cả số cá trong Fish_manager.Inventory lẫn cỡ pool; FindEmptyPosition trả điểm cho SetPosition; SortHierarchyByGrade; text "{0}<size=25>/{1}" với trần 20; rồi StartAutoMergeChain | disasm-proven | G327 | | Chép phòng thủ ở StepUp / DailyGun / PlusPack: StepUp.LoadFromSaveData (0x2B3AFF4) chép tối đa 5 cờ mua, kẹp theo cả độ dài mảng lưu lẫn mảng mình; DailyGun (0x2B266D8): Week_Key rơi về "" (không phải null) để Week_Refresh so sánh không cần null-check, tối đa 3 đếm mua; PlusPack (0x2B2C2F4): thay Purchase_dateTime bằng new DateTime[3] trước khi chép ⇒ mảng lưu ngắn/null để lại default(DateTime) chứ không phải giá trị cũ. Ctor: StepUp.Purchased = new bool[5], Open_Place = "banner_weapon"; DailyGun.Purchase_Counts = new int[3], Week_Key = "" | disasm-proven | G309 | | Cờ mute của Setting được đóng gói: ContinueLoad ghi BGM_Mute@0x1D8 → Setting.instance+0x20 bằng một byte store, rồi SFX_Mute + Vibration_Mute@0x1D9/0x1DA → +0x21/+0x22 bằng một word store ⇒ ba cờ không độc lập về offset nguồn. Setting.UI_Reload (0x2ACD3E0): mỗi toggle là một CẶP object bật/tắt theo phủ định cờ mute, rồi ApplyBGMMute; hàng đăng nhập gate theo nền tảng và trạng thái đăng nhập (Android → nút Google, iOS → Apple; DataLoad/DataSave chỉ khi đã đăng nhập); spinner luôn tắt | disasm-proven | G329, G311 | | Setting.IsSignedIn (0x2ACD654) đọc PlayGamesPlatform.Instance.IsAuthenticated() — trong bản restore đi qua ServiceLocator.Login.IsSignedIn (Null ⇒ false = không có phiên, không phải câu trả lời bịa) | disasm-proven + quyết định R1 | G312, G320 | | Gun_manager.AD_Gun_OnLoaded chỉ VÔ HIỆU HOÁ (bỏ nếu Owned_Gun_list[slot] != AD_Gun_Num, hết hạn khi RemainSec <= 0) — không nhánh nào đúc được súng quảng cáo ⇒ R1-an toàn. FreeCash_manager.LoadFromSaveData xoá cờ tường minh khi save null. Tutorial_manager.SetCleared gọi StopAllCoroutines trước CompleteTutorial (bắt buộc — tránh MoneyCheckLoop gọi lại SetStep) | disasm-proven | G291 | | ServerConfig_manager.LoadFromSaveData (0x2AC1FA8..0x2AC265C): restore InstallDateUtc (DateParseSafe "yyyy-MM-dd"), InstallDateSource, RewardAdCnt, PostLastDate, CachedConfigJson (mỗi cái ?? ""); phát hiện đổi version build → _versionChanged + log (xử lý ở nơi khác); parse JSON đã cache → AppsFlyerInit.ApplyServerSegment; thiếu ngày cài → TryGetNativeInstallDate hoặc Time_manager.UtcNow. Không có fetch mạng trên đường này ⇒ tái hiện nguyên văn. Nhãn nguồn ngày cài: LEGACY_USE_REAL_INSTALL_DATE ? "estimated" : "update" — chốt bằng CMP W8,#0 / CSEL …,EQ | disasm-proven | G326, G327 | | Khối Adventure trong ContinueLoad: Adventure_Map_Info_list không có LoadFromSave — SOT chép is_Enter / Enter_dateTime từng phần tử trong vòng lặp lồng, chặn ở cả hai cấp (số loại map, rồi số map mỗi loại) | disasm-proven | G330 | | Shop_manager có .cctor (0x2B36F9C, 1936 B): cấp Dia_FirstBuy_Used = new bool[5] (static+0x28) tại 0x2B36FF4 và DiaRewards; Is_Dia_FirstBuy(int) (0x2B2D458) = đúng ba phép thử của binary: index < 0 ⇒ false; Length <= index ⇒ false; return !Used[index] — không có null-guard (CBZ thẳng vào helper ném) ⇒ thiếu .cctor là save mới NRE ngay lần đầu chạm UI mua-lần-đầu | disasm-proven | G350 | | Time_manager.Init (0x2AD12F4): cấp Ledger nếu null, rồi đối chiếu trust (so TrustLevel, neo offset đã lưu, reconcile máy chủ). Bản restore chỉ giữ cấp Ledger (vì Load và gain-check dereference nó); tầng trust cố ý không tái hiện (anti-cheat, ngoài phạm vi) | disasm-proven (đọc) / quyết định lane (không tái hiện) | G321 | | Gamemanager..cctor (0x2A517A4, 1160 B) mang 6 khởi tạo field: TimeCheckUrls = {google, cloudflare, bing, apple}, GainRetryDelaySec = {15f, 60f}, _lastGainCheckRealtime = float.NegativeInfinity (lần kiểm đầu luôn tới hạn; 0 sẽ âm thầm trễ một chu kỳ), _moneyCache = new Dictionary<string, InfVal>(), _moneyCacheKeys = new Queue<string>(), _textCooldowns = new Dictionary<Vector2Int, float>(). CleanupTextCooldowns (MoveNext 0x2A51D58): Time.time, ngưỡng cũ 2 s, quét mỗi 5 s | disasm-proven | G319 | | Bộ field cần so sánh khi nghiệm thu save-load (ưu tiên theo mức "sai thì im lặng và đắt"): tiến độ (Stage_Now, Level_Now, Stage_Value_Max, SpeedRun/Boss Stage_Now, Monster Wave_Now) · kinh tế (Money, Money_Accum, Ruby, Dia, PetCoin, Upgrade_Lv[3], Rebirth_Upgrade_Lv[3], Rebirth_Count) · quyền lợi (6 cờ gói Shop, PurchaseCount, Dia_FirstBuy_Used[5]) · timer có thể cấp thưởng (buff money/power, vé Trip + mốc nạp, DiaPig Dia_Now + tick cuối, Mine TicketUse_Count, Fish FreeGachaCount) · danh tính (PlayFab_Email/Password/DisplayName phải giữ nguyên — lệch nghĩa là đã đúc mới thay vì restore) · cờ (TutorialCleared, is_reviewed, mute ×3) | quy trình nghiệm thu | G329; FIELD_MAP mục "Batch-9 acceptance" |

35 restore trực tiếp của ContinueLoad (gộp theo manager; @off = offset trong SaveData; nguồn FIELD_MAP, mỗi hàng có dòng Hex-Rays):

2.9 Trip / Adventure — vé, XP, bảng mở khoá (đợt 3)

2.10 Chế độ Mine (đào quặng) — luật đọc từ binary (đợt 9, G393)

2.11 Chế độ Play (SpeedRun) — luật đọc từ binary (đợt 11, G406 / lane M2)

2.12 Chế độ Raid (ẩn, chưa phát hành) — luật đọc từ binary (G406 / lane M2)

2.13 Chế độ Hunt (Monster_manager) — luật đọc từ binary (đợt 12, G408 / lane M1)

2.14 Chế độ Boss — luật đọc từ binary (G408 / lane M1)

3. Mô hình hành vi

3.1 Bộ khung: 35 singleton, không có DI

public class X_manager : MonoBehaviour
{
    public static X_manager instance;          // field static trần
    private void Awake() { instance = this; }  // đăng ký, không kiểm trùng
    public void Balance_Reload() { … }         // sinh bảng số — NHƯNG LÀ DEAD CODE (xem dưới)
    public int[] SaveData_return() { … }       // xuất state
    public void LoadData(SaveData data) { … }  // nạp state
    public void UI_Reload() { … }              // vẽ lại UI từ state
}

Đây là kiến trúc đơn giản đến mức thô — không dependency injection, không service locator, không event bus tổng. Mọi hệ thống gọi thẳng X_manager.instance.Foo().

Vì sao nó hoạt động ở đây: game có đúng một scene (doc 08). Mọi manager tồn tại từ lúc load đến lúc thoát. Không có vòng đời phức tạp, không có scene bị unload, nên rủi ro lớn nhất của singleton (tham chiếu chết) không tồn tại.

Vì sao nó vẫn nguy hiểm: khớp nối chéo là toàn phần. Cặp Tree.Die_Reload → Tree_manager.Tree_Destroyed chạm vào Particle_Polling, Tree_manager, Gamemanager, Mission_manager, và AppsFlyerInit — năm singleton cho một cây đổ (đợt 3 tách được hai hàm mà IDA đã gộp: Die_Reload 2 dòng, Tree_Destroyed 864 B — G346). Đây chính là lý do lane codegen không thể ship Gamemanager dạng overlay 70 method: nó kéo theo cả đồ thị.

Bốn quy ước method lặp lại ở hầu hết manager là thứ đáng học hơn cả bản thân singleton:

Sự tách bạch First_Reload() (thiết lập một lần: sprite, tên, chỉ số) và Value_Reload() (cập nhật thường xuyên: số, tiến độ, trạng thái khoá) xuất hiện ở khắp nơi và có bằng chứng runtime rõ: Mission_Reward_Item.First_Reload 200× vs Value_Reload 150×; Skin_Item_UI.First_Reload 25×. Đây là mẫu tối ưu UI đơn giản và hiệu quả.

3.2 Cân bằng: hàm sinh là công cụ Editor, mảng bake là nguồn sự thật

Mọi manager có tiến trình đều có một Balance_Reload() sinh bảng số từ vài hằng số:

Upgrade_manager.Balance_Reload()  RVA 0x2B4A02C   -> Money/Power/Speed/Price_balance  (10 001 phần tử)
Rebirth_manager.Balance_Reload()  RVA 0x2B21CB4   -> Value_balance ×3 + Price_balance (20 001 phần tử)
Relic_manager.Balance_Reload()    RVA 0x2ADFE20   -> Damage/Money/CriDmg_Balance
Skin_manager.Balance_Reload()     RVA 0x2B3F2EC   -> Price_Balance
Tree_manager.Balance_Reload()     RVA 0x2B447EC   -> Stage_Health/Money_Balance
Gun_manager.Balance_Reload()      RVA 0x2B0AB4C   -> StartCoroutine(Request_Sheet())  [Google Sheet TSV]

Nhưng không cái nào chạy lúc runtime. CodeRefsTo rỗng cho cả ba cái đã kiểm (Upgrade, Rebirth, Gun); không có string literal (loại trừ Invoke/StartCoroutine theo tên); không có m_MethodName: Balance_Reload trong scene (loại trừ UnityEvent). Không có [ContextMenu] trong dump ⇒ nhiều khả năng chúng được gọi từ một custom Editor (Assembly-CSharp-Editor, không có trong build) rồi bake kết quả vào scene.

Bảng thật lúc chạy nằm ở Main.unity (số dòng ghi trong [F001: scene_balance_tables.json]), và chúng được sinh bằng lặp có CẮT với hằng số là double nhị phân — lệch tới −10.2 % ở lv 50 so với dạng đóng. Chi tiết đầy đủ, bảng sai lệch và bài học: 09-prestige-rebirth.md §3.2.

Kiểm chứng độc lập: Speed_balance[46] = 468, Money_balance[46] = 3 120 (3.12a), Price_balance[46] = 1.34×10⁸ (134b) — cả ba khớp ảnh chụp save thật của người dùng ở Lv.46.

Hệ quả cho một bản restore: giữ nguyên mảng serialize; đừng gọi Balance_Reload trong Awake. Gọi nó với một InfVal khác phiên bản (làm tròn thay vì cắt, hoặc 1.38 thập phân) sẽ sinh ra một nền kinh tế khác SOT.

Hệ quả cho một framework: nếu bảng được bake, bảng là hợp đồng — kèm checksum, và hàm sinh phải tái tạo được nó trong CI. Nếu không, hàm sinh sẽ âm thầm trôi khỏi dữ liệu đã ship.

Ngoại lệ đã kiểm: Tree_manager.Degree_Health_Balance = {1, 1.8, 3, 35} và Degree_Money_Balance = {1, 1.8, 3, 100} được tính trong .cctor (0x2B46094) nên chúng thực sự chạy lúc runtime. (Thứ tự theo enum degree: HYPOTHESIS.)

3.2b Ba lớp cổng — và vì sao phải tách chúng ra

Người chơi gặp ba hệ thống khoá độc lập, không phải một. Chúng chồng lên nhau và được xác nhận bằng hai phiên probe runtime độc lập:

Lớp 1 — TUTORIAL            Tutorial_manager mở dần các nút HUD
   save mới (Stage_Value_Max = 0):  CHỈ SpeedRun_Btn + Setting_Btn bật
   Shop / Gun / Skin / Mission / DailyCheck / Auto / Eco / DiaPig / Buff  -> TẮT
   và KHÔNG cái nào được Contents_Lock_Reload chạm tới

Lớp 2 — TIẾN ĐỘ            Tree_manager.Contents_Lock_Reload  (0x2B4441C)
   so Stage_Value_Max với 20 / 30 / 50 / 90 / 110 / 110 / 340
   Stage_Value_Max = max(Level_Now + 10*Stage_Now), CHỈ TĂNG, không bị Rebirth reset

Lớp 3 — SEGMENT / LIVEOPS  ServerConfig_manager (segment) + trạng thái SDK riêng của từng bề mặt
   đơn vị đo: MaxStageDisplay = Stage_Value_Max / 10 + 1     <- KHÔNG phải Stage_Value_Max thô
   OfferWall      >= 10          (bật vĩnh viễn)
   Interstitial   >= 12          (chỉ 2 điểm đặt: Rebirth, Mine)
   FreeCash       15 .. 35       (CỬA SỔ HAI ĐẦU — tự ẩn khi vượt 35)
                                 + cổng thứ hai: AlmediaLinkSDK._almediaStatus in {1,2}
                                   (mặc định 3 = NotAvailable -> máy fresh không bao giờ thấy)
   segment = 0    -> tắt sạch

Ba lớp trả lời ba câu hỏi khác nhau:

Vì sao đây là bài học framework quan trọng: trộn ba lớp này vào một cờ isUnlocked là một trong những sai lầm tốn kém nhất trong game live-service. Chúng có chủ sở hữu khác nhau (designer / system / growth), nhịp thay đổi khác nhau (không bao giờ / theo tiến độ / theo cấu hình từ xa), và hậu quả khác nhau khi sai (người chơi bối rối / mất nội dung / mất doanh thu hoặc spam).

Đáng chú ý: lớp 1 vô hình với phân tích tĩnh. Nếu chỉ đọc Contents_Lock_Reload, bạn sẽ kết luận Shop/Gun/Skin mở ngay từ đầu — sai. Phải chạy một save mới thật mới thấy chúng tắt.

FreeCash là ví dụ duy nhất của cửa sổ hai đầu (15 ≤ x ≤ 35): một lời chào mời chỉ xuất hiện ở khoảng giữa game — đủ lâu để người chơi có động lực, đủ sớm để họ chưa tự lo được. Đây là một mẫu tuning đáng chép: không phải mọi thứ mở ra rồi ở đó mãi.

Và một lớp gate thứ tư mà cả ba đều không thấy: THỜI GIAN THỰC. Map của Trip xoay theo ngày trong tuần (Forest T2/T5/CN · Desert T3/T6/CN · Glacier T4/T7/CN). Không có phân tích tĩnh nào phát hiện ra điều này — nó chỉ hiện ra khi mở panel trên máy thật. Cộng với Adventure_Unlock_Balance = [0,1,3,6,10] (gate theo Trip Level, không theo stage), Trip có hai trục gate riêng, độc lập với cả ba lớp ở trên.

3.2c Đường boot & định dạng save

Luồng nạp save — offline chạy TRƯỚC, và là một continuation:

// LoadData.Load(data)
if (data == null)
    InitNewGame();
else
    OfflineProgressManager.instance.EvaluateAndApply(data, ContinueLoad);   // <-- ContinueLoad = continuation

CodeRefsTo(EvaluateAndApply) = đúng một người gọi: LoadData.Load. Nghĩa là:

• Tiến trình offline được tính trước khi bất kỳ manager nào nạp state của nó.
• Popup "Chào mừng trở lại!" nằm trong luồng điều khiển, không phải một hiệu ứng phụ chạy song song: phần còn lại của việc nạp save chờ nó xong rồi mới tiếp tục.
• ContinueLoad sau đó toả ra ~48 điểm gọi: X.LoadFromSaveData(data) cho từng manager, cộng một cặp Time_manager.get_Now / DateParseSafe cho từng bộ đếm thời gian (buff, vé, daily, cooldown…). Đợt 3 đã chứng minh từng field của đường này (35 restore trực tiếp + thứ tự gọi + vị trí AllowSave) — xem §2.8 và [evidence codegen: FIELD_MAP.md].

Đây là một thứ tự có chủ đích, không phải tình cờ: offline phải chạy trước vì nó ghi vào Gamemanager.Money và đẩy level upgrade lên (§01 §5.8); nếu manager nạp state trước thì kết quả offline sẽ bị ghi đè.

Định dạng save — không mã hoá, không salt:

SaveSystem.TryLoadFrom   0x2AC6064
JsonData_Decoding        0x2AC6228   =>  Base64( UTF8( JSON của JsonUtility ) )

Application.persistentDataPath + "/saves/"
    NoSaveFile.json        (chính)
    NoSaveFile.json.bak    (dự phòng — dùng khi bản chính parse ra null)

Và điểm đáng chú ý nhất: game dùng Anti-Cheat Toolkit (ObscuredInt, ObscuredFloat…) cho state trong bộ nhớ — nhưng SaveData khai báo kiểu thường:

public class SaveData {          // dump.cs:589019+
    public InfVal Money;         // 0x18
    public int    Dia;           // 0x78   <- int THƯỜNG, không phải ObscuredInt
    …                            // 100+ field
}

(Đã tự kiểm: 0 lần xuất hiện chuỗi Obscured trong toàn bộ khối SaveData.)

Khối restore chép thẳng từng field vào static của manager — ví dụ data.Money (@+0x18) → Gamemanager static +0x28.

Đánh đổi, nói thẳng: chống gian lận phía bộ nhớ (ACTk) + save plain-text khi nghỉ. Nó chặn được lớp tấn công phổ biến nhất (công cụ quét/sửa bộ nhớ như GameGuardian) với chi phí gần bằng 0, và không chặn được người chơi mở file save ra sửa bằng tay. Đó là một lựa chọn hợp lý cho một game idle single-player: giá trị bị đe doạ là doanh thu quảng cáo/IAP của chính người chơi đó, không phải sự công bằng với người chơi khác. Mã hoá save sẽ chỉ làm chậm kẻ quyết tâm và tăng rủi ro hỏng save cho người dùng thật. Nếu game có bảng xếp hạng có thưởng, phép tính này đổi — và CatGunner có Rank_manager, nên đây là một điểm đáng chất vấn chứ không phải một hình mẫu để chép mù.

Ba tầng phòng thủ khi NẠP (đợt 3, disasm-proven — §2.8): (1) kẹp giá trị có thể cấp thưởng ngay lúc nạp (LoadBuffTimes = Clamp(0, 900)); (2) bất đối xứng null-save cho mọi thứ tích luỹ theo thời gian (DiaPig.Init: save null chỉ neo lại đồng hồ, không Tick_Accumulate); (3) chép phòng thủ cho mảng (min(độ dài lưu, độ dài mình), thay mảng mới trước khi chép, chuỗi rỗng thay null). Cộng với AllowSave đặt ở cuối ContinueLoad / InitNewGame — autosave không thể ghi đè một save đang nạp dở.

⚠ QUY TẮC KHÔI PHỤC — bắt buộc

Không bao giờ bật việc nạp save trước khi khối restore hoàn chỉnh và chính xác. Một bản restore một phần sẽ đọc save của người chơi cũ, khôi phục thiếu, rồi ghi đè save đó bằng trạng thái thiếu — phá huỷ tiến trình của họ trong im lặng. Điều đó tệ hơn việc không restore gì cả: không restore thì người chơi thấy game mới và biết ngay; restore thiếu thì họ mất nhiều giờ chơi mà không có cách nào lấy lại. Với SaveData 100+ field và ~48 điểm LoadFromSaveData, "gần đủ" là một trạng thái rất dễ rơi vào.

3.3 Súng: gacha → merge → hạn dùng

DrawRandom_Normal() / DrawRandom_Epic() / DrawGun_Degree_5(degree)
        |
        v
DrawRandomGun(degree) -> FindFirstEmptyOwned() -> Owned_Gun_list[slot] = gunNum   (16 ô, -1 = trống)
        |
        +-> OnWeaponAcquired(gunNum) -> Weapon_Get_Counts[degree]++   [thống kê cho analytics R1]
        +-> NewGun_UI_Reload(gunNum)
        |
        v
TryStartAutoMerge()  (nếu is_AutoMerge)
        AutoMerge_Limit_Degree = min(AutoMerge_Degree, Max_Collected_Degree)
        const AutoMerge_Exclude_Degree = 7   <- bậc >= 7 KHÔNG BAO GIỜ tự ghép

Ba chi tiết thiết kế:

1. Kho cố định 16 ô với -1 là ô trống. Không List, không cấp phát. Chỉ một int[16]. FindFirstEmptyOwned() là một vòng lặp tuyến tính — trên 16 phần tử thì đó là cách nhanh nhất.

2. Auto-merge có trần cứng bằng hằng số. AutoMerge_Exclude_Degree = 7 bảo vệ người chơi khỏi việc tự động ghép mất một khẩu hiếm. Đây là kiểu ràng buộc phải nằm trong code, không nằm trong cấu hình — một designer chỉnh nhầm sẽ phá tài khoản người chơi.

3. Súng thưởng quảng cáo có hạn dùng theo long AD_Gun_EndUtcTicks. Nó chiếm một ô kho, hết hạn thì AD_Gun_Clear(removeFromInventory). Đây là "cho mượn sức mạnh" chứ không phải "cho sức mạnh" — một mẫu monetization gặp thường xuyên. Toàn bộ đường này là R1.

Cân bằng từ xa (đáng chú ý): Gun_manager chứa một URL Google Sheets dạng export?format=tsv&range=A2:I66 cùng coroutine Request_Sheet(). Nghĩa là bảng chỉ số súng (9 cột × 65 dòng) tải được từ xa sau khi ship. Đây là một mẫu liveops thật, rất phổ biến, và cũng là một rủi ro cần ghi nhận: bản restore có thể quan sát thấy chỉ số khác với bảng nhúng.

Ranh giới R1: Request_Sheet là truy cập mạng ra dịch vụ ngoài ⇒ phải đi qua IRemoteConfigService với binding mặc định fail-closed (không trả về giá trị từ xa nào).

3.4 Buff: hai đồng hồ, một coroutine

// Buff_manager — dump.cs:592886
private const float BUFF_DURATION = 300f;   // mỗi lần nhận: +5 phút
public  const float BUFF_MAX      = 900f;   // trần tích luỹ: 15 phút
private float moneyBuffTime;                // @0x28
private float powerBuffTime;                // @0x2C
private Coroutine buffCoroutine;
private void TryStartCoroutine();           // chỉ chạy coroutine khi có buff
public  void AddBuff(AD_Type type);
public  bool IsBuffActive(AD_Type type);
public  float GetBuffRemainingTime(AD_Type type);
public  bool IsPermanentBuff { get; }

Thiết kế đáng học:

• Buff là thời gian còn lại, không phải danh sách instance. Hai float thay cho một List<ActiveBuff>. Nhận buff = cộng 300 giây, kẹp ở 900. Không cấp phát, không GC, không sắp xếp.
• AddBuff cộng dồn có trần. Xem 3 quảng cáo liên tiếp = 15 phút, không phải 3 buff chồng nhau. Trần cứng ngăn người chơi tích trữ vô hạn.
• Trần được áp cả khi NẠP save, không chỉ khi cộng: LoadBuffTimes kẹp [0, 900] bằng NEON (G291). Một save sửa tay moneyBuffTime = 1e9 vào game vẫn chỉ còn 15 phút.
• Một coroutine duy nhất, chỉ chạy khi cần (TryStartCoroutine). Khi không có buff nào, không có gì chạy mỗi frame.
• IsPermanentBuff là đường thoát riêng cho buff vĩnh viễn (mua bằng IAP) — nó là property, không phải một float = ∞. Runtime cho thấy nó được hỏi 103× trong 40 giây, tức nằm trên hot path và được kiểm trước mọi thứ khác.
• AD_Type có 10 giá trị nhưng Buff_manager chỉ giữ 2 đồng hồ. Nghĩa là 8 giá trị còn lại là loại phần thưởng quảng cáo một lần (bonus, gacha, rebirth boost), không phải buff theo thời gian. Một enum, hai ngữ nghĩa — hợp lý ở đây vì tất cả đều là "người chơi xem quảng cáo để lấy X".

3.5 Nhiệm vụ: 4 loại, một API

public enum Mission_Type { TreeCount = 0, StageClear = 1, Rebirth = 2, PlayMine = 3 }

// Call-site duy nhất từ gameplay:
Mission_manager.instance.MissionValue_Increase(Mission_Type.TreeCount);   // Tree_manager.Tree_Destroyed (G346; trước ghi nhầm là Tree.Die_Reload)
Mission_manager.instance.MissionValue_Increase(Mission_Type.Rebirth);     // Rebirth()

Bốn loại nhiệm vụ cho một game có hàng chục hệ thống. Đây là một quyết định thiết kế mạnh: nhiệm vụ chỉ theo dõi những hành động cốt lõi (giết cây, qua màn, rebirth, chơi mỏ), không theo dõi mọi thứ. Kết quả: Mission_manager (54 method) hầu hết là UI và phần thưởng, không phải theo dõi.

Runtime xác nhận vòng khép kín: Tree.Die_Reload 85× → Tree_Destroyed → MissionValue_Increase 86×.

is_Reward_SequenceLocked (150×) cho thấy phần thưởng phải nhận theo thứ tự — người chơi không nhảy cóc lấy phần thưởng lớn. Cộng với hệ mùa (Season_Reload, is_Season_Closed), đây là bộ khung battle-pass tối giản.

3.6 Ranh giới R1 — cái đúng đắn nhất trong toàn bộ project

// [restore project: NullServices.cs]
public sealed class NullAdService : IAdService
{
    public bool IsInterstitialReady => false;
    public bool IsRewardedReady     => false;
    public void ShowRewarded(string placementId, Action<ServiceResult> onReward)
    {
        NullLog.Refused(nameof(NullAdService), nameof(ShowRewarded));
        onReward?.Invoke(ServiceResult.NotAvailable);      // TỪ CHỐI. Không bao giờ grant.
    }
}

Quy tắc (R1, nguyên văn): "Reward/purchase/entitlement calls FAIL CLOSED: return failure/denied, never success. A NullService may log and no-op. It may never fabricate progression state."

Vì sao đây là mẫu quan trọng nhất trong tài liệu này:

• Một game idle chằng chịt các call-site quảng cáo/IAP: buff ×3, rebirth ×3, gacha, súng thưởng, offerwall, free cash, phần thưởng nhiệm vụ. Đó là 10 giá trị AD_Type.
• Nếu một stub trả về "thành công", bản restore sẽ tự trao thưởng cho chính nó — và mọi phép đo parity sau đó đều vô nghĩa, một cách âm thầm.
• Fail-closed nghĩa là: nếu quên bind một service, người chơi nhận ít hơn thực tế. Sai theo hướng an toàn, và sai một cách quan sát được.

Trong build hiện tại, ngay cả 46 assembly SDK còn giữ lại cũng fail-closed do cấu trúc: chúng là DLL do Cpp2IL dựng, không có thân method, nên mọi lời gọi qua chúng trả về default.

3.7 Reset theo ngày có tầng chống đổi giờ máy — mẫu chuẩn của mọi quota hằng ngày

Đọc từ Fish_manager.FreeGacha_Reload (quota 5 lượt rút cá/ngày, doc 10 §4.1b, docs/functions/ca-fish.md §6). Cùng một hình dạng dùng lại được cho điểm danh, vé Trip, quota quảng cáo — bất cứ thứ gì "mỗi ngày N lần".

void Reload()
{
    if (savedDate.Date >= Time_manager.Today) return;              // 1. chưa sang ngày mới
    if (!Time_manager.CanRolloverDaily("fish_free", 3)) return;    // 2. tầng trust chưa đồng ý
    Time_manager.RecordGain("fish_free");                          // 3. ghi sổ TRƯỚC
    count = 0;                                                     // 4. rồi mới phát
    savedDate = Time_manager.Today;                                // 5. và mới đánh dấu
}

Bốn quy tắc, xếp theo mức dễ làm sai:

1. KHÔNG BAO GIỜ so bằng DateTime.Today. Mọi hệ theo lịch phải hỏi một nguồn giờ duy nhất (Time_manager.Today = Now.Date, với Now là giờ local đã hiệu chỉnh theo lệch đo được với máy chủ). Hai nguồn giờ trong một game là hai lịch, và chúng sẽ lệch nhau đúng vào lúc người chơi đổi múi giờ.
2. Cổng chống gian lận là một SỔ NỢ CÓ TRẦN, không phải một cờ boolean. CanRolloverDaily(key, maxPending) = SaveLoaded && CanGrantTimedReward && PendingCount(key) < 3. Người chơi được "ứng trước" tối đa 3 lần rollover chưa xác thực; quá đó thì hệ ngừng phát cho tới khi giờ được xác nhận. Ưu điểm so với cờ: chơi offline dài ngày vẫn nhận được, chỉ có gian lận lặp lại mới bị chặn — và mỗi khoá ("fish_free", …) có sổ riêng nên một hệ bị khoá không kéo theo hệ khác.
3. Bị chặn thì KHÔNG ghi ngày mới. Đây là toàn bộ khác biệt giữa "hoãn" và "mất": vì savedDate giữ nguyên ngày cũ, điều kiện savedDate < Today vẫn đúng ở lần gọi sau, nên lần đồng bộ tiếp theo thử lại. Ghi ngày trước khi qua cổng = người chơi mất trắng quota hôm đó, im lặng. Quy tắc tổng quát: đừng bao giờ đánh dấu "đã phát" trước khi phát.
4. Kẹp ngày lưu về hiện tại khi đồng hồ được đồng bộ. OnSynced → savedDate = ClampFutureLocalDate(savedDate) chặn kiểu gian lận "đẩy giờ máy tới tương lai rồi trả về" — nếu không, ngày lưu nằm ở tương lai và quota đóng băng vĩnh viễn. Trần là Today.AddDays(1); khi không vượt trần thì trả saved nguyên vẹn, không phải saved.Date (giữ cả phần giờ).

Điểm gọi: hàm Reload() phải chạy ở cả hai đường — mỗi lần vẽ lại UI của bề mặt đó, và khi đồng hồ vừa được đồng bộ lúc UI đang đóng. Chỉ gọi ở một chỗ là có một cửa sổ trong đó bộ đếm cũ được dùng để quyết định.

Bẫy dựng lại (G1679): hai hàm ClampFutureLocalDate/ClampFutureLocal từng là ret-stub return default(DateTime) và nằm im vô hại cho tới khi một lô khác dựng đúng OnTimeSynced — lúc đó mỗi lần đồng bộ giờ sẽ ghi 0001-01-01 vào ngày lưu, tức reset quota mỗi lần. Bài học chung cho mọi dự án khôi phục: dựng đúng một hàm có thể kích hoạt một stub ở lớp khác đang nằm im. Trước khi kết thúc một lô, phải quét stub trên toàn bộ callee mà lô vừa mở đường tới.

4. Framework takeaway

1. Bốn quy ước method cho mọi hệ thống tiến trình: Balance_Reload() sinh bảng số từ công thức — CÔNG CỤ EDITOR, bake ra asset SaveData_return() / LoadData() ranh giới lưu trữ, một cặp mỗi hệ thống First_Reload() / Value_Reload() thiết lập một lần vs cập nhật thường xuyên static X_return() phơi giá trị dẫn xuất cho hệ thống khác Bốn cái này lặp lại ở ~30 manager. Framework nên đưa chúng thành interface, không để mỗi người tự đặt tên.

2. Cân bằng là công thức + vài hằng số, không phải bảng inspector. 7 hằng số sinh ra 10 001 phần tử. Chỉnh nhanh hơn, diff sạch hơn, và khôi phục được từ binary. Framework nên cung cấp ICurve { BigNum ValueAt(int lv); } với các hiện thực sẵn (hình học có làm tròn, tuyến tính, đa thức, có soft-cap).

3. Kho vật phẩm cố định + giá trị lính canh (int[16], -1 = trống) thay cho List<T>. Với kích thước nhỏ, quét tuyến tính là nhanh nhất và không cấp phát.

4. Ràng buộc bảo vệ người chơi phải là const trong code, không phải cấu hình. AutoMerge_Exclude_Degree = 7 là ví dụ: một designer chỉnh nhầm sẽ phá tài khoản.

5. Buff = thời gian còn lại có trần, không phải danh sách instance. float remaining; const float PER_GRANT = 300; const float MAX = 900; AddBuff() => remaining = min(remaining + PER_GRANT, MAX) Không cấp phát, cộng dồn tự nhiên, trần cứng chống tích trữ. Cộng một property IsPermanent riêng.

6. Ít loại nhiệm vụ. Bốn loại là đủ cho một game thương mại. Theo dõi hành động cốt lõi, không theo dõi mọi thứ — nếu không, mỗi hệ thống mới lại phải sửa hệ nhiệm vụ.

7. Mọi dịch vụ ngoài nằm sau interface với binding mặc định FAIL-CLOSED. Đây là bất biến quan trọng nhất trong một game idle, vì phần thưởng quảng cáo/IAP đan xuyên toàn bộ hệ thống tiến trình. Một stub được phép log và no-op; không bao giờ được bịa progression.

8. Tách "máy móc toàn vẹn" khỏi "gameplay" ngay từ đầu. Một nửa Gamemanager (70 method) và toàn bộ Time_manager (51 method) là chống gian lận thời gian. Trong framework, đó phải là module riêng đằng sau ITrustedTime, không trộn vào manager kinh tế — nếu không, bạn không thể kiểm thử kinh tế mà không có mạng.

9. Kiểm tra xem cấu hình từ xa CÓ THỰC SỰ chạm vào cân bằng không — đừng giả định theo cả hai hướng. Ở đây có đủ hạ tầng cho việc đó (URL Google Sheet trong Gun_manager, Firebase RemoteConfig, PlayFab, một endpoint config riêng) và trực giác ban đầu là "số có thể bị ghi đè từ xa". Kiểm tra bằng xref cho thấy: không. RemoteConfig chỉ chạm UpdateManager; GetTitleData 0 caller; ServerConfig chỉ mang tham số quảng cáo; và Request_Sheet chỉ tới được từ một Balance_Reload đã chết. Bài học: một hạ tầng có mặt không có nghĩa nó được dùng. Ba lệnh xref rẻ hơn một giả định sai.

10. Đừng dựng lại thứ mà runtime cho thấy không quan trọng. 731 type, chỉ 190 vào scene, 66 class chiếm phần lớn thời gian chạy. Xếp hạng bằng dữ liệu, đừng xếp hạng bằng cảm giác.

11. PHÂN TẦNG CỔNG: đừng gộp ba loại khoá vào một cờ isUnlocked. ITutorialGate : "đã học tới đâu?" — designer sở hữu, không bao giờ đổi sau khi ship IProgressGate : "đã đi xa nhất tới đâu?" — high-water mark, không bị prestige reset ISegmentGate : "nhóm nào, có chào mời không?" — cấu hình từ xa, đổi bất cứ lúc nào ITimeGate : "hôm nay là thứ mấy?" — map Trip xoay theo ngày trong tuần Bốn lớp, bốn chủ sở hữu, bốn nhịp thay đổi, bốn kiểu hậu quả khi sai. Gộp lại là một trong những sai lầm tốn kém nhất của game live-service. Cảnh báo phương pháp: lớp Tutorial và lớp Time vô hình với phân tích tĩnh — chỉ hiện ra khi chạy một save mới thật trên máy thật.

11b. Cửa sổ chào mời hai đầu. FreeCash chỉ hiện trong khoảng Stage 15…35 và tự ẩn khi người chơi vượt qua. Không phải mọi thứ mở ra rồi ở đó mãi — một lời chào mời hết phù hợp thì nên biến mất.

11c. Ngưỡng đo bằng ĐƠN VỊ NGƯỜI CHƠI THẤY, không bằng biến nội bộ. Mọi cổng liveops so sánh với MaxStageDisplay = Stage_Value_Max/10 + 1 — tức số stage hiển thị, thứ mà người vận hành và người chơi cùng nói tới. Cấu hình từ xa ghi "Stage 15" và nó thật sự nghĩa là Stage 15. Nếu cấu hình dùng biến nội bộ, mọi người sẽ chỉnh sai.

11d. "Nhận thưởng theo thứ tự" là một quy tắc, không phải một ngưỡng. is_Reward_SequenceLocked không so sánh với con số nào — nó quét claimed[] và khoá chừng nào còn một mốc thấp hơn chưa nhận. Framework nên có sẵn kiểu này (SequentialClaimTrack) thay vì để mỗi người tự dựng bằng ngưỡng số.

11e. Mốc mở khoá đọc một tiến độ ĐƠN ĐIỆU riêng, không đọc tiến độ hiện tại. Stage_Value_Max = max(Level_Now + 10·Stage_Now) chỉ tăng và không bị prestige reset — nên prestige không bao giờ khoá lại nội dung người chơi đã mở. Framework nên có sẵn một HighWaterMark riêng cho việc mở khoá.

12. Thứ tự boot là hợp đồng, không phải tình cờ. LoadData.Load chạy offline trước, rồi truyền ContinueLoad làm continuation — vì tiến trình offline ghi vào tiền và level. Framework nên phơi ra một pipeline boot có thứ tự tường minh (IBootStep với thứ hạng), không để mỗi manager tự Awake rồi hy vọng.

13. Chống gian lận bộ nhớ ≠ chống gian lận file — chọn có ý thức và ghi lại lựa chọn. SOT bọc state runtime bằng ACTk nhưng ghi save Base64(JSON) trần. Hợp lý cho idle single-player; đáng chất vấn khi có bảng xếp hạng có thưởng. Đừng chép mẫu này mà không kiểm lại mô hình mối đe doạ.

14. ⚠ QUY TẮC KHÔI PHỤC: không bật nạp save trước khi khối restore hoàn chỉnh. Restore một phần sẽ đọc save cũ, khôi phục thiếu, rồi ghi đè — phá tiến trình người chơi trong im lặng. Tệ hơn hẳn việc không restore gì. Với 100+ field và ~48 điểm LoadFromSaveData, "gần đủ" là trạng thái rất dễ rơi vào. Framework nên có một cổng an toàn: từ chối ghi save khi số field khôi phục được < 100 % số field đọc vào.

15. ⚠ dump.cs chỉ liệt kê KHAI BÁO, không liệt kê TRUY CẬP. "Field không xuất hiện trong dump.cs" không là bằng chứng nó không được dùng — tài liệu này từng kết luận sai như vậy về Rebirth_Btn_Locked_obj. Dùng xref của IDA (CodeRefsTo / DataRefsTo + decompile + tìm offset). Cùng kỹ thuật là thứ chứng minh Balance_Reload là dead code — một kết luận không thể rút ra từ dump.cs.

16. ⚠ CÂN BẰNG CỦA BẢN SHIP SỐNG TRONG SCENE, KHÔNG TRONG CTOR. Đây là mặt bên kia của bài học "phải chép initializer" (G1648/G1663) và nó đã làm hai kết luận trong dự án này sai:

    Field	Ctor nói	Scene nói	Ai thắng
    Cat_manager.FormationRadius	10	2.5	scene
    Fish_manager.GachaChances (G1682)	{40, 30, 20, 10}	{60, 30, 10, 0}	scene

    Luật đọc, theo loại field chứ không theo trực giác:

    public / [SerializeField] và CÓ trong scene|prefab -> ctor chỉ là mặc định AddComponent; SCENE thắng private KHÔNG [SerializeField] -> CTOR là giá trị thật; scene không cứu được const / static readonly -> ctor/metadata là giá trị thật

    Hệ quả thao tác cho một dự án khôi phục: chép ctor vào code là đúng (thiếu initializer là nợ 1:1 thật), nhưng viết con số của ctor vào tài liệu như cân bằng của game là sai. Trước khi một con số cân bằng được publish, phải trả lời được "field này có serialize không, và scene ghi gì". Cách bắt lỗi rẻ nhất khi chưa đọc được scene: một quan sát tần suất trên máy — năm lượt gacha liên tiếp ra cùng một bậc là 0,6⁵ ≈ 7,8% với bảng thật nhưng 0,4⁵ ≈ 1% với bảng ctor, đủ lệch để đi đọc lại. Nợ còn treo cùng loại: Fish_Draw_Btn.Price (ctor 100, chưa đọc scene — đừng tin con số đó).

5. Negative evidence & UNKNOWN

6. Raw evidence

• [index: priority_static.json] — xếp hạng 731 class theo instance + method
• [index: scene_census.json] — 30 082 tham chiếu m_Script, 190 class có mặt
• [runtime trace: runtime_ranking.json] — 505 method đã chạy, kèm số lần
• dump.cs:602928 — Upgrade_manager (hằng số + 22 method)
• dump.cs:596607 — Gun_manager (gacha, auto-merge, URL từ xa)
• dump.cs:592886 — Buff_manager
• dump.cs:592186 — Relic_manager
• dump.cs:601415 — Skin_manager
• dump.cs:587114 / :584959 — Mission_Type / AD_Type
• dump.cs:583820 — Gamemanager (hằng số chống gian lận)
• [evidence codegen: rule_statics.cs.evidence] — rule statics đã dựng lại
• [evidence codegen: Upgrade_Balance_Reload.c] — Balance_Reload đã giải mã (dead code)
• [phân tích nội bộ] — Balance_Reload là dead code; bảng thật = mảng scene
• [F001: scene_balance_tables.json] — 8 mảng balance trích từ Main.unity
• [device evidence: user_screenshot_stage5-4.png] — xác nhận Speed_balance[46] = 468
• [restore project: Services.cs], NullServices.cs, ServiceLocator.cs} — ranh giới R1
• [report: asset_lane.md] §7 — 781 file SDK ngoài phạm vi
• [liveops catalog: liveops] — danh mục màn hình + cổng mở khoá (lane riêng, liên kết khi bàn giao)
• [evidence codegen: FIELD_MAP.md] — bản đồ restore 22 + 5 + 35 field, mỗi hàng có dòng Hex-Rays (đợt 3)
• [evidence codegen: TABLE.md] — 22 bảng InitializeArray của Assembly-CSharp, 448/448 SHA MATCH toàn build (đợt 3)
• [evidence codegen: CTOR_INITIALIZER_WORKLIST.md] — 39 ctor / 24 class có khởi tạo bị Cpp2IL bỏ rơi
• Gaps: G129, G134, G136; đợt 3: G291, G296, G309, G311, G319–G330, G346, G350, G353 trong gap list (nội bộ)