DOCSEARCHbyAlgolia
Submit Docs

Rune SDK Documentation

repository·staging·Indexed 19 days ago

https://github.com/rune/rune

A platform and SDK for building multiplayer web games using TypeScript and React. Rune provides managed networking with predict-rollback netcode, social features like voice and text chat, and hosting for games that run within the Rune mobile app. The ecosystem includes the rune-mcp server for AI-assisted development in VS Code, eslint-plugin-rune for server-side logic validation, and a CLI for publishing games.

Tokens
57.3K
Snippets
148
Records
292
Agent score
64%

What's inside Rune

  1. Overview of Rune Open-Source Grants

    staging

    Rune offers a $100k grant initiative to support indie developers building open-source multiplayer web games. The program aims to grow the open-source web game community by providing financial support and recognition to talented developers.

    There are two tiers of grants:

    • Spark grants: $500 awarded to indie game developers.
    • Ignite grants: $5,000 awarded to developers who have previously proven themselves with a Spark grant.

    Awarded developers receive promotion via Rune's blog, highlights within the Rune app, and shoutouts on social media (Twitter, Reddit, LinkedIn).

  2. Overview of Rune

    staging

    Rune is a platform for building multiplayer web games that run inside the Rune app (available on iOS and Android). It abstracts away the complexities of servers and networking, allowing developers to focus on game logic.

    Key Capabilities:

    • Multiplayer Networking: Uses predict-rollback netcode for fast and reliable updates, with server-side conflict resolution.
    • Social Integration: Built-in messaging, friends, spectating, and voice chat.
    • Tech Stack: Games are built using JavaScript/TypeScript and can leverage any web framework (React, Svelte, Vue) or graphics library (Threejs, PixiJS, Phaser).
    • Cost: Launching games on Rune is free, as Rune handles server and voice chat costs.

  3. Use the Rune Games CLI to publish multiplayer games

    staging
    The Rune Games CLI is used to upload games to the Rune app, enabling multiplayer functionality. When you use the CLI, Rune handles the backend infrastructure, including servers and networking, allowing you to focus on game development. Your game will be available to users on the Rune app across iOS and Android platforms.

  5. Implement multiplayer sync in Rune games

    staging

    Rune supports multiplayer synchronization using a predict-rollback netcode architecture. When building multiplayer games, you should follow these architectural fundamentals:

    • Predict-Rollback Netcode: Use this for handling network latency and state synchronization.
    • Rate Limits: Implement appropriate rate limiting for network updates.
    • Stateless Logic Architecture: Design game logic to be stateless to facilitate easier synchronization across clients.

  6. Identify the local player using yourPlayerId

    staging

    The onChange callback provides a yourPlayerId property. This represents the ID of the client currently running the game. You can pass this ID to Rune.getPlayerInfo() to retrieve the local player's displayName and avatarUrl.

    Important: yourPlayerId will be undefined if the client is a spectator.

  7. Load Balancing for stateful Real-Time servers

    staging

    Load balancing strategies must differ based on the component type:

    • Stateless (Central Server): Use standard web-style load balancing. Since state is stored in the database, any server instance can handle any request.
    • Stateful (Real-Time Server): Requires "sticky sessions". Because the server maintains active connections and authoritative game state in memory, the load balancer must ensure that all players in the same session (e.g., the same room or game instance) are routed to the exact same server instance. This often requires custom load balancing solutions that use connection attributes to determine routing.

  8. Architecture of a Rune game

    staging

    Rune games follow a strict separation of concerns between Logic and Rendering (the MVC pattern). This separation is required to support the predict-rollback network model, where identical copies of the game logic run on both the server and the client.

    • Logic: Contains the data model (game state) and the rules for updating that state. It must be fully deterministic so that all clients and the server arrive at the same state when applying the same actions. Logic is executed on both the browser and the server.
    • Renderer (Client): The code responsible for drawing the game to the screen and capturing player input. It can be implemented using any browser-based library or framework (e.g., HTML5 Canvas, React, Three.js).

  9. Implement multiplayer state synchronization for physics-based games on Rune

    staging

    When building physics-based games on Rune, you can achieve multiplayer synchronization by having the client act as the source of truth for its own local state.

    For games where players have separate containers or entities (like individual fruit wells), a common pattern is to have the client send the position, rotation, and velocity of every object to other clients whenever a new object is added to the simulation. This allows other clients to sync the state of that player's objects.

    Note: While this client-side synchronization works well for casual games, for more complex features like co-op modes (where players share the same container), it is recommended to move physics logic to a server-side environment using a library like propel-js to ensure a single authoritative source of truth.

  10. Compare WebSockets and WebRTC for multiplayer game networking

    staging

    When choosing a networking model for real-time multiplayer games on the web, the primary trade-off is between the ease of implementation (WebSockets) and the latency performance (WebRTC).

    WebSockets (TCP-based)

    • Pros: Extremely easy to implement; wide library support (e.g., Socket.io); abundant cheap hosting options.
    • Cons: Uses TCP, which is subject to Head of Line Blocking. If a single packet is delayed or lost, all subsequent packets are held up by the protocol until the lost packet is retransmitted and acknowledged, increasing latency (ping).
    • Best for: Games where absolute reliability and order are more important than millisecond-level latency, or where development speed is a priority.

    WebRTC Data Channel (UDP-like)

    • Pros: Uses SCTP over UDP, allowing for unreliable/unordered delivery. This avoids Head of Line Blocking, as packets are not dependent on each other, preventing delay compounding.
    • Cons: Significantly more complex setup; requires a signaling mechanism (like WebSockets) to exchange SDP payloads; requires network traversal infrastructure (STUN, ICE, and TURN servers).
    • Best for: High-performance, real-time multiplayer games where minimizing latency and avoiding jitter is critical.

  11. Categorize player interactions to manage latency and rollbacks

    staging

    Categorizing interactions early helps in choosing the right networking model and managing player expectations regarding latency. Interactions fall into four complexity tiers:

    1. Data Exchange (Easiest): Swapping or sharing objects/consumables. Since there is no real-time visual requirement beyond stat updates, latency is rarely noticeable.
    2. Out of Band Effects: Power-ups that affect others (e.g., screen blackouts). These can tolerate slight delays between input and effect, allowing latency to be absorbed.
    3. Ranged Interactions: Shooting or projectile-based combat. These are sensitive to latency and rollbacks, but because the interaction is visually distant, rollbacks are less jarring to the player.
    4. Close Interactions (Hardest): Physical contact, such as pushing or shoving. These are highly sensitive to latency and can cause sudden, jarring movements during rollbacks. Mitigation strategies include using slow-moving objects and implementing acceleration in player movement.

  12. Monetization and Costs on Rune

    staging

    Rune is currently free for both players and game developers.

    Monetization Options:

    • Game Jams: Developers can win cash prizes through community game jam events.
    • Future Revenue Sharing: Rune is developing ways for developers to earn money on their games. When revenue generation is implemented, Rune will take a small percentage to cover server and development costs.

    Note: Rune does not use ads and does not support blockchain or NFT integrations.