05 — Nhân vật, Pet & Kẻ địch

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.

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

Màn hình idle phải đông và sống: một đàn mèo bám theo người chơi, một bầy pet lượn quanh, hàng nghìn mục tiêu chờ bị bắn. Tất cả phải tự di chuyển mà không giẫm lên nhau, và phải chạy 60 fps trên điện thoại. Đây là mô tả cách CatGunner làm điều đó.

Hai class flocking (Cat_manager, Pet_Ingame_manager) nằm trong nhóm chạy nhiều nhất toàn game: Pet_Ingame_manager 20 038 lời gọi / 40 giây, Cat_manager 9 577.

2. Stable truths

2.1 Mèo (nhân vật người chơi + đồng đội AI)

2.2 Pet (bầy boids)

2.3 Kẻ địch

2.4 Camera, khung nhìn và "vòng chơi" đo trên thiết bị (đợt 4)

3. Mô hình hành vi

3.1 Đàn mèo — leader + follower, tách ra hai tầng

Cat_manager (11 method, 1 instance)          <- tầng ĐÀN
    Cat_list[0]      = mèo người chơi
    Cat_list[1..n]   = follower AI
    Update()         -> ComputeSeparation()   (mỗi frame, 4 776x/40s)
    SetupFormation() -> tính FormationOffset cho từng follower quanh leader
    AddFollower / RemoveFollower / Warp / Skin_Reload / Balance_Reload

Cat (~100 field, ~50 method, n instance)     <- tầng CÁ THỂ
    máy trạng thái AIState: Follow / Chase / AttackStay / Reposition / Assist / Fidget
    hệ ngắm: FindNearestEnemyByRaycast (RayCount 8..72) -> ResolveAttackTarget -> Attack
    hệ bắn:  ApplySpread -> TrySpawnBulletEx | TryFireShotgun | TryFireMissile
    hệ tay/mặt: UpdateHandRotation / UpdateFaceRotation / FaceTowardEnemy

Sự phân chia này là điểm học chính: manager chỉ lo quan hệ giữa các cá thể (đội hình, đẩy nhau), cá thể lo hành vi của chính nó (ngắm, bắn, đi). Không có "AI trung tâm" điều khiển từng con.

Chống rung trạng thái là chi tiết chuyên nghiệp đáng chép lại:

HysteresisMargin  [Range(0.05, 0.3)]   ngưỡng đổi trạng thái có vùng chết
MinStateDuration  [Range(0.1, 1.0)]    thời gian tối thiểu ở một trạng thái
_stateTimer                            đếm ngược

Không có hai thứ này, một follower đứng đúng ranh giới FollowIdealDist sẽ nhấp nháy giữa Follow và AttackStay mỗi frame. Tên field tiếng Hàn trong code (버벅거림 방지 = "chống giật") cho thấy đây là bản vá cho một bug thật.

Breadcrumb + lịch sử có độ trễ giải bài toán "follower đi xuyên tường":

static List<Vector3> Breadcrumbs      // leader thả vệt mỗi RecordDist = 0.5 đơn vị
const int MaxCrumbs      = 100        // giữ 100 điểm gần nhất
const int CrumbLookahead = 5          // nhắm tới điểm thứ 5 phía trước, không phải điểm ngay sau
Queue<PosRecord> _leaderHistory       // + HistoryDuration = 2 s
GetLaggedLeaderPos()                  // vị trí leader cách đây X giây

Follower đi theo đường mà leader đã thực sự đi qua, không đi theo đường thẳng tới leader. Đó là lý do đàn mèo trông như một đoàn rắn chứ không như một đám xúm lại. CrumbLookahead = 5 cho phép cắt góc nhẹ để không trông máy móc.

Fidget (AIFidget, _fidgetTimer, _fidgetInterval, _fidgetOffset) là thứ biến một đàn đứng yên từ "tượng" thành "sinh vật": khi không có việc gì, mỗi con dịch một chút theo chu kỳ ngẫu nhiên.

3.1b Auto-move — mèo tự đi tới mục tiêu (batch C, đợt 4)

12 method (HandleAutoMove 0x2AE8278 4 404 B, HandleMovement 0x2AE6BF0, SmoothMoveTowardWithAvoidance 0x2AEA4A4, ClampToMonsterRadius 0x2AE93AC, RecordBreadcrumb 0x2AE67F0, GetBreadcrumbTarget 0x2AED0C4, ScreenSpeedMultiplier 0x2AE5020, …) — disasm-proven, dự đoán trước khi build và khớp trên thiết bị (G356 → G358).

HandleAutoMove:                                        // mode-aware
    Main      : mục tiêu = cây gần nhất theo lưới; đi tới, DỪNG CÁCH 8 đơn vị (AutoZOffsetMax = -8)
    SpeedRun  : khoá mục tiêu bắn (không đổi cây giữa chừng)
    Raid      : mục tiêu = _boss
    Monster   : đứng trên VÀNH đấu trường bán kính 14 (ClampToMonsterRadius); lùi khi trong MinEnemyDist tới +0.5
    tốc độ thực ~14.4 u/s  ->  tới cây (-102.5, 0, 27.5) từ (-100, 0, 0) mất ~1.4 s (đo: 5 -> 12 cây vào khung)

ScreenSpeedMultiplier:                                 // triệt tiêu foreshortening isometric (CamPitchSin 0.57735)
    stick.x / ScreenSpeedK ; stick.z * ScreenSpeedK    // ánh xạ BẤT ĐỐI XỨNG: ngang chia, dọc nhân

Breadcrumbs (static, DÙNG CHUNG cho cả đàn):
    leader thả 1 vệt / 0.5 u, giữ tối đa 100; follower nhắm vệt thứ 5 phía trước (cắt góc nhẹ)

Ba tail byte-identical (drive / face / stop) trong HandleAutoMove được tách thành helper L1 (AutoDrive, FaceAlong, StopAndFaceTarget) — cùng mã máy, chỉ khác tên. Bài học phương pháp kèm theo: xác nhận callee từ lệnh BL, không từ nhãn trong overlay (G356).

3.1c AI follower — vệt leader có độ trễ, hai lớp chống rung (batch D, đợt 5)

RecordLeaderHistory (leader, mỗi frame):   push (pos, t) vào lịch sử STATIC dùng chung; cắt bỏ mục cũ hơn 2 s
GetLaggedLeaderPos (follower):             đọc vị trí leader tại t - _lagSeconds   // _lagSeconds ∈ [0.15, 0.6], rút 1 lần/instance
EvaluateDesiredState(leader, dist):
    băng của trạng thái ĐANG GIỮ được nới thêm HysteresisMargin (×(1+k))       // lớp 1: không đổi khi chỉ vừa chạm ngưỡng
HandleAI:
    if (_stateTimer < MinStateDuration) giữ trạng thái                          // lớp 2: tối thiểu thời gian ở một trạng thái
    Follow / Chase / AttackStay / Reposition / Assist (xích 0.85·FollowMaxDist) / Fidget
HandleAIMonster: không leader — mỗi mèo giữ một TRẠM trên vành bán kính 14 (cùng vành với auto-move §3.1b)

Vì sao là vệt chứ không phải điểm: ba follower cùng đọc một lịch sử ở ba độ trễ khác nhau tự nhiên xếp thành đoàn rắn, không cần offset đội hình phức tạp; độ trễ rút từ GetInstanceID() nên tất định giữa các lần chạy — thứ tự đoàn không đổi ngẫu nhiên mỗi lần vào game.

3.2 Hệ spread — tản đạn theo nhịp bắn

SpreadAngleMin / SpreadAngleMax      biên độ tản
SpreadGrowthRate      [Range(0.1, 0.6)]   Lerp tăng mỗi phát bắn
SpreadDecayMultiplier                     giảm khi ngừng (maxAngle * hệ số / giây)
_spreadAngle                              trạng thái hiện tại
_prevHadTarget                            biết lúc nào chuyển từ bắn sang ngừng
Debug_SpreadAngle / Debug_SpreadMaxAngle  [Header("Spread Debug (Read Only)")]

Hai điều đáng học: 1. Spread max phụ thuộc tốc độ đánh — tooltip gốc nói rõ: 스프레드 최소(가장 느린 공속) 각도 ("góc tản nhỏ nhất = tốc độ đánh chậm nhất"). Bắn càng nhanh, tản càng rộng. Đây là một cơ chế cân bằng tự nhiên: nâng cấp tốc độ đánh không phải là lợi ích thuần. 2. Có field debug read-only ngay trong inspector. Một hệ thống cảm-giác chỉ chỉnh được nếu nhìn thấy được. Framework nên chuẩn hoá [Header("... Debug (Read Only)")].

3.3 Boids pet — ba lực, tính mỗi bước vật lý

// L1 ANALYSIS — Pet_Ingame_manager.FixedUpdate (disasm-proven, chạy 4 006x/40s)
Cat mainCat = GetMainCat();
if (mainCat == null) return;
Vector3 pos = mainCat.transform.position;
float inst = Vector3.Distance(pos, _prevMainCatPos) / Time.fixedDeltaTime;
_smoothedCatSpeed += (inst - _smoothedCatSpeed) * 0.12f;      // làm mượt hàm mũ
_prevMainCatPos = mainCat.transform.position;
ComputePetSeparation();
ComputeCatAvoidance();
MovePets(mainCat);

Hệ số 0.12 là một bộ lọc thông thấp bậc một: pet phản ứng theo tốc độ trung bình của mèo trong khoảng ~8 bước vật lý, không theo tốc độ tức thời. Nếu dùng tốc độ tức thời, pet sẽ giật mỗi khi người chơi nhả joystick. Đây là hằng số cảm-giác quan trọng nhất của hệ pet.

Ba lực (thuật toán đã giải mã, xem cảnh báo ở §5):

# 1. Tách nhau giữa pet (từng cặp i<j, chỉ pet đang active)
d = Pets[i].pos.xy - Pets[j].pos.xy;  dist = |d|
if 0.001 <= dist <= PetSeparationRadius:
    f = normalize(d) * ((1 - dist/PetSeparationRadius)^2 * PetSeparationStrength)
    Pets[i].SeparationForce += f
    Pets[j].SeparationForce -= f

# 2. Né mèo (mỗi pet, với mỗi mèo đang active)
d = pet.pos.xy - cat.pos.xy;  dist = |d|
if 0.001 <= dist <= CatAvoidRadius:
    pet.CatAvoidanceForce += normalize(d) * ((1 - dist/CatAvoidRadius)^2 * CatAvoidStrength)

# 3. Di chuyển (MovePets)
    FormationOffset + SeparationForce + CatAvoidanceForce
    + trễ Start/StopMoveDistance (hysteresis)
    + kẹp [MinSpeed, MaxSpeed], FullSpeedDistance
    + CatSpeedMultiplier * _smoothedCatSpeed
    -> rb, và điều khiển animation Spine (IsMoving / _currentAnim)

Chi tiết đáng học: hàm suy giảm là bình phương (1 - dist/radius)^2, không tuyến tính. Lực gần như bằng 0 ở rìa bán kính và tăng vọt khi rất gần — nên pet không "đẩy nhau từ xa" nhưng cũng không bao giờ chồng lên nhau. Và tính toán chỉ dùng 2D (x, y) dù thế giới là 3D: mặt phẳng chiếu là đủ cho một game nhìn từ trên, và rẻ hơn hẳn.

Start/StopMoveDistance là hysteresis: pet bắt đầu đi khi cách xa hơn StartMoveDistance, nhưng chỉ dừng khi gần hơn StopMoveDistance (< StartMoveDistance). Cùng ý tưởng chống rung như ở Cat.AIState.

3.4 Kẻ địch — một Enemy chung + dispatch component

// Enemy.Die_Reload — RVA 0x2AFF354
switch (_type)
{
    case Type.Tree:          GetComponent<Tree>().Die_Reload();          gameObject.SetActive(false); break;
    case Type.Tree_SpeedRun: GetComponent<Tree_SpeedRun>().Die_Reload(); gameObject.SetActive(false); break;
    case Type.BossMonster:   GetComponent<Boss>().Die_Reload();          break;   // KHÔNG tắt
    case Type.Monster:       GetComponent<Monster>().Die_Reload();       break;   // KHÔNG tắt
    case Type.Ore:           GetComponent<Ore>().Die_Reload();           break;   // KHÔNG tắt
    case Type.RaidBoss:      GetComponent<Raid_Boss>().Die_Reload();     break;   // KHÔNG tắt
}

Enemy giữ toàn bộ thứ chung: Health_Now, Health_Max, Money, is_Die, thanh máu Slider, hiệu ứng nảy _bounce. Component anh em giữ thứ riêng: cây rơi tiền và đẩy wave, quặng nhả dust và dia, quái bị knockback, boss có coroutine đi lang thang.

Chú ý sự bất đối xứng ở trên: chỉ Tree và Tree_SpeedRun bị SetActive(false) ngay tại Enemy. Bốn loại còn lại tự quyết định vòng đời của chúng bên trong Die_Reload riêng (Ore.Die_Reload kết thúc bằng gameObject.SetActive(false); Monster/Boss có thể cần chạy hiệu ứng chết trước). Đây là bằng chứng đọc được từ disasm, không phải suy đoán.

Ba component data-holder thuần (EnemyColl, Enemy_Slider, Gun) chỉ có .ctor — chúng tồn tại để liên kết ngược: EnemyColl.enemyScript cho phép một collider con tìm ra Enemy cha mà không cần GetComponentInParent (vốn đắt và chạy mỗi lần trúng đạn).

3.5 Quái vật — animation trên GPU

// Monster — dump.cs:594503
private MaterialPropertyBlock _mpb;                    // @0x40
private static readonly int ID_TimeOffset;             // @0xC
private static readonly int ID_AnimSpeed;              // @0x10
private static readonly int ID_ScaleAmount;            // @0x14

240 quái vật trên màn hình, không Animator nào. Thay vào đó mỗi con nhận một MaterialPropertyBlock với ba tham số: lệch pha thời gian, tốc độ animation, biên độ co giãn. Shader tự làm phần còn lại.

Vì sao đây là mẫu quan trọng cho idle: Animator tốn ~vài chục µs mỗi instance mỗi frame và không batch được. MaterialPropertyBlock giữ nguyên batching (cùng material) và chi phí gần bằng 0. ID_TimeOffset khác nhau cho từng con là thứ khiến 240 quái không đập cánh đồng loạt — một số ngẫu nhiên duy nhất thay thế cho 240 state machine.

3.6 Trạng thái wave và đường cong stage

Tree_manager:
    Stage_Now / Level_Now / Stage_Value_Max         tiến độ
    TreeCount_Now / TreeCount_Max                   wave hiện tại
    GameTime_Now / GameTime_Max                     đồng hồ đếm ngược màn
    gameSlider (GameSlider)                         thanh tiến độ
    _healthCache / _moneyCache  Dictionary<int, InfVal>
    const int PrecomputedStageCount = 5000
    static InfVal PowOfThree(int exp)
    GetStageHealth(stage) / GetStageMoney(stage)
    StageAdvance(ref int stage, ref int level)
    Game_Start / Game_Win / Game_Fail / Game_Restart / Game_Exit

Vòng đời một wave (disasm-proven; đợt 3 tách đúng biên hàm — G346):

// Tree.Die_Reload  0x2B43904  (184 B — chỉ hai dòng)
    Particle_Polling.instance.Spawn(MoneySpawn_trans.position, is_Boss ? 15 : 5)   // KHÔNG null-guard: binary dereference thẳng
    Tree_manager.instance.Tree_Destroyed()

// Tree_manager.Tree_Destroyed  0x2B439BC  (864 B — toàn bộ logic wave)
    if (!Gamemanager.is_gaming) return;                  <- guard bắt buộc (doc 02 §3.5)
    TreeCount_Now--
    ratio = (TreeCount_Max - TreeCount_Now) / TreeCount_Max
    gameSlider.Value_Reload(ratio)
    [R1 analytics: SendLog_WaveRatio CHỈ khi Stage_Now == 0 && Level_Now >= Stage_Value_Max,
     mốc 10 % (decile), dedup HashSet<string> khoá "{stage}_{level}_{percent}"]
    if (TreeCount_Now <= 0) Game_Win()                   // private, cùng class
    Mission_manager.instance.MissionValue_Increase(Mission_Type.TreeCount)

Game_Win (0x2B452E4, 1 144 B — G347):

    if (!is_gaming) return;  is_gaming = false
    _stageTimeAll += realtimeSinceStartup - _roundStartTime
    gameSlider.Value_Reload(1f)
    (stage0, level0) = (Stage_Now, Level_Now)                     // chụp trước khi tiến
    StageAdvance(ref Stage_Now, ref Level_Now)                    // 5 level / stage
    // RELIC "SKIP": Relic_manager.Skip_Value (static +0x6C) là % cơ hội
    if (Random.Range(0, 100) < Skip_Value && Level_Now + 10*Stage_Now < Stage_Value_Max)
        StageAdvance(...)  lần 2                                   // skip KHÔNG BAO GIỜ vượt mốc cao nhất từng đạt
    _pendingGameSkipUI = <kết quả skip>
    if (Level_Now + 10*Stage_Now >= Stage_Value_Max):             // lập kỷ lục
        Stage_Value_Max = Level_Now + 10*Stage_Now
        if (!is_ProgramDestroyed) Rank_manager.SubmitScore(false, null)   // [R1]
        Contents_Lock_Reload()
        SendLog_WaveClear();  if (level0 == 4) SendLog_StageClear(_stageTryCount)   // [R1]
    Sound_manager.PlaySfx(Win);  MissionValue_Increase(StageClear)
    GameWin_UI.SetActive(true);  Loading_Then_Start()

Hai chi tiết đáng học: (1) relic Skip chỉ nhảy trong vùng đã chinh phục (< Stage_Value_Max) — nó rút ngắn cày lại sau rebirth chứ không đẩy tiến độ mới; (2) _stageTimeAll cộng dồn thời gian thực mỗi màn — nguồn cho analytics, không phải cho kinh tế.

Đặt cây (Tree_Grid.Spawn 0x2B43D28 — G343):

    order = [0..99].OrderBy(i => Morton(i % 10, i / 10))         // Z-order curve: Spread(x) | (Spread(z) << 1)
    acc = 0; for k in 0..want-1: acc += total; pick order[acc / want]   // lấy `want` ô CÁCH ĐỀU trên đường cong
    mỗi cây: localPosition = (5*j - 50*(j/10) + jitter, 0, 5*(j/10) + jitter), jitter ∈ ±randomRange

Đọc nhầm comparer thành "xáo trộn" rồi thay bằng Random sẽ cho cây tụ đám — đúng thứ SOT cố tránh.

Hai chi tiết kiến trúc: bộ đếm wave là một số nguyên duy nhất (TreeCount_Now), và tỉ lệ tiến độ được tính lại từ nó mỗi lần — không có state trùng lặp. Còn _sentWaveRatioKeys (HashSet chuỗi) đảm bảo mỗi mốc analytics chỉ gửi một lần cho mỗi (stage, level, percent).

Đường cong stage được tính trước 5 000 stage và cache trong dictionary. Kết hợp với PowOfThree(int) (luỹ thừa 3), điều này gợi ý máu/tiền tăng theo bậc 3 — nhưng công thức chính xác là UNKNOWN (xem §5).

4. Framework takeaway

1. Tách "quan hệ giữa các cá thể" khỏi "hành vi của cá thể". IFlockManager : đội hình, lực tách nhau, thêm/bớt thành viên (chạy mỗi frame/bước vật lý) IFlockMember : máy trạng thái riêng, nhận lực, tự di chuyển Đây là lý do một class 11 method (Cat_manager) quản được một đàn mà không thành God object.

2. Chống rung là hạ tầng, không phải bản vá. Mọi ngưỡng chuyển trạng thái cần hysteresisMargin + minStateDuration; mọi ngưỡng khoảng cách cần một cặp start/stop. Framework nên phơi ra một kiểu HysteresisThreshold thay vì để mỗi người tự nhớ.

3. Làm mượt hàm mũ cho mọi tín hiệu đầu vào của chuyển động. smoothed += (instant - smoothed) * k với k = 0.12 là một hằng số cảm-giác đã được kiểm chứng trên một game đã ship. Đừng dùng giá trị tức thời.

4. Đi theo vệt đường, không đi theo đường thẳng. Breadcrumb (RecordDist, MaxCrumbs, CrumbLookahead) là cách rẻ nhất để follower trông thông minh mà không cần pathfinding.

5. Lực suy giảm bình phương, tính trong 2D. (1 - dist/radius)^2 cho ranh giới mềm ở rìa và đẩy mạnh khi sát nhau. Với game nhìn từ trên, chiếu về 2 chiều và tiết kiệm một nửa chi phí.

6. MaterialPropertyBlock + lệch pha thời gian thay cho Animator khi có hàng trăm instance. Ba tham số (timeOffset, animSpeed, scaleAmount) đủ để một đám đông trông sống động. Đây là kỹ thuật có tỉ lệ hiệu quả/chi phí cao nhất trong toàn bộ tài liệu này.

7. Một component "kẻ địch" chung + dispatch tới component chuyên biệt. Máu/tiền/thanh máu/hiệu ứng nảy là chung; vòng đời và phần thưởng là riêng. Cho phép loại chung uỷ quyền vòng đời cho loại riêng, đừng ép mọi loại chết giống nhau.

8. Component "liên kết ngược" (EnemyColl.enemyScript) thay cho GetComponentInParent trên hot path.

9. Field debug read-only trong inspector cho mọi hệ thống cảm-giác. Không nhìn thấy thì không chỉnh được.

10. Tính trước và cache đường cong tiến độ. PrecomputedStageCount = 5000 + Dictionary<int, InfVal> — đường cong idle được truy vấn liên tục; đừng tính lại luỹ thừa mỗi lần.

11. "Bể" thực thể trang trí = POOL CỐ ĐỊNH bằng đúng trần kho, không phải Instantiate/Destroy. Mẫu đọc được ở Fish_Tank (bể cá 20 ô, docs/functions/ca-fish.md): fishPool là mảng dựng sẵn trong scene, đúng MAX_FISH phần tử; Awake gọi Init(this) + Deactivate() cho từng ô; thêm một thực thể = GetInactiveItem() rồi Reload(grade, invIndex); xoá = Deactivate(). Không có Instantiate nào ở runtime, không có GC spike khi người chơi rút liên tục, và trần kho tự thực thi bằng kích thước mảng — GetInactiveItem() trả null là hết chỗ, không cần một if thứ hai. Đổi lại: pool và trần phải khớp nhau, nên trần nên là một const duy nhất mà cả hai cùng đọc. Kèm theo: chỉ số kho (inventoryIndex) là dữ liệu, tham chiếu item là tạm bợ. Sau mỗi lần xoá, SyncInventoryIndices() gán lại chỉ số cho mọi item đang sống bằng cách bắt cặp theo hạng với một mảng bool[] used (mỗi ô kho chỉ dùng một lần); item không tìm được ô nào thì ở lại -1. Đây là cách an toàn khi lưới có thể bị dựng lại dưới chân coroutine — cùng bài học với mục 1 của docs/functions/pet-drag-fuse.md §6.

12. Rải chỗ trống bằng "thử N lần, giữ chỗ thoáng nhất" — đừng dùng lưới, đừng giải va chạm. best = randomPoint(); bestDist = -1 for (i = 0; i < maxAttempts; i++) { // Fish_Tank: 30 p = randomPoint() d = distanceToNearestActive(p, exclude: self) if (d >= minDistance) return p // Fish_Tank: 100 px — đủ thoáng, nhận NGAY if (d > bestDist) { bestDist = d; best = p } } return best // không nhánh thất bại, không vòng vô hạn Ba tính chất khiến mẫu này đáng chép: (a) luôn trả về một điểm hợp lệ kể cả khi bể chật — chất lượng suy giảm mượt thay vì hỏng; (b) chi phí có trần cứng O(maxAttempts × N); (c) hai tham số (minDistance, maxAttempts) là núm chỉnh cảm giác, không phải hằng số kỹ thuật. Nhớ seed best bằng một điểm ngẫu nhiên TRƯỚC vòng lặp — nếu seed bằng Vector2.zero thì bể chật sẽ dồn mọi thứ về tâm. Cùng khuôn "kẹp vào khung": if (min > max) { min = 0; max = 0; } — khi thực thể lớn hơn khung chứa thì ghim về tâm thay vì cho ra một Random.Range ngược biên.

13. Sắp lớp bằng MỘT thang order mang HAI trục + một dải "luôn trên cùng" nằm ngoài Clamp. csharp order = Clamp(RoundToInt(yOrigin − y) + step * (maxGrade − grade), 0, 2000); // step = 10 if (isDragging) order = 9999; // vật thể người chơi đang cầm else if (isAnimatingToTarget) order = 9998; // vật thể đang trong hoạt ảnh Trục hạng chiếm bước 10, trục toạ độ Y chiếm bước 1 ⇒ hạng vẫn thắng, nhưng trong cùng hạng thì ai ở thấp nổi lên trên (phối cảnh nhìn ngang). Hai giá trị đặc biệt thoát khỏi cả hai trục, và vì chúng nằm ngoài Clamp nên không bao giờ bị trục nội dung đuổi kịp. Đi kèm là một quyết định thẩm mỹ đáng ghi: Fish_Tank.SortHierarchyByGrade sắp hạng giảm dần trong hierarchy ⇒ thực thể bậc CAO (sprite to) bị bậc THẤP vẽ đè. Nghe ngược, nhưng nó giữ cho một con to không nuốt mất mặt tiền của cả đàn nhỏ — người chơi vẫn đếm được tài sản của mình. Thực thể đang tắt bị SetAsLastSibling() để không chiếm chỗ sibling.

5. Negative evidence & UNKNOWN

6. Raw evidence

• dump.cs:593380 — Cat_manager (tooltip tiếng Hàn xác nhận Cat_list[0])
• dump.cs:593002 — Cat (~100 field, ~50 method, hằng số)
• dump.cs:597811 — Pet
• dump.cs:594503 — Monster (MaterialPropertyBlock, knockback)
• dump.cs:593531 / :595047 — Boss / Raid_Boss
• dump.cs:602135 — Tree_manager (wave + đường cong stage)
• [reconstructed: Cat.cs], Tree_Grid.cs, Tree.cs, Ore.cs, Tree_manager.cs} — thân đã dựng lại đợt 3 (marker // L1 RVA)
• [evidence codegen: TABLE.md] — degreeRates, MonsterCountPerLevel, SpawnIntervalPerLevel (SHA MATCH)
• [report: t300.png] — đo đồng hồ màn 180 s (G351)
• Gaps đợt 3: G306, G343, G344, G346, G347, G351, G352, G353 trong gap list (nội bộ)
• [evidence codegen: README.md], Pet_Ingame_manager.c} — boids đã giải mã
• [runtime trace: flock_oracle.js], run_flock.py, flock_samples.json} — oracle lực (bằng chứng phủ định)
• [reconstructed: Enemy.cs], EnemyColl.cs, Enemy_Slider.cs, Ore.cs, Tree_SpeedRun.cs, Pet_Dummy.cs}
• [evidence codegen: Tree.cs] — vòng đời wave
• [report: asset_lane.md] §0, §5 — Spine 4.1.24, 13 skeleton, tên dự án BardCat
• [index: scene_census.json] — số instance
• Gaps: G130, G131 trong gap list (nội bộ)