DOCSEARCHbyAlgolia
Submit Docs

Redwood MMO Documentation

website·Indexed 31 days ago

https://redwoodmmo.com/docs

A backend framework for MMOs with Unreal Engine integration. Features include matchmaking via Open Match, persistence for Unreal's Gameplay Ability System, and authentication providers for Steam, Epic, Discord, and Twitch. Supports game server hosting via Edgegap and local providers, secret management through AWS, Azure, GCP, and HashiCorp Vault, and data storage using Redis.

Tokens
47.9K
Snippets
131
Records
378
Agent score
51%

What's inside Redwood

  1. Overview of Redwood Backend Infrastructure

    Redwood is a self-hosted, source-available Game Backend as a Service (GBaaS) alternative to platforms such as Epic Online Services, Steamworks, and Azure Playfab. It is designed for scalability and flexibility, allowing developers to customize the backend via configuration or direct source code modification. The backend is written entirely in Node.js, enabling integration with third-party services using NPM modules.

  2. Overview of Redwood Backend Infrastructure

    Redwood is a self-hosted, source-available alternative to Game Backend as a Service (GBaaS) platforms like Epic Online Services, Steamworks, and Azure Playfab. It is designed for scalability and flexibility, allowing developers to customize the backend via configuration parameters or by modifying the source code directly to meet specific game requirements.

  3. Scale backend microservices and ticketing

    Redwood backend microservices have been refactored to use Redis, allowing them to scale horizontally. Additionally, ticketing (matchmaking and queuing) has been moved to its own dedicated microservice. This allows developers to use different logic for different game types, such as queuing for persistent MMORPG worlds and matchmaking for instanced dungeons or raids.

  4. Understand the NetDriver, NetConnection, and Channel hierarchy

    The networking architecture is organized into three primary layers:

    1. UNetDriver: Manages sets of UNetConnections and shared data. Common types include:
      • Game NetDriver: Handles standard game network traffic.
      • Demo NetDriver: Handles recording or playback of game data (Replays).
      • Beacon NetDriver: Handles traffic outside of normal gameplay.
    2. UNetConnection: Represents an individual client connected to a NetDriver. On a server, the NetDriver maintains a list of these for all players; on a client, there is typically only one connection to the server.
    3. Channels: NetConnections route data to Channels. Common types include:
      • Control Channel: Manages connection state (e.g., closing the connection).
      • Voice Channel: Transmits voice data.
      • Unique Actor Channel: Created for every Actor replicated from server to client.

  5. Redwood Framework scaling goals

    Following the core maturation phase, the development focus for the Redwood framework is shifting toward supporting high player counts, specifically targeting more than 100 players with a goal of 1,000 players without requiring sharding.

  6. Manage ephemeral player parties in Redwood

    Redwood provides a Parties system for temporary grouping of players. Parties are ephemeral: they are not stored in the database and are deleted once all players leave. To interact with the Parties system, players must first connect to a Realm, as parties exist in Realms rather than the Director. This system allows for minimal synchronization (create, invite, join) even from the title screen/main menu without a game server.

  7. Use World Data for global synchronization across shards

    World Data is used to specify data that must be synchronized to all shards in all zones and persisted to the database. It is associated with a GameServerProxy so that data is reloaded when the server restarts via a GameServerCollection.

    When to use World Data vs. Sync Items:

    • Use World Data: For global world state that does not require spawning a specific actor (e.g., long-term guild scoring, global time of day).
    • Use Sync Items: For data that should initiate the spawning of an actor (e.g., player-created buildings).

    Starting in Version 3.0, World Data is automatically synchronized to all shards in all zones.

  8. Understand Redwood Realms

    A Realm is the primary collection of logic and data in Redwood. It manages ticketing (matchmaking, queuing), player character data, world data, and game servers. Each Realm consists of a Frontend and Backend, along with various microservices. When players log into the Director, they list available Realms to create or update characters bound to that specific Realm and join GameServerProxies associated with it.

  9. Manage social groups with Guilds, Alliances, and Parties

    Redwood provides three primary social grouping systems: Guilds & Alliances for long-term group management and game logic membership, and Parties for ephemeral groupings used during queuing and matchmaking.

  10. Understand Redwood player database storage structure

    Redwood uses two primary database entities for player data:

    1. PlayerIdentity: A single entry per player stored in the Director database. Used primarily for authentication; it contains no game-specific data.
    2. PlayerCharacter: One or more entries per player stored in Realm databases. These are specific to the Realm where the game is running and include a name used for APlayerState::SetPlayerName().

    Each PlayerCharacter contains the following JSON fields:

    • characterCreatorData: Data from the character creator. Client-editable via Realm Frontend API; not suitable for authoritative data (e.g., level, gear). Typically replicated to all players.
    • metadata: Server-managed metadata (e.g., health, level). Typically replicated to all players.
    • equippedInventory: Items the character is currently carrying. Typically NOT replicated to other players to prevent inventory-spoofing mods.
    • nonequippedInventory: Items in the character's 'bank'. Typically NOT replicated to other players.
    • progress: Character progress (achievements, quests, skill trees). Disabled by default; must set URedwoodCharacterComponent::bUseProgress to true to enable.
    • abilitySystem: Ability data. Used by URedwoodCharacterComponent or the built-in Gameplay Ability System (GAS) integration.
    • data: General character data not intended for other players (e.g., bookmarks, settings). Typically NOT replicated.
    • redwoodData: Internal system data (e.g., zone transferring). Do not modify manually.

  11. RedwoodMMO Core Technology Stack

    RedwoodMMO utilizes the following core technologies for its backend services and infrastructure:

    • Runtime & Language: Node.js and TypeScript.
    • Infrastructure & Orchestration: Docker for containerization and Kubernetes (K8s) for orchestration.
    • Game Server Management: Agones (Kubernetes extension for scaling game server pods) and Open Match for matchmaking.
    • Databases: PostgreSQL is the primary relational database. For local development on Windows (without Kubernetes), SQLite is used as a substitute.
    • Caching & Messaging: Redis is used for horizontal scaling and as a pub/sub broker. For Windows development, Redwood provides a custom pure-JS Singleton stub, or Memurai can be used as a full Redis replacement.
    • Networking: SocketIO is used for connections to Node.js services.
    • Communication: ejabberd is used to support Text Chat functionality.

  12. Understand the Redwood backend configuration structure

    The Node.js backend microservices configuration is located in config/node. The default folder contains all available configuration variables and their default values. Configuration is primarily managed via YAML files. Variables are accessed in the Node.js service using a typed getter: config.get<type>("path.to.variable").

    Variable paths are constructed using three methods:

    1. Subfolders: A folder name becomes a segment of the path.
    2. YAML Files: The filename (basename) becomes a segment of the path.
    3. YAML Objects: A dictionary key within a YAML file becomes a segment of the path.

    Example Path Resolution: deployment.redwood.director.backend.replicas

    • deployment/ (subfolder under default)
    • redwood.yaml (YAML file)
    • director: (object key in redwood.yaml)
    • backend: (object key under director)
    • replicas: (final key-value pair)
    const value: type = config.get<type>("path.to.variable");