Evan
7ec26df4b4
## Summary A performance review of `src/client/render/` found three issues where per-tick work silently defeated existing optimizations. All three are surgical fixes with no behavior change. ### 1. Relation matrix forced a full-map border recompute every tick `buildRelationMatrix` ran unconditionally every tick and `updateRelations` was pushed unconditionally, so every tick paid: - a 1 MB `fill(0)` + rebuild on the CPU, - a 1 MB `texSubImage2D` upload (~10 MB/s steady-state), - a **full map-resolution border fragment pass** via `globalDirty` — which also called `scatter.clear()`, making the incremental `BorderScatterPass`/`patchTile` path dead code during live play. Now the matrix is rebuilt and uploaded only when alliances/embargoes actually change. `PlayerUpdate`s are delta-encoded (`diffPlayerUpdate` content-compares `allies`/`embargoes`), so field presence is a reliable change signal. The WebGL context-restore path force-pushes relations, matching the existing structures/railroads pattern. ### 2. Heat decay pass + full-map blit ran every frame, forever `HeatManager.decayHeat()` set `heatActive = true` on every tick regardless of whether any fallout existed. With `heatDecayPerTick: 1` the drain window (255 ticks) was always re-armed before expiring, so the map-sized decay/transition fragment pass **plus a full-map R16UI `blitFramebuffer`** ran at 60 Hz for the entire game — even if no nuke was ever fired. On large maps this was likely the biggest fixed GPU cost in the renderer. Now `TerritoryPass` flags FALLOUT-bit flips at GPU-write time (delta, drip-drain, and conservatively on full uploads), and the renderer activates the heat pipeline only then. While inactive, `updateHeat()` does no GL work at all. Skipping the prev-tile blit while inactive is safe because the transition shader only reads the fallout bit, and every fallout flip activates the pipeline before its tile flush reaches the GPU. ### 3. `computePlayerStatus` was O(players × units) per tick The per-player loop scanned **all units** looking for that player's nukes (~1M+ iterations/tick at scale). Inverted to a single pass over units building per-owner `nukeActive`/`nukeTargetsMe` sets, then O(1) lookups in the player loop. ## Testing - Full suite passes (1386 + 65 tests), including the 19 existing `computePlayerStatus` behavior tests; `tsc --noEmit` and ESLint clean. - Verified in a live singleplayer game (headless Chromium): territory fill, borders, names/troop counts, and leaderboard all render correctly. - Fallout path verified end-to-end: built a missile silo, launched an atom bomb (1235 fallout tiles in tile state), and the fallout glow rendered at the impact site — under the new gating that glow can only appear if the `falloutTouched → activate()` chain works. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
OpenFront.io is an online real-time strategy game focused on territorial control and alliance building. Players compete to expand their territory, build structures, and form strategic alliances in various maps based on real-world geography.
This is a fork/rewrite of WarFront.io. Credit to https://github.com/WarFrontIO.
License
OpenFront source code is licensed under the GNU Affero General Public License v3.0
Current copyright notices appear in:
- Footer: "© OpenFront and Contributors"
- Loading screen: "© OpenFront and Contributors"
Modified versions must preserve these notices in reasonably visible locations.
See the LICENSE for complete requirements.
For asset licensing, see LICENSE-ASSETS.
For license history, see LICENSING.md.
🌟 Features
- Real-time Strategy Gameplay: Expand your territory and engage in strategic battles
- Alliance System: Form alliances with other players for mutual defense
- Multiple Maps: Play across various geographical regions including Europe, Asia, Africa, and more
- Resource Management: Balance your expansion with defensive capabilities
- Cross-platform: Play in any modern web browser
📋 Prerequisites
- npm (v10.9.2 or higher)
- A modern web browser (Chrome, Firefox, Edge, etc.)
🚀 Installation
-
Clone the repository
git clone https://github.com/openfrontio/OpenFrontIO.git cd OpenFrontIO -
Install dependencies
npm run instDo NOT use
npm installnornpm ibut instead use ournpm run inst. It runs the safernpm ci --ignore-scriptsto install dependencies exactly according to the versions inpackage-lock.jsonand doesn't run scripts. This can prevent being hit by a supply chain attack.
🎮 Running the Game
Development Mode
Run both the client and server in development mode with live reloading:
npm run dev
This will:
- Start the webpack dev server for the client
- Launch the game server with development settings
- Open the game in your default browser (to disable this behavior, set
SKIP_BROWSER_OPEN=truein your environment)
Client Only
To run just the client with hot reloading:
npm run start:client
Server Only
To run just the server with development settings:
npm run start:server-dev
Connecting to staging or production backends
Sometimes it's useful to connect to production servers when replaying a game, testing user profiles, purchases, or login flow.
To replay a production game, make sure you're on the same commit that the game you want to replay was executed on, you can find the
gitCommitvalue viahttps://api.openfront.io/game/[gameId]. Unfinished games cannot be replayed on localhost.
To connect to staging api servers:
npm run dev:staging
To connect to production api servers:
npm run dev:prod
🛠️ Development Tools
-
Format code:
npm run format -
Lint code:
npm run lint -
Lint and fix code:
npm run lint:fix -
Testing
npm test
🏗️ Project Structure
/src/client- Frontend game client/src/core- Deterministic game simulation/src/server- Backend game server/resources- Static assets (images, maps, etc.)
🤝 Contributing
Contributions and translations are welcome! See CONTRIBUTING.md for the workflow, the approved-issue process, project governance, and translation info.