og-bot-discord

A Discord bot for the OGame community. It reads Gameforge's public OGame API and helps players with day-to-day tasks: looking up players and their planets, computing trade rates, estimating expedition cargo, generating moon-lock galaxy links, listing alliance members and computing moonbreak (lune) destruction probabilities.

The bot has been running for a long time on the French OGame Discord. This version is modernized (Node 24 + ESM, discord.js v14) so any community/country can run its own instance.

All commands are triggered by a prefix in any channel the bot can read. <n°> is the server number and <lang> the community code (fr, en, de, es, …), matching the API host s<n°>-<lang>.ogame.gameforge.com.

• Node.js >= 24 (the ogamejs dependency requires it).
• A Discord application + bot token.
• Optionally Docker for deployment.

1. Create an application at the Discord Developer Portal.
2. Add a Bot and copy its token.
3. Under Bot → Privileged Gateway Intents, enable Message Content Intent. The bot reads message text to detect commands and will not work without it. Without it, client.login() fails outright with Used disallowed intents.
4. Invite the bot to your server (see below).

Replace YOUR_APPLICATION_ID with the Application ID from the Developer Portal:

https://discord.com/oauth2/authorize?client_id=YOUR_APPLICATION_ID&permissions=84992&scope=bot

permissions=84992 is the minimum this bot actually needs:

Embed Links is the one that is easy to miss. Without it the bot connects, sees commands, and silently fails on every command that replies with an embed — which is most of them. The catch in index.js then tries to send the help message, which is also an embed, so nothing appears at all.

No applications.commands scope: this bot uses prefix commands (!ogp, !mb), not slash commands.

If the bot joins but stays silent, check channel-level permission overrides first — they take precedence over the role permissions granted by this link.

The bot reads three environment variables:

npm install
DISCORD_TOKEN=your-token npm start

Prefer a .env file? It is git-ignored, and Node reads it natively — no dependency needed:

echo 'DISCORD_TOKEN=your-token' > .env
node --env-file=.env index.js

The token is injected at runtime (never baked into the image):

docker build -t og-bot:latest .
docker run --name og-bot -d --restart unless-stopped \
  -e DISCORD_TOKEN=your-token og-bot:latest

The bot exposes a single HTTP route on PORT (default 8080), used by container platforms to tell a live bot from a stuck one:

GET /health  ->  200 {"status":"ok","user":"…","guilds":3,"uptime":42}
             ->  503 {"status":"connecting", …}  while the gateway is down

Deployment is fully automated. Pushing to master runs .github/workflows/deploy.yml, which lints and tests, builds and pushes the image to GHCR, then asks Scaleway Serverless Containers to redeploy it and waits until the container reports ready.

The bot runs as a single always-on instance (min_scale = max_scale = 1): it holds a persistent gateway connection, so it must never be scaled to zero, and never run twice — two instances would answer every command twice.

Infrastructure lives in a separate repository and is managed with Terraform. This repository never runs Terraform; it only needs three secrets:

DISCORD_TOKEN is not among them. It is stored as an encrypted environment variable on the container itself and injected at startup, so it never reaches the CI and is never present in an image layer.

npm run lint    # ESLint (flat config, eslint.config.js)
npm test        # node:test smoke tests for the pure functions

The bot consumes Gameforge's public XML API (verified working in 2026):

• https://s<n°>-<lang>.ogame.gameforge.com/api/serverData.xml
• .../api/players.xml, .../api/universe.xml, .../api/playerData.xml?id=<id>
• .../api/alliances.xml

These endpoints refresh roughly once a day, so player/planet data reflects the last daily snapshot rather than live positions.