Known Limitations and Scope

Known Limitations and Scope

When evaluating an IL2CPP-compiled Unity game for porting or teardown, it is vital to distinguish between a port (rebuilding minimal mechanics to make existing scene data playable) and a total rewrite (re-implementing gameplay systems from scratch).

This document outlines what systems survive, what systems do not survive, and how to decide whether a project is viable for porting.

---

System Survival Matrix (MiSide Case Study)

System	Survival Status	Reconstructibility	Notes
Scene Transforms & Meshes	100% Intact	Automatic	Hierarchy, positioning, lighting, and materials import directly via AssetRipper.
UnityEvent Chains	100% Intact	Automatic	Button actions, trigger chains, and scene loading calls survive in scene YAML.
Inspector Field Values	100% Intact	Automatic	[SerializeField] values, speed constants, Rigidbody masses, and references survive.
Core Movement & Raycasting	0% Logic	Easy Hand-Rewrite	Player controller parameters (speedPlayer=0.65, mass=5, height=1.85) survive in Inspector fields. Rebuilding FPS movement takes ~50 lines of C#.
UI Menu & Navigation	0% Logic	Easy Hand-Rewrite	Rebuilding ButtonMouseClick and Menu.Start() unlocks all 108 menu buttons and their underlying UnityEvent chains.
Dialogue & Text Tables	0% Logic / Data	Difficult	Text is addressed by integer index into an external string table that did not survive as an editable asset (zero TextAsset files; text format function is return null;).
Interactive Minigames	0% Logic	Full Rewrite	~200 Location* classes retained Inspector values but lost all rules and state machines. Rebuilding them is rewriting the game.
Audio Playback	0% Logic	Moderate Rewrite	Audio clips survive on disk, but custom audio manager helper methods are stripped.
Animations (.anim)	Partial	Moderate	Animator controllers and state machines import; .anim motion clips were excluded from initial import closures to save size.

---

Detailed Breakdown of Lost Systems

1. Dialogue & Localization Tables

• Condition: In the decompiled export, zero TextAsset files exist, and there are no StreamingAssets containing localization JSON/CSV files.
• Impact: Text lines are referenced by integer IDs passed into formatted string lookup functions. Because those lookup functions were stripped to return null;, no dialogue text displays.
• Porting Implication: Without extracting raw string tables from binary metadata or re-writing a localization loader, dialogue cannot be recovered automatically.

2. Minigames and Unique Location Logic

• Condition: Over 200 distinct location scripts (e.g. LocationBasement, LocationPhone) retained their Inspector field declarations and object references, but 100% of their C# method bodies are empty.
• Impact: Walking into a minigame area renders all 3D assets, but no game rules, puzzle scoring, or state transitions execute.
• Porting Implication: Re-creating minigames requires reading ISIL line-by-line for all 200 location classes. Rebuilding them is effectively rewriting the game logic from scratch.

3. Audio & Helper Triggers

• Condition: Audio sources in scenes keep their clip references, but audio manager wrapper methods (such as PlaySound3DAtPosition()) are stripped.
• Impact: Direct AudioSource.Play() calls fired via UnityEvent graphs work, but script-triggered sound effects remain silent until helper methods are restored.

---

Decision Matrix: Port vs. Rewrite

Before planning an IL2CPP project port, run python tools/measure-bodies.py and evaluate your goals against this matrix:

                                  Is your goal to:
                                         |
                +------------------------+------------------------+
                |                                                 |
     Slice/Showcase Port                               Full Game Re-creation
(Menu, 3D exploration, triggers)                    (Minigames, AI, Full Story)
                |                                                 |
                v                                                 v
    [FEASIBLE & RECOMMENDED]                              [HIGH COST / REWRITE]
 - Keep 100% of scene YAML data.                   - Requires reading ISIL for
 - Rebuild minimal Player/UI scripts.                hundreds of complex classes.
 - Firing surviving UnityEvents                    - Dialogue & state machines
   restores 80% of interactivity.                    must be written by hand.

If your goal is a playable WebGL demonstration, architecture teardown, or slice port, IL2CPP reconstruction is efficient because scene data handles the heavy lifting. If your goal is a 100% feature-complete commercial rebuild, recognize that stripped logic requires transcribing ISIL for every custom method in the codebase.