Skip to content

STRATEGY.md

Latest commit

 

History

History
48 lines (38 loc) · 3.98 KB

STRATEGY.md

File metadata and controls

48 lines (38 loc) · 3.98 KB

Project Strategy: The "Hybrid" Worklfow

Vision: Combine 2009's "Golden Era" knowledge with 2026's "Modern" tooling to create the ultimate AI modding assistant.

The Challenge

Modding MW2 (IW4) in 2026 presents a unique challenge:

  1. Lost Tools: Official tools don't exist for MW2.
  2. Scattered Knowledge: Documentation is spread across 15 years of forum posts, dead wikis, and Wayback Machine snapshots.
  3. Modern Expectations: Agents (and users) expect 2026-era tooling (Linters, CI/CD, Hot-reloading), but the game engine is from 2009.

Strategic Pillars

1. Engine Heritage (Cross-Title Knowledge)

The IW Engine is iterative. MW2 (IW4) is built directly on CoD4 (IW3).

  • Strategy: Use "Upstream" documentation to fill "Downstream" gaps.
  • Tactic: When MW2 documentation is missing, the agent should trust CoD4/WaW official documentation for:
    • GSC Script syntax and built-in functions.
    • FastFile asset structures (MenuDefs, WeaponFiles).
    • New: Common error patterns (leaks, syntax errors) are identical. We can use CoD4 troubleshooting guides for MW2.

2. Scripting & UI Supremacy (The "Logic" Layer)

LLMs are essentially advanced text-processing engines. Because of this, the iw4x-toolkit makes them incredibly powerful at scripting but fundamentally incapable of visual design (mapping, modeling, texturing).

  • Strategy: Focus the toolkit on what Text-AI does best: GSC Scripting (gametypes, zombies, bots), UI Menu design (.menu), weapon tweaking, and DVAR manipulation.
  • Tactic: Do not attempt to build GUI MCP tools for Radiant (mapping). Let human artists build the visual assets, while the LLM acts as the Lead Programmer executing the logic. However, developing headless/CLI tools to read compiled assets (like extracting spawn coordinates from a .d3dbsp) is a high-value, long-term goal.

3. Open Source Synergy & Cross-Title Reach

The IW engine lineage is a shared resource. We shouldn't reinvent the wheel if the community has already solved a format parsing problem.

  • Strategy: Actively integrate, wrap, or "borrow" from existing open-source C++/C# tools (like ZoneTool or OpenAssetTools) rather than rewriting complex parsers from scratch in TypeScript.
  • Tactic: Make no mistake: this tool is built for MW2 (IW4x). However, because the engine iterations share so much DNA, we should design our IW4 tools (like the GSC Linter or FastFile parser) with enough architectural flexibility that they could eventually be extended to CoD4, WaW, or MW3 by the community. We solve for IW4x first.

4. The "Userraw" Workflow (Local-First Development)

Directly editing .iwd files is risky and slow ("Production Mode"). Active development should utilize the engine's built-in override system ("Development Mode").

  • Old Pattern: Read IWD -> Edit -> Write IWD.
  • New Pattern: Extract assets to fs_game/userraw. The game loads these "loose files" with higher priority.
  • Goal: Build tools (setup_workspace, deploy_mod) that manage this environment, allowing for rapid iteration without constant archiving.
  • Strategic Note: In the wake of X Labs/H2M shutdowns (2023-2024), decentralized, local-only tooling is the only safe path for preservation. We do not rely on central servers.

5. "Compilers" for Scripting (Static Analysis)

Since we cannot verify code by running it (no unit test framework for GSC), we must verify it by reading it.

  • Missing Piece: GSC has no compiler. You find generic syntax errors only when the map fails to load.
  • Asset Compilation: ZoneBuilder (2017+) is the standard for building FastFiles. We should treat it as the "Linker" in our toolchain.
  • Solution: GSC Linter. A strict static analysis tool to catch:
    • Syntax errors (Braces, Semi-colons).
    • Logic errors (Undefined variables, invalid #includes).
    • Type safety (Argument counts for built-ins).
    • New: Hard Limit Checks (DVAR count < 4096, Entity count limits).