Getting Started

What is Jondob Multiplayer Backend?

Jondob Multiplayer Backend (JMB) is a complete multiplayer backend built in Go. It is highly performant and engine-agnostic, and it comes with direct integration for Godot 4. You have access to source code, and it is one Go server binary you run yourself.

Out of the box you get account management (Steam, email/password, and more login options to be added in the future), lobbies with a full match-start flow, chat and direct messages, friends, blocking, synced player data, world data, generic data, and authoritative game-server orchestration in two modes: world and matches.

The server runs on any machine you control — a VPS, your own PC, whatever you want. Everything is stored on that machine, and everything is completely configurable by editing a text file.

This guide takes you from an empty project to a running multiplayer game: SDK installed, server configured, builds exported, and your first match running.

Install JMB in Godot

• Unzip the JMB pack into your Godot project. The recommended path is res://addons/jmb/ or any location under your project root.
• The pack contains the full SDK, a sample game, and premade UI for login, lobbies, chat, and friends.

Configure your project

Key configuration files

Go to the addons/01_jg_lib/packs/jmb/ directory, as shown in the screenshot:

Then duplicate build_config.tres and client_config.tres, and place them in a directory of your choosing. Ideally, create your own directory that keeps everything related to your game in one place.

Core scenes configuration

jmb_service.tscn is the key file where all the core logic lives. You will only need to interact with it during the setup process, and you only need to change one thing:

• Create an inherited scene from jmb_service.tscn and save it to disk, ideally right next to the config files.
• Change the config variable so that it points to your duplicated client_config.tres.

jmb_network_manager.tscn is the file you will interact with most of the time. You can use it as-is, or follow the recommended flow:

• Create an inherited scene based on jmb_network_manager.tscn.
• Create a new script that extends JMB_NetworkManager.
• In your client_config.tres, assign the new network manager into Core Settings.

Finally, set the new service scene you created as an autoload: Project → Project Settings → Globals → Autoload.

Creating core scenes

You need to set up two scenes in the network manager to act as entry and exit points for online gameplay:

JMB uses a single Godot project for both client and server. You export two builds from the same project using export presets.

Export presets

Make sure you have export templates installed in Godot (Editor → Manage Export Templates). Then set up your export presets in Project → Export.

Build using JMB_BuildConfig

Select your JMB_BuildConfig resource and configure it to point to the scenes, output directory, and export preset name.

Export presets are the presets you define in the Export window. The build system uses these for creating builds.

Install Go

JMB's server is written in Go. Install Go 1.25 or later from go.dev/doc/install.

Verify the installation:

go version

If it prints version 1.25 or above, you are ready to proceed.

Configure the Go server

In the Go server source code, the only directory you need to work with is config/. It contains everything you can configure.

config.json

Start with config.json, which defines the server's listen addresses:

{
  "public": {
    "address": "0.0.0.0:8080"
  },
  "internal": {
    "address": "127.0.0.1:25001"
  }
}

If you look at client_config.tres in Godot, you will find that these values match. They must be exactly equal, or the client will not be able to connect.

endpoints.json

Configure which login endpoints are available:

{
  "login_with_email": {
    "enabled": true,
    "confirmed": true
  },
  "login_with_id_t": {
    "enabled": true,
    "confirmed": true
  },
  "login_with_steam": {
    "enabled": false,
    "confirmed": true
  }
}

To support a platform, set its enabled to true. The confirmed field is an extra safety measure — if it is false, the server will log a warning about that endpoint.

gameinst_definitions.json

This file tells the Go server where your game executable lives, so it knows how to launch the Godot server build:

{
  "all_game_entries": {
    "gk_main_world_entry": {
      "executable": "C:/path/to/your/GameServer.exe",
      "display_name": "Sample Game"
    }
  },
  "port_range_start": 9000,
  "port_range_end": 19000
}

Set the executable field to the absolute path of your exported Godot server build on your operating system.

Run the Go server

Open a terminal in the directory that contains the Go server source, then run:

go build .
go run .

That's it. If you see the following output, the server is running:

INFO  lobby: loaded 8 lobby var(s), 1 member var(s)
INFO  backup: routine started
INFO  ws router started
INFO  ws hub started
INFO  lobby started
INFO  JMB :: Jondob Multiplayer Backend
INFO  internal listener running on 127.0.0.1:25001
INFO  public listener running on 0.0.0.0:8080

Run the game

The server is running and everything is configured. Launch the client, and you are live.

The premade login UI supports Steam, email/password, and debug token login out of the box:

Create an account, log in, and enter the lobby:

The room browser shows available rooms, a chat panel, and online players:

Inside a room, you can see the player list, room settings, room chat, and the Start Match button:

JMB supports the core plain data types: bool, string, float. Whether you want to give players XP, track lifetime kills across all matches, or check whether a monument in a persistent world has been destroyed — it all works through GenVar config files.

Data configuration files

Modify one of these files depending on your needs, by adding or removing variables:

Persistent worlds

If your game is world-based or uses a persistent world that runs forever and players can join and leave freely, open persistent_worlds.json:

{
  "world_spawn_interval_seconds": 2,
  "worlds": [
    {
      "game_key": "gk_main_world_entry",
      "game_id": "world_main",
      "display_name": "Main World",
      "enabled": false,
      "max_players": 64
    }
  ]
}

The key variables you need to modify:

• game_key — references the key from gameinst_definitions.json. This tells the world which executable to launch.
• enabled — set this to true, launch the Go server, and you will have a world that any player can join without any further changes.
• max_players — the maximum number of concurrent players in that world.

Database

JMB supports both SQLite and Postgres. By default it uses SQLite — the database is a single file stored at data/jmb.db.

You can change the database name, save location, or switch between Postgres and SQLite through database.json:

{
  "target_db": "sqlite",
  "entries": [
    {
      "driver_name": "sqlite",
      "connection_string": "file:data/jmb.db?_pragma=..."
    },
    {
      "driver_name": "postgres",
      "connection_string": "..."
    }
  ]
}

To rename your database, modify the connection string — for example, changing data/jmb.db to data/mySuperCoolGame.db will create a database with that name instead.

Automatic backups

If you use SQLite, backing up is straightforward: the entire database is a single file. You can copy jmb.db anywhere you want as a manual backup. JMB also provides an automatic backup system.

Configure automatic backups in the database.json file:

"can_use_automatic_backups": true,
"backup_interval_minutes": 1440,
"max_backups": 10,
"backup_dir": "backups"

Backups are named in ascending order: backup_01 is always the oldest. For Postgres, backups are stored as .sql files instead of .db files.

The JMB SDK talks to the Go server through two channels: a REST client for one-off HTTP requests and a WebSocket client for real-time, persistent communication. Both are accessed through JMB_ServiceController, the singleton that holds all core service references.

Getting the service reference

Everything starts with JMB_ServiceController.get_instance(). From the returned service you can reach the REST client, WS client, and user manager.

var service: JMB_ServiceController = JMB_ServiceController.get_instance()
var rest_client: JMB_RESTClient = service.get_rest_client()
var ws_client: JMB_WSClient = service.get_ws_client()
var user_manager: JMB_UserManager = service.get_user_manager()

Logging in

Login is handled by JMB_UserManager. Call login() with a username or email and a password. The result comes back through the on_login_completed signal.

var service: JMB_ServiceController = JMB_ServiceController.get_instance()
var user_manager: JMB_UserManager = service.get_user_manager()

user_manager.on_login_completed.connect(_on_login_completed)
user_manager.login("player@example.com", "my_password")

func _on_login_completed(result: JMB_RequestResult) -> void:
	if result.status == JMB_RequestResult.Status.OK:
		print("Logged in successfully")
	else:
		print("Login failed")

Logging out

Call logout() on the user manager. It sends a logout request to the server, clears local credentials, and emits on_logout_completed. After logout you typically return to the main menu.

var user_manager: JMB_UserManager = JMB_ServiceController.get_instance().get_user_manager()
user_manager.logout()
get_tree().change_scene_to_file("res://scenes/main_menu.tscn")

Using the REST client

The REST client handles all HTTP calls to the Go server. Every method comes in two forms: a callback version and an async version that you can await.

var rest_client: JMB_RESTClient = JMB_ServiceController.get_instance().get_rest_client()

# Check server health (async)
var health_result: JMB_RequestResult = await rest_client.check_health_async()
print("Server is reachable: ", health_result.status == JMB_RequestResult.Status.OK)

# Read player variables (async)
var keys: Array[String] = ["score", "level"]
var read_result: JMB_RequestResult = await rest_client.read_qvars_async(account_id, keys)

Using the WS client

The WebSocket client maintains a persistent connection to the server. It handles lobby rooms, chat, match events, and any custom real-time messaging. You send typed envelopes and receive responses through signals or await.

var ws_client: JMB_WSClient = JMB_ServiceController.get_instance().get_ws_client()

# Listen for connection events
ws_client.on_ws_opened.connect(_on_connected)
ws_client.on_ws_closed.connect(_on_disconnected)

# Subscribe to a message category
await ws_client.subscribe_to_category_async("lobby")

# Send a custom envelope and await the response
var envelope: JMB_WSOutEnvelope = JMB_WSOutEnvelope.new()
var response: JMB_WSInEnvelope = await ws_client.send_envelope_async(envelope)

A summary of the most important calls available through the REST client and the WebSocket adapters.

REST client calls

All methods below are on JMB_RESTClient. Each has a callback and an _async variant. Only the async signatures are listed.

Auth & account

Profile

Player, world & bucket variables

Friends & blocking

Leaderboards & chat

WebSocket adapter calls

These methods live on the adapter classes, not on JMB_WSClient directly. The adapters are found via groups at runtime.

JMB_WSClient (core)

JMB_LobbyAdapter (room browsing)

JMB_LobbyRoomAdapter (inside a room)

JMB_ChatAdapter (messaging)

JMB_UserManager (auth state)

Network manager overrides

Your script extends JMB_NetworkManager (see part 2), and these are the callbacks you can override. All of them are optional no-ops by default — override only what you need. Server means it fires on the game-server build, Client on player builds, Both everywhere.

JMB_NetworkManager