Opengate

Opengate is an open-source space flight simulator fan project. It is inspired by the mechanics and flight physics of classic space simulations like the 2001 MMORPG sim Jumpgate. It starts as some kind of clone but might evolve into something different.

Opengate is written in python and uses the OGRE3D graphics engine.

Opengate is a hobbiest project and developed in rare spare time so don't expect to much rush in content development. However, its an open source project and you are very welcome to support as dev/artist/writer/tester/translater .. whatever you feel able to.

Feel free to join the Opengate HUB on Discord where you can find some kind of dev blog with some recent screenshots.

Getting started

python3 -m venv .venv
. .venv/bin/activate
pip install opengate-game

Then start the client (it connects to the public server):

og-launcher

Development plan

There is a coarse long term dev plan:

• 0.2 (Technical Proof of Concept (TPoC) to revive all features from the abandoned c++ code base 0.1)

  • All major game aspects: Graphics/Network/Sound/Collision/GUI/Console/GameStates are working in principle

• 0.3 (pre alpha - consolidation of the (TPoC))

  • Market/Ship configuration
  • Missiles, 2nd Sector (with some foe action)
  • No known open issues or missing features for the game aspects from 0.1
  • Rebase working branch to main, cleaning code (remove unused old code and assets)
  • Basic set of in-game content Materials and Textures(placeholder)
  • 2 Stations, Planet, Asteroids, Beacons, ...
  • Fixing file-formats for content descriptions
  • pip install target for linux/win/(mac)
  • Roleout for public Linux and Windows clients/updater (MacOS if hardware available)

• 0.4 (alpha release .. basic content phase)

  • Assetviewer, SectorDesigner and Ingame editor
  • Content rules
  • Basic content for 3 factions (artist, writer, modeller welcome ....)

• 0.5 (beta release .. Its a game now)

  • exp/missions/trade/production/sim mode
  • 10+ Sectors with full rule set and fully playable
  • permanent server

• Milestones >0.5

  All from here should be community driven .. if there is some.

Permanent detailed TODO list: (https://gitlab.com/Turb/opengate/doc/todo.md)

Starting the game and hosting a server

The game client needs a running server to be started. Until there is a permanent server and metaserver running, you need to start your own server to take a look into the game.

./og-server-launcher

With uv you can run the server without activating the environment first:

uv run ./og-server

(Equivalent to python -m Opengate.server.)

Headless server launcher

og-server assumes the game assets are already present. For a fresh machine (or a container) use the headless launcher instead: it obtains the assets (clone on first run, pull to refresh) — the same way the client launcher does — and then starts the server:

uv run ./og-server-launcher            # fetch/update assets, then serve
uv run ./og-server-launcher --no-update  # skip the fetch (assets already present)

Any other flags (-H, -P, --metrics-host, --bots, …) are passed straight through to the server.

Running the server with Docker

The server ships as a self-contained image that builds the native stack (Ogre/Bullet + the _bindings extension) and runs headless. Assets are fetched at startup by the launcher, so nothing needs to be baked in or mounted.

# Build and start (first build is slow — it compiles Ogre/Bullet from source):
docker compose up --build

# Or with plain docker:
docker build -t opengate-server .
docker run --rm -p 4242:4242/udp -p 9101:9101 opengate-server --metrics-host 0.0.0.0

Ports: 4242/udp (game), 9101 (health/metrics, /healthz + /metrics), 9102 (optional JSON API). Writable state (SQLite DB, config, logs) lives on the opengate-state volume at /opengate/state (via OPENGATE_CONFIG) so it survives image rebuilds.

Using the pre-built image from the registry

Every push to the default branch publishes an image to the project's GitLab Container Registry, so you can skip the local build entirely. The image is tagged :latest (latest default-branch build), :<branch-name> (the branch a build came from), and :<tag> for released git tags.

If the registry is private, log in first with your GitLab username and a personal access token (or a project deploy token) that has the read_registry scope — not your account password:

docker login registry.gitlab.com

Then pull and run:

docker run --rm \
  -p 4242:4242/udp \
  -v opengate-state:/opengate/state \
  registry.gitlab.com/turb/opengate:latest

To also reach the health/metrics and JSON API endpoints from the host, publish their ports and bind them to all interfaces (they default to localhost inside the container):

docker run -d --name opengate --restart unless-stopped \
  -p 4242:4242/udp -p 9101:9101 -p 9102:9102 \
  -v opengate-state:/opengate/state \
  registry.gitlab.com/turb/opengate:latest \
  --metrics-host 0.0.0.0 --api-host 0.0.0.0

Anything after the image name is passed straight through to the server (e.g. --bots 5, --assets-ref <branch>). To use the published image with docker compose, set the service's image: to registry.gitlab.com/turb/opengate:latest (replacing build: .) and run docker compose up -d.

In a different terminal you can start the client by running the launcher.

cd opengate
source .venv/bin/activate
./launcher

If you use uv, the equivalent command is:

cd opengate
uv run ./launcher

Administrative web UI

Opengate/server/admin/ holds a small Vue 3 + TypeScript console for inspecting a running server from the browser: online pilots, loaded sectors and stations, plus the status summary. It is read-only — it never mutates game state — and talks to the server's JSON API described below.

You need Node.js 20.19+ or 22.12+ (npm ships with it), as required by Vite 8. The UI is a separate npm project and is not part of the Python build.

1. Enable the JSON API

The API is off by default. It starts only when a bearer token is configured, so exposing it is always an explicit opt-in. Add one to .opengate.toml (the same config file the game uses — with OPENGATE_CONFIG set, it lives there instead):

[api]
token = 'pick-a-long-random-string'

Then start the server as usual:

uv run ./og-server

It logs API: JSON API on http://127.0.0.1:9102/api once the API is up. With no token you get API: no [api].token in config; JSON API disabled. and the port is never bound. --api-host / --api-port change where it listens.

2. Build the console

bash .workflow.sh webui

This runs npm ci && npm run build in Opengate/server/admin and writes the bundle to admin/dist/. It is also run by bash .workflow.sh dist, so a packaged build carries the console. npm is not a dependency of the game: if it is missing the step warns and skips, and the server simply starts without the console.

Restart the server and open http://127.0.0.1:9102/admin/. It logs

API: admin console on http://127.0.0.1:9102/admin/

Paste the token from [api].token on the sign-in screen. It is kept in the browser's localStorage, so a reload does not ask again; "Sign out" clears it.

That is the whole production setup. The console is served by the game server itself, from the same listener as the API, so both share an origin — no reverse proxy and no CORS configuration. Put a TLS terminator in front if the port is reachable from anywhere but localhost.

A pip install of the wheel includes the built console (it ships as package-data), so an installed server serves /admin/ with no extra steps.

3. Developing the console

For work on the UI itself, the Vite dev server adds hot reloading:

cd Opengate/server/admin
npm install          # first run only
npm run dev

Open http://localhost:5173/admin/. It proxies /api to http://127.0.0.1:9102, keeping requests same-origin against a running server. If the server listens elsewhere, point the proxy at it:

OPENGATE_API_URL=http://192.168.1.10:9102 npm run dev

npm run preview serves the built bundle on :4173 with that same proxy — a local smoke test of the production build, not a deployment.

Security. The API has no transport encryption and its token grants full control of the server, including stopping it. Keep both the API and the UI on localhost or a private network unless you put a TLS terminator in front. Note that the read endpoints (/api/status, /players, /sectors, /stations) are not token-gated: anyone who can reach the port can read pilot names, credits and station occupancy. Only /api/config and the write actions require the token.