📄️ How to build a game
CELTE works the following way:
📄️ Building your game with CELTE
This section collects practical pages and how-tos for integrating CELTE into your Godot game. It targets game developers using the Celte runtime (demo code in celte-godot/projects/demo-tek), and covers setup, runtime flows, spawning, replication, and editor tooling.
📄️ CELTE YAML configuration (~/.celte.yaml)
The Celte server reads configuration from a YAML file by default located at ~/.celte.yaml. All processes in the Celte ecosystem (master, clock server, automation scripts) can use this file to load common configuration values such as Redis host/port, Pulsar broker address, Godot executable path, and other settings. Only the game client does not require it (or rather, it is left to the game developer to decide how to configure the client. Our example client code uses this config but it is bad design to have clients read from ~/.celte.yaml).
📄️ The Master API
The Master API (master server) exposes HTTP routes to control game sessions, create and accept server nodes, connect clients, and manage session-scoped Redis data. One or more master servers can run for fault resilience; they provide a small JSON-over-HTTP API on port 1908 by default.
📄️ Lobby server
This page documents the purpose and design of a lobby server in the Celte architecture, explains how the provided Go example implements a lobby, and describes how to write a generic lobby that interacts with the Master API.
📄️ Hosting the game (development & production)
This page explains how to host a Celte-based game during development and in production. It uses artifacts and conventions from this repository: the provided Docker Compose for local/dev stacks, a Helm chart for Kubernetes deployment, and small helper services (lobby, master, Pulsar, Redis).
📄️ Coding-your-game
Coding your game with CELTE
🗃️ Coding-steps
10 items