14 — Lưu game & thu nhập offline (nạp save an toàn, trả tiền vắng mặt đúng luật)

Nguồn framework: docs/framework/07-progression-managers.md §2.8, §3.2c (hệ save/load), docs/framework/01-economy-money.md §5.8 và docs/framework/09-prestige-rebirth.md §4b (kinh tế offline), docs/framework/08-architecture-and-scale.md §3.6 (phương pháp). Cấp bằng chứng: L1 ANALYSIS — dựng lại clean-room từ disasm + metadata + quan sát runtime; không phải source gốc. Mỗi dòng bên dưới mang nhãn bằng chứng riêng và mã G-id trong ledger dự án.

Mục tiêu

Một game idle sống bằng hai khoảnh khắc mà người chơi không nhìn thấy code: lúc nạp save (họ quay lại sau vài giờ) và lúc tính tiền vắng mặt (họ được trả bao nhiêu). Sai ở đây là sai im lặng và không đảo được: save bị ghi đè thiếu, buff vô hạn hồi sinh từ file, tiền offline thổi phồng do chỉnh giờ. Trang này gom toàn bộ luật mà game gốc áp ở hai khoảnh khắc đó — từng field, từng thứ tự gọi, từng chỗ kẹp — để bạn chép đúng phần phòng thủ chứ không chỉ phần "đọc JSON".

Game gốc làm gì

Định dạng và đường nạp

Ba tầng phòng thủ khi nạp

Thu nhập offline — cửa sổ thời gian

Nghiệm thu trên save thật — đã kiểm vs còn mở (đợt 5, trung thực)

Bản dựng lại nạp save thật Stage 3-3 (cùng file được đẩy vào game gốc để so):

Vì sao đường GHI cố ý tắt (G370): Save() = Save(CreateFromCurrentState()); hàm tạo snapshot lớn (245 lời gọi, 112 field) còn là stub. 45 field là nghịch đảo cơ học của đường nạp, 64 cần đọc riêng. Một cây ghi dở dang sẽ ghi đè save thật bằng null (12 field ngày giờ, level nâng cấp, level prestige ⇒ mất prestige) — tệ hơn không ghi. Kế hoạch: sửa 3 residual nhìn thấy được trước, rồi cây ghi với cổng phía ghi riêng (đủ 112 field + mọi SaveData_return, 0 stub), rồi mới bật Save(); nghiệm thu = nạp save thật → ép ghi → diff từng field với file gốc (chỉ timestamp/dẫn xuất được khác, mỗi cái phải giải thích).

Kinh tế offline — 12 luật đã VERIFIED và một ví dụ với số thật (đợt 7, G382)

Đây là mô hình kinh tế thứ hai của game (doc 01 §5.8 / doc 09 §4b) — nay đọc trọn từ binary và kiểm chứng bằng oracle: một harness Python độc lập (mô phỏng chính xác số học InfVal + float32) chạy trên save thật cho ra cùng 17 chữ số với game gốc. Vì R6a (kinh tế phải chạy độc lập), đây là mẫu để bạn viết simulator của mình.

Ví dụ với số thật (save Stage 2-2, mốc 22, nâng cấp [36, 36, 35], Money 2 497 189.34, súng lục Damage 100 / AtkSpeed 0.6, không skin/pet/relic/cá, vắng mặt 802.99 s):

Thời điểm được trả suy ra từ elapsed (mốc tin cậy + 802.993 s = 20:19:28.370Z) trùng độc lập với dấu autosave của game gốc ⇒ elapsed được kiểm chéo, không phải khớp cưỡng (G1005). Hai điều đáng học: prestige và bộ sưu tập vẫn sinh lợi khi tắt game (chỉ buff quảng cáo thì không — offline không phải kênh bán buff), và cày lại wave cao nhất nghĩa là offline không bao giờ "chơi hộ" tiến độ mới — người chơi phải tự mở stage kế.

Công thức / pseudocode

// ---- L1 ANALYSIS (doc 07 §2.8, G328/G330) — thứ tự nạp save ----
Load(data):                                                           // thứ tự đầy đủ, 91 call (G359/G361)
    if data == null: InitNewGame(); AllowSave(); return
    A  tiền tệ  : Money, Money_Accum, Ruby (InfVal); Dia, _getDia, _useDia (Obscured); PetCoin; TotalPlayTime; is_TimeHacker; OfflineFail*
    B  đồng hồ  : SavedOffsetSec, HasSavedOffset, LastTrustedUtc, Ledger, TimeStrike*, UsedCodes_Log
                  RỒI MỚI Time_manager.Init()   // sau khi offset/ledger đã có
                  ServerConfig.LoadFromSaveData(); TimeHack_* ; Rank_btn.SetActive(false) nếu bị gắn cờ chỉnh giờ
    C  nâng cấp : Upgrade_manager.LoadData(); Rebirth_manager.LoadData(); Rebirth_Count
    D  súng     : chép TỪNG PHẦN TỬ, chặn theo độ dài; AD_Gun_*; Gacha_Draw_Count; AD_Gun_OnLoaded(); Has_Merged back-fill
    E1 pet      : LoadLockGroups(); Pet_Reload()
    E2 stage    : Stage_Now + Level_Now (1 lệnh 8 byte), Stage_Value_Max, LoadSentWaveRatios(); Skin_Unlock, Selected_num, Skin_Value_Reload()
    F  cá/relic : FishInventory, UpdateStatTexts(); Relics (+ Balance_Reload NẾU bảng null) ; Value_Reload()
    OfflineProgressManager.EvaluateAndApply(data, ContinueLoad)        // offline TRƯỚC, rồi mới… (không có instance ⇒ ContinueLoad thẳng)

ContinueLoad(data):                                                   // 35 restore trực tiếp + fan-out
    Tree_manager.Game_Start(); Contents_Lock_Reload()
    StepUp/DailyGun/PlusPack/Shop/FreeCash .LoadFromSaveData(data)     // chép phòng thủ (min độ dài, mảng mới trước, "" thay null)
    Buff_manager.LoadBuffTimes(money, power)                           // Clamp(0, 900) — chú ý: đọc power TRƯỚC money
    DiaPig.Init(data.diaPig)                                           // null ⇒ chỉ neo đồng hồ, KHÔNG tích luỹ
    Setting.UI_Reload(); Rank_manager.Login(); Tutorial_manager.SetCleared() if TutorialCleared
    DailyCheck.First_reload(…); Fish_Tank.ReloadAll()                  // tank ẩn ⇒ hoãn
    Adventure: Lv, Exp, Ticket_Now, mốc nạp vé, Maps (vòng lặp lồng, chặn cả hai cấp)
    Mission_manager.Reload(…)                                          // is_Vip là STATIC
    Time_manager.MarkSaveLoaded(); Cat_manager.Skin_Reload(); Cat_manager.Balance_Reload()
    SaveSystem.AllowSave()                                             // <-- CUỐI đường nạp, không sớm hơn
    OfferWall.OnSaveLoaded(); ServerConfig.OnSaveLoaded(); [R1] log launch

// ---- L1 ANALYSIS (doc 01 §5.8, G332/G334) — cửa sổ offline ----
ComputeElapsed(data, out elapsed, out absent):
    if PendingCountPrefix("offline:") > 2: return false               // chống lạm dụng
    now  = trusted ? Time_manager.UtcNow : DateTime.UtcNow
    last = trusted ? parse(LastTrustedUtc, "o") ?? LastSaveTime : LastSaveTime
    total  = (now - last).TotalSeconds                                 // absent  = total (hiển thị)
    capped = min(total, 28800 + Relic.Offline_Value * 60)              // elapsed = capped (trả tiền)
    if total < 0: capped = 0                                           // đồng hồ lùi
    return capped >= 30                                                // sàn 30 s

EvaluateRoutine():
    if !ComputeElapsed(…): ShowResult(); return                        // lần 1: cổng rẻ, kết quả BỎ
    yield Time_manager.WaitForCheck(5f)                                // chờ reconcile giờ máy chủ
    UI_manager.Loading_On()
    if !ComputeElapsed(…, out elapsed, out absent): Loading_Off(); ShowResult(); return   // lần 2: giá trị ĐƯỢC TRẢ
    Time_manager.RecordGain(string.Format("offline:{0:F1}h", elapsed / 3600f))
    yield OfflineProgressSimulator.RunCoroutine(data, elapsed, absent)
    ApplyToManagers(); Loading_Off(); ShowResult()

// ---- Gợi ý framework (không phải SOT) ----
ISaveSlot     : Load() -> Restore(all systems, ORDER declared) -> AllowSave()   // AllowSave là bước cuối, tự động
IRestoreGuard : Clamp(timers), NullSaveResetsAccumulators, DefensiveCopy(min length, fresh array, "" not null)
IOfflineClock : (elapsedCapped, absentTrue) tách bạch; gate rẻ trước UI; tính lại SAU khi đồng bộ giờ

Bẫy đã gặp

• Bật nạp save khi restore mới xong một nửa. Save của người chơi cũ được đọc, khôi phục thiếu, rồi autosave 10 s ghi đè bằng trạng thái thiếu — mất nhiều giờ chơi trong im lặng. Đây là lý do dự án giữ một "cổng lật" (đếm số method còn rỗng trên đường nạp) và chỉ bật SaveSystem.Load khi cổng về 0 (G330).
• Cổng lật báo "mở" mà thật ra chưa (G355 → G359). Nghiệm thu trên save thật: 8/38 field nạp ra 0 (tiền, stage, level nâng cấp) trong khi game gốc nạp đúng cùng file. Hai nguyên nhân: Load chỉ là dispatcher 10 dòng (SOT: 91 call), và một coroutine return null làm StartCoroutine ném NRE cắt ngang ContinueLoad. Kiểm toán stub phải đọc thân hàm và đi theo StartCoroutine; điều kiện lật là 38/38 field khớp trên save KHÔNG mới, không phải số stub. May mắn duy nhất: AllowSave nằm sau chỗ NRE nên autosave chưa kịp ghi đè — sửa NRE mà không sửa Load thì sẽ ghi đè.
• Gọi hàm sinh bảng vô điều kiện trên đường nạp. Exp_Balance_Reload chỉ được gọi khi mảng scene null/rỗng; gọi luôn là ghi đè đường cong designer mỗi lần nạp (G361). Và sửa chỗ đó đã gộp nhầm hai nhánh (mới / restore) của khối Trip — sau mỗi sửa trên đường nạp, đọc lại các rẽ nhánh quanh nó (G372).
• Một helper parse ngày còn stub = mọi ngày trong save đều năm 1. Nghiệm thu chỉ thấy một triệu chứng (mốc vé Trip); đếm điểm gọi của helper (15) trước khi sửa tại chỗ (G372).
• Sự kiện thay đổi tiền tệ bất động. Công cụ decompile render event thành accessor rỗng ⇒ mọi += không làm gì, HUD số dư không bao giờ làm mới mà không có ngoại lệ nào (14 event / 9 file). Nếu HUD "đứng im", kiểm event trước khi kiểm kinh tế (G376).
• Một ngoại lệ trước continuation nuốt cả nửa sau của việc nạp. Bước offline ném ⇒ ContinueLoad không chạy ⇒ 8 field ngày còn năm 1, trông hệt "lỗi restore ngày". Khi nhiều field cùng ở mặc định, tìm điểm ném sớm nhất trước khi sửa từng field (G400).
• "Hồi quy" có thể là quy trình test. Đẩy file save vào trước khi app tạo thư mục (cài mới) ⇒ app không đọc được. Quy trình: cài → chạy 1 lần → dừng → đẩy file → kiểm md5 → chạy lại (G399).
• Start của Unity chạy trước khi save được nạp. Quyết định "vào tutorial hay không" trong Start đọc Upgrade_Lv chưa restore ⇒ save cũ bị bắt đầu tutorial; đường nạp phải gọi lại (SetCleared → CompleteTutorial) (G375).
• Tin bảng trích tự động cho đường nạp. Bộ trích thanh ghi gán nhầm cả khối Mission_* cho Adventure_manager; siết chặt chỉ làm nó giấu lỗi (10 hàng → 2 hàng). Đổi công cụ (decompiler), chứng minh từng hàng (G328, G329).
• Đặt AllowSave "đâu đó gần cuối". Binary chỉ có hai vị trí; sớm hơn một dòng là mở cửa sổ ghi đè.
• Quên rằng ctor cũng là code. _moneyCache, _textCooldowns, Dia_FirstBuy_Used, GameTime_Max = 180 đều là khởi tạo field bị công cụ decompile bỏ rơi; thiếu chúng là NRE — hoặc tệ hơn, màn thua ở frame 1 mà không ném gì (G306, G319, G350; doc 08 §3.6).
• Xoá "lời gọi trùng" ComputeElapsed. Lần 2 mới là lần sau đồng bộ giờ; bỏ nó = trả tiền theo giờ thiết bị chưa kiểm — chính cửa sổ chỉnh giờ mà WaitForCheck tồn tại để đóng (G334).
• Cho save null đi chung nhánh với save thật ở mọi thứ tích luỹ theo thời gian. DiaPig.Init cố ý bất đối xứng; chép "đối xứng cho gọn" là tặng dia miễn phí cho người xoá save (G327).
• Parse timestamp không ép về UTC. Chuỗi mang offset bị hiểu là giờ địa phương ⇒ khoảng vắng bị thổi phồng vài giờ.
• Danh tính khách chỉ lưu khi đăng ký thành công. SOT lưu trước; đổi sang "chỉ lưu khi thành công" là mỗi lần chạy offline đúc một danh tính mới (G323).

Checklist khi tự làm

• [ ] AllowSave() là bước cuối của cả hai đường (InitNewGame và ContinueLoad), không có chỗ thứ ba.
• [ ] Mọi timer có thể cấp thưởng (buff, vé, tick tiền) được kẹp ngay lúc nạp, không chỉ lúc cộng.
• [ ] Mọi bộ tích luỹ theo thời gian có nhánh save null riêng: reset + neo lại đồng hồ, không tích luỹ.
• [ ] Chép mảng từ save: min(độ dài lưu, độ dài mình); cấp mảng mới trước khi chép; chuỗi rỗng thay null.
• [ ] Timestamp: parse RoundtripKind, ép ToUniversalTime() khi chưa phải UTC.
• [ ] Offline: sàn (30 s) + trần (8 h + relic) + đồng hồ lùi ⇒ 0; tách elapsed (trả) khỏi absent (hiển thị).
• [ ] Offline: cổng rẻ trước UI, tính lại sau khi đồng bộ giờ; log và bộ đếm chống lạm dụng dùng chung tiền tố.
• [ ] Có một bộ field nghiệm thu save-load (tiến độ, kinh tế, quyền lợi, timer, danh tính, cờ) để diff hai bản trước khi tin đường nạp.
• [ ] Đọc .ctor / .cctor của mọi class trước khi cho rằng field "tự có".
• [ ] Danh tính khách: quyết định tường minh lưu trước hay sau khi đăng ký, và ghi lý do.

Điều chưa biết (UNKNOWN)

• Tầng đối chiếu trust trong Time_manager.Init (so TrustLevel, neo offset, reconcile máy chủ) — cố ý không tái hiện trong bản restore (anti-cheat, ngoài phạm vi); nội dung đã đọc nhưng không phải bằng chứng cho game của bạn (G321).
• Số học mô phỏng offline (CalcFarmMoneyPerSec, CalcMoneyPerStage, BuyAllAffordable) — chưa dựng lại; mới biết đầu vào và các bảng (doc 09 §5).
• ~~Bảng XP Trip nào sống sau khi nạp save~~ — ĐÃ GIẢI (G361): mảng scene (lưu dạng hex blob) sống; hàm sinh chỉ chạy khi mảng trống.
• ~~Nghiệm thu save-load 38/38~~ — ĐÃ CHẠY: 37/38 với 4 residual có tên (bảng "đã kiểm vs còn mở" ở trên, G367).
• Đường ghi save (112 field) — MỞ theo quyết định (fail-safe, G370); chưa có cây ghi nào được flip.
• ~~Save mới: 7 tích luỹ base-100 = 0~~ — ĐÃ ĐÓNG (G374): Relic_manager.Start / Skin_manager.Start đặt baseline; chờ build kế xác nhận.
• ~~Simulator offline chưa dựng~~ — ĐÃ DỰNG TRỌN và khớp oracle 17 chữ số ngoài thiết bị (G382). Còn chờ: khoản trả trên thiết bị (9 stub R13 ở file khác, G1002) và nghiệm thu lại residual (2).
• ~~Đường ghi save đang làm~~ — dựng xong (G388), 7 Clone đã ghim; chưa bật vì 6 getter inline + bỏ sót phía đọc (G389). Bảng trên.
• Tại sao một getter nhỏ lại quan trọng: Time_manager.UtcNow trả ngày mặc định là đủ để guard Phật lịch loại mọi ngày trong save và làm save mới dừng khởi tạo — bài học "getter inline là stub vô hình" (doc 08 §3.6).
• ~~Hệ điểm danh / retention (DailyCheck)~~ — ĐÃ DỰNG XONG (G378): quy tắc + bảng 70…1500 dia ở 11 §7; panel Ngày-2 trên save thật chưa nghiệm thu lại.
• Các field SaveData không được đường nạp đọc (nếu có) — chưa liệt kê; bản đồ hiện có phủ 22 + 5 + 35 field mà binary ghi vào manager.
• Nghiệm thu chéo: lần 1 FAIL 8/38 (đã sửa — G355/G359); lần 2 37/38 + 4 residual (G367). Chưa có lần nào 38/38.

Đọc thêm

• ../framework/07-progression-managers.md §2.8 — bảng 35 field + ba tầng phòng thủ, §3.2c — định dạng save và quy tắc khôi phục
• ../framework/01-economy-money.md §5.8 — kinh tế offline là mô hình thứ hai
• ../framework/09-prestige-rebirth.md §4b — offline và prestige, bảng Degree*
• ../framework/08-architecture-and-scale.md §3.6 — vì sao ctor bị bỏ rơi và hàm bị gộp
• 10 — Tiến trình & mở khoá — vé Trip, XP Trip, Game_Win