The Concept of Engine-Agnostic Components

Engine-agnostic components are parts of GameCatalyst that work the same way regardless of which engine you’re using. Understanding this distinction helps you appreciate the architectural elegance and explains why adding new engine support doesn’t require rebuilding the entire system.

Engine-agnostic components (Layers 1-3):

These components have zero knowledge of Unity, Unreal, or Godot. They operate purely on abstract concepts like “projects,” “commands,” and “sessions.”

• MCP Bridge — Handles all AI client communication using the Model Context Protocol. Doesn’t know what engine the commands target.
• Discovery Server — Tracks projects from any engine. Stores project metadata (name, path, engine type) but doesn’t execute engine-specific operations.
• WhatIs system — Provides documentation for any engine. Command documentation is tagged by engine but served through the same API.
• Session management — Fingerprinting, authentication, and permission enforcement work identically across engines.
• Transport layer — STDIO, HTTP/SSE, and Web Relay support all engines without modification.
• Workspace Intelligence — DAP, workspace.plan, workspace.index, workspace.diagnose, and workspace.find work across engines because they operate on file systems and code, not engine APIs.
• Database layer — SQLite databases store plans, sessions, and configuration the same way for all engines.

Engine-specific components (Layers 4-5):

These components know about specific engine APIs and must be implemented separately for each engine:

• Instance Server (Layer 4) — Different Python implementation per engine. UnityInstanceServer.py, UnrealInstanceServer.py (future), GodotInstanceServer.py (future).
• API Bridge (Layer 5) — Different language and API per engine: C# for Unity, C++ for Unreal, GDScript or C# for Godot.
• Handlers — Engine-specific command implementations. Unity has object.create, Unreal will have actor.spawn, Godot will have node.create.
• CommandDefinition assets — Define available commands per engine with engine-specific parameters.

The abstraction boundary:

The boundary between engine-agnostic and engine-specific components is carefully designed. Commands flow through this boundary using a standardized interface:

1. AI client sends a command to MCP Bridge (engine-agnostic)
2. MCP Bridge validates and routes to Discovery Server (engine-agnostic)
3. Discovery Server forwards to appropriate Instance Server (engine-specific)
4. Instance Server translates to engine API calls (engine-specific)
5. Results flow back through the same path

This clean separation means adding a new engine requires implementing only Layers 4-5. Layers 1-3 remain untouched.

What this means for you:

When Unreal support launches, you’ll use:

• The same AI clients (Claude, ChatGPT, Cursor, etc.)
• The same connection process (Client Conductor Configurator)
• The same WhatIs site (just with Unreal commands added)
• The same workspace.plan system (plans work identically)
• The same Dashboard (with Unreal project support)
• The same safety features (dry-run, protected paths, permissions)

Only the engine-specific commands change. Instead of object.create, you’ll use actor.spawn. Instead of component.add, you’ll use component.attach. The pattern is the same. The syntax adapts to the engine.

Benefits of this architecture:

• Faster development — Adding engines requires less code
• Consistent experience — You learn once, use everywhere
• Easier maintenance — Bug fixes in engine-agnostic layers benefit all engines
• Future-proof — New engines can be added without breaking existing support

This is why GameCatalyst can credibly claim multi-engine support is coming. The hard part (the architecture) is done. The remaining work is implementation.