Cross-Platform SDK¶

Skill ID: ivx-cross-platform

name: ivx-cross-platform description: >- Port IntelliVerseX SDK features between game engines and platforms. Use when the user says "port to Unreal", "port to Godot", "add JavaScript SDK", "cross-platform", "multi-engine", "feature parity", "platform support", "which features work on", "stub vs real", or needs help understanding cross-platform coverage. version: "1.0.0" author: "IntelliVerse-X team@intelli-verse-x.ai" allowed-tools: - Read - Write - Edit - Glob - Grep - Shell

Overview¶

The IntelliVerseX SDK supports 10 platforms. Unity is the reference implementation with full coverage. Other platforms implement a subset of features, with the rest available as API-surface stubs so code compiles and can be incrementally implemented.

When to Use¶

Ask your AI agent any of these:

• "Port my game from Unity to Godot"
• "Which features work on Unreal Engine?"
• "Convert the Hiro economy stub to a real implementation on Flutter"
• "What's the JavaScript equivalent of IVXLobbyManager?"
• "Add leaderboard support to the C++ SDK"
• "What's the coverage for the Defold SDK?"

What the Agent Does¶

flowchart TD
    A[You: "Port to Godot"] --> B[Agent loads ivx-cross-platform skill]
    B --> C[Shows Godot feature coverage]
    C --> D[Maps Unity classes to Godot equivalents]
    D --> E[Identifies RPC contract from Unity reference]
    E --> F[Creates typed RPC wrapper in GDScript]
    F --> G[Builds manager with caching + signals]
    G --> H[Replaces stub with real implementation]
    H --> I[Updates coverage matrix]

1. Supported Platforms¶

2. Feature Coverage Matrix¶

Legend¶

Matrix¶

Coverage Summary¶

3. Unity-Only Features¶

These features currently have real implementations only in Unity:

Other platforms have stubs that return defaults or call HTTP equivalents.

4. Cross-Platform Architecture Pattern¶

Every SDK follows the same architectural pattern adapted to language idioms:

┌──────────────────────┐
│  Game Code           │  Your game logic
├──────────────────────┤
│  IVX{Feature}Manager │  Singleton manager (C# / TS class / Java class / etc.)
├──────────────────────┤
│  IVX{Feature}RpcClient│  Typed RPC wrappers calling Nakama
├──────────────────────┤
│  IVXNakamaClient     │  Platform HTTP/WebSocket client
└──────────────────────┘

Language Adaptations¶

5. Class Mapping Table¶

6. Adding a Feature to a Non-Unity SDK¶

Follow this process to port a feature from the Unity reference to another platform:

Step 1 — Identify the RPC Contract¶

Look at the Unity IVX{Feature}RpcClient.cs to find: - RPC endpoint IDs (e.g. hiro_economy_grant) - Request payload shape - Response payload shape

Step 2 — Create the RPC Wrapper¶

In the target SDK, create a typed wrapper that calls the same RPC:

// JS/TS example
export class IVXEconomy {
  async grant(currency: string, amount: number): Promise<EconomyResponse> {
    return this.client.rpc("hiro_economy_grant", { currency, amount });
  }
}

Step 3 — Create the Manager¶

Wrap the RPC client with convenience methods, caching, and events:

export class IVXEconomy {
  private _balances: Map<string, number> = new Map();

  async grant(currency: string, amount: number): Promise<void> {
    const resp = await this.rpc.grant(currency, amount);
    this._balances.set(currency, resp.newBalance);
    this.emit("balanceChanged", currency, resp.newBalance);
  }

  getBalance(currency: string): number {
    return this._balances.get(currency) ?? 0;
  }
}

Step 4 — Replace the Stub¶

Update the stub implementation to use the real manager. Mark the feature as Y in the coverage matrix.

Step 5 — Test¶

Verify against the same Nakama server that the Unity client uses. The RPC contracts are identical.

7. SDK Directory Structure¶

SDKs/
├── javascript/       # npm / TypeScript
│   ├── src/
│   ├── package.json
│   └── tsconfig.json
├── java/             # Gradle / Android
│   ├── lib/src/main/java/com/intelliversex/
│   └── build.gradle
├── flutter/          # Dart / pub.dev
│   ├── lib/
│   └── pubspec.yaml
├── unreal/           # UE5 Plugin
│   ├── Source/
│   └── IntelliVerseX.uplugin
├── godot/            # Godot 4 Addon
│   ├── addons/intelliversex/
│   └── plugin.cfg
├── defold/           # Defold Library
│   ├── intelliversex/
│   └── game.project
├── cpp/              # CMake
│   ├── include/
│   ├── src/
│   └── CMakeLists.txt
├── cocos2dx/         # CMake
│   ├── include/
│   ├── src/
│   └── CMakeLists.txt
└── web3/             # TypeScript + ethers.js
    ├── src/
    ├── package.json
    └── tsconfig.json

8. Device / Runtime Platform Matrix¶

Beyond engines, the SDK also varies by deployment target. This matrix shows what works on each device class.

Legend¶

Matrix¶

Key Takeaways¶

• Multiplayer, Hiro, and Satori work everywhere — they're server-side via Nakama RPCs.
• XR features require engine-level support (Unity XR Management, Unreal XR System, Godot OpenXR).
• Console platform services (auth, achievements, presence, store) use the adapter pattern — the SDK provides the interface, you implement the NDA-protected bridge.
• WebGL has limitations on ads, audio recording, and push notifications but supports multiplayer and core game systems.
• Monetization varies significantly by device class — VR and console have no traditional ads.

Relevant Documentation¶

Checklist¶

• Identified target platform and its current coverage
• Reviewed Unity reference implementation for the feature
• Extracted RPC contract (endpoint, request, response)
• Created typed RPC wrapper in target SDK
• Created manager with caching and events
• Replaced stub with real implementation
• Tested against shared Nakama server
• Updated coverage matrix in this document
• Device/runtime matrix reviewed for target deployment (VR/Console/WebGL)
• XR compile defines set if targeting VR/AR
• Console adapter implemented for platform services