08 — Kiến trúc & quy mô

Nguồn: chưng cất từ restore SOT com.Chodun.CatGunner 1.1.59 (BardCat). Đây là tài liệu về hình dạng của một game idle đã ship: nó lớn cỡ nào, được đóng gói ra sao, và những quyết định kiến trúc nào phải trả giá về sau.

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

Ba câu: 1. Một game idle thương mại thực tế lớn đến mức nào, và cấu trúc ra sao? 2. Quyết định "một scene duy nhất" tốn kém những gì? 3. Một studio bảo vệ build của họ như thế nào — và điều đó dạy ta gì về việc ship?

2. Stable truths

2.1 Danh tính build

2.2 Quy mô scene — quyết định kiến trúc trung tâm

2.3 Chi phí của quyết định đó — đo được

2.4 Hình ảnh & hiệu năng

2.5 Bảo vệ khi ship (mục nội bộ, đã lược bỏ)

2.6 Package bên thứ ba

2.7 Hình dạng project sau khôi phục

3. Mô hình hành vi

3.1 Quyết định "một scene" — và hoá đơn của nó

Cái được: - Không có màn hình loading giữa các phần. Mở shop, vào mỏ, đánh boss — tức thì, vì mọi thứ đã ở trong bộ nhớ. - Không cần AssetBundle, Addressables, catalog, CDN, hay logic cache. Toàn bộ một tầng hạ tầng biến mất. - Không có lỗi tham chiếu chéo scene. Mọi singleton sống suốt vòng đời app (xem doc 07 §3.1).

Cái mất (đo được, không phải lý thuyết):

Và một hệ quả gameplay tinh vi — đây là chỗ kiến trúc rò rỉ vào code:

Vì kẻ địch, đạn và collider luôn tồn tại, không có gì ngăn combat chạy khi người chơi đang ở menu. Thứ duy nhất chặn là một cờ boolean toàn cục Gamemanager.is_gaming được kiểm ở từng entry-point. Trong quá trình dựng lại, Enemy.Damaged và Enemy.Die bị thiếu guard đó (bug G132b) — hậu quả sẽ là quái ăn damage và rơi tiền khi người chơi đang mở shop. Không crash, không lỗi hiện ra: chỉ là kinh tế sai một cách âm thầm. Chi tiết: doc 02 §3.5.

Bài học: kiến trúc một-scene đổi chi phí runtime lấy chi phí quy trình phát triển, và tạo ra một loại bug mới (rò rỉ trạng thái xuyên "màn hình") cần một guard toàn cục có kỷ luật.

3.2 Ngân sách hình ảnh — chọn giảm thứ người chơi không thấy

m_RenderScale: 0.7               # render ở 70% độ phân giải (49% số pixel) rồi upscale
m_UpscalingFilter: 1             # có bộ lọc upscale (FSR), FsrSharpness 0.92
m_MSAA: 1                        # TẮT
m_SupportsHDR: 0                 # TẮT
m_MainLightShadowsSupported: 0   # TẮT
m_AdditionalLightShadowsSupported: 0  # TẮT
m_ShadowDistance: 50
m_ShadowCascadeCount: 1
m_RequireDepthTexture: 1         # BẬT (có gì đó cần depth)
m_RequireOpaqueTexture: 0        # TẮT
m_EnableLODCrossFade: 0          # TẮT

RenderScale 0.7 là quyết định lớn nhất: nó cắt 51 % số pixel phải tô. Với một game 2.5D nghệ thuật phẳng, nhìn từ trên, chạy trên màn hình điện thoại mật độ cao, mất mát thị giác gần như không nhận ra — nhưng lợi ích fill-rate là khổng lồ, đặc biệt với 7 718 ParticleSystem.

Mọi thứ liên quan tới đổ bóng và HDR đều tắt. Nghệ thuật của game là sprite phẳng có viền; nó không cần bóng động. Bật RequireDepthTexture trong khi tắt RequireOpaqueTexture cho thấy có ít nhất một hiệu ứng cần độ sâu (viền/outline là ứng viên, xét package Outline Objects).

ASTC 6x6 cho hai trang atlas 4096×4096: đây là điểm ngọt cho sprite mobile — nhỏ hơn ETC2 nhiều mà chất lượng tốt hơn hẳn ở mức nén tương đương, và mọi thiết bị arm64 hiện đại đều hỗ trợ phần cứng. Tên file tự mã hoá định dạng (sactx-0-4096x4096-ASTC 6x6-Cat-ad05b281) — chi tiết nhỏ nhưng hữu ích cho việc kiểm tra sau này.

Chỉ 2 atlas cho toàn game (Cat 125 sprite, _UI 374 sprite) nghĩa là hầu hết UI vẽ trong rất ít draw call.

3.3 Bảo vệ khi ship (mục nội bộ, đã lược bỏ)

3.4 Hình dạng project sau khôi phục — và giới hạn thật của nó

(khối mã nội bộ đã lược bỏ)

Bài học từ nguyên nhân gốc ([report: reexport_lane.md] §1) đáng nhớ: đống dummy do hai vấn đề độc lập gây ra, và sửa một cái là không đủ. Kể cả với metadata đã giải mã, việc trỏ AssetRipper vào assets/bin/Data đơn lẻ vẫn cho ra dummy, vì nó không nhận ra cấu trúc game Android và không bao giờ chạy Cpp2IL. Cây staging phải là layout Android đầy đủ.

Và ranh giới trung thực, phải nhắc lại:

Cpp2IL dựng lại chữ ký và field, không bao giờ dựng lại logic. Update(), OnEnable(), ShootBullet() là { }. APK dựng từ export này là một vỏ cấu trúc: nó cài được, khởi động được, load được scene và asset thật, và không làm gì cả. Nó không phải một game đang chạy hay đã khôi phục.

Việc khôi phục logic là một lane riêng, và mọi thân method ở đó là L1 ANALYSIS — dựng lại clean-room từ ARM64 + quan sát runtime, không bao giờ là "source gốc".

Con số của lane đó cho thấy quy mô thật: 22 class đã ship trong tổng 731; trong đó chỉ 5 được xác minh bằng oracle field-delta trên thiết bị.

3.5 Xếp hạng ưu tiên bằng dữ liệu, không bằng cảm giác

Bài học phương pháp luận mạnh nhất của toàn bộ project:

(khối mã nội bộ đã lược bỏ)

Và runtime đảo ngược phỏng đoán tĩnh ở hai chỗ quan trọng:

Không có oracle runtime, lane khôi phục sẽ đổ công sức vào BulletShooter (0 giá trị) và bỏ qua SlicedFilledImage (class quan trọng nhất về hiệu năng). Đo, đừng đoán.

3.6 Bài học phương pháp khôi phục — đợt 3 (mỗi bài học là một lỗi thật đã trả giá)

Đây là phần "method" của bộ tài liệu: cách các sự thật ở doc 01/05/07 được lấy ra, và bẫy nào đã cắn. Mỗi mục trích ledger gap list (nội bộ).

4. Framework takeaway

1. Cấu trúc scene là quyết định kiến trúc đắt nhất và khó đảo ngược nhất. Một scene = không loading, không hạ tầng bundle, nhưng: 481 MB, > 30 phút import, không merge được, và trạng thái rò rỉ xuyên màn hình. Framework nên hỗ trợ mô hình lai — một scene lõi bền + các màn hình phụ tải thêm — và đo chi phí import ngay từ đầu, không phải khi đã 481 MB.

2. Nếu chọn một-scene, guard trạng thái toàn cục phải là hạ tầng bắt buộc. is_gaming không được là một dòng if mà mỗi người phải nhớ chép. Nó phải là một cổng ở tầng framework (base class, hoặc IDamageable gate). Bằng chứng: bug G132b.

3. Ngân sách hình ảnh: giảm thứ người chơi không nhìn thấy, giữ thứ họ thấy. RenderScale 0.7 (−51 % pixel) + tắt toàn bộ bóng/HDR/MSAA + 2 atlas ASTC 6x6. Đây là một cấu hình mobile đã ship, đáng dùng làm mặc định cho game 2D/2.5D.

4. Ít atlas lớn, định dạng mã hoá trong tên. 2 atlas × 4096² phục vụ 499 sprite.

5. Bảo vệ là quản trị rủi ro, không phải bức tường — và mỗi lớp chỉ chặn một loại tấn công. ACTk (sửa bộ nhớ). Save plain-text là một lỗ trống có chủ đích — hợp lý cho idle single-player, đáng chất vấn khi có bảng xếp hạng. Hãy nêu rõ mô hình mối đe doạ của từng lớp; đừng gộp thành "game này có bảo vệ". Mã hoá 55 % metadata + đổi tên export chặn được mọi công cụ tự động — đó là giá trị thật. Nó không ngăn được người quyết tâm, vì key phải nằm trong binary. Hãy hiểu rõ mình mua gì. Và đừng trộn hai mối đe doạ: chống dịch ngược (metadata) và chống phân phối lại (license) là hai bài toán khác nhau, hai lớp khác nhau.

6. Khi hook, can thiệp vào quyết định, không vào hậu quả.

7. Xếp hạng công việc bằng dữ liệu quan sát, không bằng tên. Điều tra scene + topology manager (tĩnh) → thu hẹp; trace runtime (động) → xếp hạng. Runtime đảo ngược phỏng đoán ở những chỗ quan trọng nhất.

8. Mua package thật; ghi lệch version, đừng giấu. 8 package thương mại, không cái nào bị stub. 3 cái có rủi ro lệch version và được ghi thành gap (G117/G118/G122). Với package serialize vào scene (như InfVal), kiểm layout field trước khi tin dùng — một field bị đổi tên sẽ âm thầm xoá sạch dữ liệu kinh tế.

9. Trung thực về việc "khôi phục" nghĩa là gì. Chữ ký + field ≠ hành vi. Một APK build được, cài được, chạy được và không làm gì là một vỏ cấu trúc, không phải một game đã khôi phục. Hãy nói đúng như vậy.

10. Cây staging phải phản ánh layout thật của nền tảng. assets/bin/Data và lib/arm64-v8a/ phải đi cùng nhau, nếu không công cụ sẽ không nhận ra cấu trúc game và âm thầm bỏ qua bước quan trọng nhất.

5. Negative evidence & UNKNOWN

6. Raw evidence

• [shared facts nội bộ] — danh tính, hash, cipher metadata (mục "CORRECTED FINDING"), kiểm kê code
• [report: asset_lane.md] — thống kê scene, kiểm kê asset, định dạng texture, audio, Spine
• [report: reexport_lane.md] — nguyên nhân gốc dummy, thay thế metadata, so sánh trước/sau
• [report: project_lane.md] — pin Editor, manifest package, PlayerSettings, kết quả gate
• [report: codegen_lane.md] — xếp hạng ưu tiên, oracle runtime, trạng thái khôi phục
• [restore project: Mobile_RPAsset.asset] — cài đặt URP (m_RenderScale: 0.7)
• [index: scene_census.json], priority_static.json} — điều tra scene + xếp hạng
• [runtime trace: runtime_ranking.json] — 505 method đã chạy
• [tài liệu nội bộ: check_singletons.py], check_no_meta.py}, [restore project: verify_script_guids.py] — ba gate đứng sinh ra từ §3.6
• [native: libil2cpp.so.split.i64] (IDB đã tách 87 hàm gộp) · libil2cpp.so.pristine.i64 (bản gốc đóng băng, sha256 e8273f34…)
• Gaps: G013, G014, G027, G028, G101, G107, G117, G118, G120, G122, G129, G131, G132b; đợt 3: G296–G297, G306–G308, G314–G315, G319–G324, G328–G329, G334, G345–G348, G350, G353, G601, G702 trong gap list (nội bộ)