## Summary
Follow-up to #4230. Two more core-sim optimizations — these are
**behavior-affecting in controlled ways** (unlike #4230, which was
hash-identical), so both come with dedicated test coverage written
before the change.
Combined results (`npm run perf:game`, same machine, before → after):
| run | mean tick | ticks/sec | p99 | peak heap |
|---|---|---|---|---|
| default (world, 400 bots, 1800 ticks) | 7.98 → **6.96 ms** | 125 →
**144** | 21.2 → **19.0 ms** | 438 → **294 MB** |
| giantworldmap, 600 ticks | 17.4 → **15.2 ms** | 58 → **66** | 32.6 →
30.5 ms | |
Cumulative with #4230 vs. the original baseline: default run mean 9.04 →
6.96 ms (111 → 144 ticks/sec); giantworldmap 22.5 → 15.2 ms (44 → 66
ticks/sec, max tick 52.8 → 40.1 ms).
### 1. `PseudoRandom`: seedrandom ARC4 → inline sfc32
- ARC4 was ~4% of profiled self time. The new engine is sfc32 with
splitmix32 seed expansion and a warmup, using only 32-bit integer ops —
sequences are identical across platforms. The class API is unchanged.
- This **removes the `seedrandom` dependency entirely**, making
`src/core` actually dependency-free (the import was the only violation
of that rule).
- ⚠️ **The random stream differs, so the deterministic game-state hash
changes.** All clients run the same code, so cross-client sync is
unaffected; the harness reproduces the same hash on repeated runs per
seed. New reference hashes:
- `--map world --ticks 200 --bots 100` → `5607618202213430`
- default run → `29309648281599524`
- `--map giantworldmap --ticks 600` → `39945089450032050`
- New `tests/PseudoRandom.test.ts` (15 tests) pins the engine-agnostic
contract: per-seed determinism, ranges, uniformity, adjacent-seed
decorrelation, and every API method. The tests were verified green
against the old engine first, then the swap.
- The stream change exposed a test that passed **by RNG luck**: in
`AiAttackBehavior.test.ts`, "nation cannot attack allied player" was
actually being blocked by the difficulty dice gate in `shouldAttack`,
not the alliance check — hiding that the test's `AiAttackBehavior` was
constructed without its `NationEmojiBehavior`. The test now supplies one
and verifies the real protection layer (`AttackExecution`'s alliance
check), robust to any dice outcome.
### 2. `PlayerImpl.toFullUpdate`: allocation-free empty collections
- `toFullUpdate` runs for every player every tick and allocated ~10
collections each (allies, embargoes Set, attacks, alliance views, …)
even when all were empty — the common case for most of 472 players.
Because `lastSentUpdate` retains each snapshot for a full tick, these
objects survived minor GC, got promoted, and accumulated as old-space
garbage between major GCs — that's the peak-heap drop.
- Empty collections now reuse shared **frozen** module-level singletons,
so `diffPlayerUpdate`'s existing `a === b` fast paths skip structural
comparison entirely. Non-empty collections build in single passes.
Freezing makes accidental in-worker mutation throw loudly instead of
silently corrupting every player; consumers across the worker boundary
get mutable structured clones as before. (`Set` cannot be frozen —
`EMPTY_EMBARGOES` is documented as never-mutate.)
- Value-identical: the game-state hash is unchanged by this part
(verified against the post-PRNG baseline).
- New `tests/PlayerUpdateDiff.test.ts` (8 tests): full-snapshot shape,
null-when-unchanged, embargo/alliance/target/attack diffs through the
real tick pipeline, and the freeze contract.
### Verification
- Full suite passes: 124 files / 1408 tests (23 new) + server tests;
lint and prettier clean.
- Hash reproducibility confirmed: repeated runs with identical args
produce identical hashes on all three configs.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
## Description:
This PR fixes the `Invalid coordinates: NaN,NaN` crash during Warship
patrol execution.
### Root cause
`WarshipExecution.randomTile` picks a patrol destination inside
`warshipPatrolRange / 2` of the current patrol tile. When a search fails
to find a valid tile, the range expands by 50% per retry (`100 → 150 →
225 → 337`) and becomes odd. Once odd, `warshipPatrolRange / 2` is a
float (e.g. `112.5`), which is handed straight to
`PseudoRandom.nextInt`:
```ts
Math.floor(this.rng() * (max - min)) + min;
```
With a float `min`, this returns `integer + float` - a float. Despite
its name, `nextInt` was silently returning a non-integer. From there:
- `x = mg.x(patrolTile) + floatOffset` → float
- `mg.isValidCoord(floatX, floatY)` → `true` (only bounds were checked)
- `mg.ref(floatX, floatY)` → `yToRef[floatY] + floatX` → `undefined +
float` → `NaN`
- `hasWaterComponent(NaN, …)` → `miniMap.ref(NaN, NaN)` → **throw**
### Why this only started crashing recently
The float‑leaking `nextInt` bug has been latent since at least the
pathfinding refactor (#2866, January), which introduced the
`hasWaterComponent` check. It was invisible because the guard directly
above it short‑circuited on `NaN`:
```ts
if (!this.mg.isOcean(tile) || (!allowShoreline && this.mg.isShoreline(tile))) continue;
```
For a `NaN` tile ref, `terrain[NaN]` is `undefined`, so:
- `isOcean(NaN)` → `Boolean(undefined & OCEAN_BIT)` → **`false`**
- `isLand(NaN)` → **`false`**
- `isWater(NaN)` → `!isLand(NaN)` → **`true`**
Before: `!isOcean(NaN)` was `true`, execution hit `continue`, and the
poisoned ref never reached `hasWaterComponent`. The "Trading in lakes"
PR (#3653) relaxed that single line to allow patrol on lakes:
```diff
- if (!this.mg.isOcean(tile) || ...) continue;
+ if (!this.mg.isWater(tile) || ...) continue;
```
Because `isWater(NaN)` is `true`, `!isWater(NaN)` is now `false` -
execution falls through to `hasWaterComponent(NaN, …)` and crashes.
#3653 didn't introduce the bug; it just happened to remove the
accidental NaN filter that was hiding it.
### Changes
- **`PseudoRandom.nextInt`** - root‑cause fix. Floors both `min` and
`max` so `nextInt` always returns an integer regardless of what callers
pass. Future callers can't re‑trip this trap.
- **`WarshipExecution.randomTile`** - replaced the unsafe
`this.warship.patrolTile()!` non‑null assertion with a proper
`undefined` guard that returns early.
- **`GameMap.isValidCoord`** - defense in depth: also requires
`Number.isInteger(x)` and `Number.isInteger(y)`. Non‑integer coords can
still be produced outside `nextInt` (trig, arithmetic); this makes
`ref()` fail loudly at the boundary instead of silently producing `NaN`
refs.
### Original stacktrace
Please paste the following in your bug report in Discord:
Game crashed!
game id: gGicMpDh
client id: wXE5SpT2
Error: Invalid coordinates: NaN,NaN
Message: Error: Invalid coordinates: NaN,NaN
at at.ref
(https://nightly.openfront.dev/assets/Worker.worker-DL_guV2P.js:31:64853)
at r_.hasWaterComponent
(https://nightly.openfront.dev/assets/Worker.worker-DL_guV2P.js:31:243326)
at l_.hasWaterComponent
(https://nightly.openfront.dev/assets/Worker.worker-DL_guV2P.js:31:260740)
at b1.randomTile
(https://nightly.openfront.dev/assets/Worker.worker-DL_guV2P.js:31:92634)
at b1.patrol
(https://nightly.openfront.dev/assets/Worker.worker-DL_guV2P.js:31:91728)
at b1.tick
(https://nightly.openfront.dev/assets/Worker.worker-DL_guV2P.js:31:89996)
at
https://nightly.openfront.dev/assets/Worker.worker-DL_guV2P.js:31:251463
at Array.forEach (<anonymous>)
at l_.executeNextTick
(https://nightly.openfront.dev/assets/Worker.worker-DL_guV2P.js:31:251383)
at p_.executeNextTick
(https://nightly.openfront.dev/assets/Worker.worker-DL_guV2P.js:31:271256)
Discord:
https://discord.com/channels/1284581928254701718/1494336024740888667
## Please complete the following:
- [X] I have added screenshots for all UI updates
- [X] I process any text displayed to the user through translateText()
and I've added it to the en.json file
- [X] I have added relevant tests to the test directory
- [X] I confirm I have thoroughly tested these changes and take full
responsibility for any bugs introduced
## Please put your Discord username so you can be contacted if a bug or
regression is found:
FloPinguin
## Description:
in src/core/pseudorandom.ts
a helper function of nextint is defined but never used.
instead, this.rng is used. those are replaced.
also, shuffleArray originally would self-shuffle at i=0 for the
conditional being i>=0, fixed to 0.
## Please complete the following:
- [X] I have added screenshots for all UI updates
- [X] I process any text displayed to the user through translateText()
and I've added it to the en.json file
- [X] I have added relevant tests to the test directory
- [X] I confirm I have thoroughly tested these changes and take full
responsibility for any bugs introduced
## Please put your Discord username so you can be contacted if a bug or
regression is found:
jack_45183
## Description:
The previous implementation had a bug that biased numbers away from 0,
so random.chance(1500+) would always return false. This caused trains to
not spawn at all when their spawn rate was sufficiently low. We should
be using a library instead of implementing it from scratch anyways.
## Please complete the following:
- [x] I have added screenshots for all UI updates
- [x] I process any text displayed to the user through translateText()
and I've added it to the en.json file
- [x] I have added relevant tests to the test directory
- [x] I confirm I have thoroughly tested these changes and take full
responsibility for any bugs introduced
## Please put your Discord username so you can be contacted if a bug or
regression is found:
evan
## Description:
Add a rail network to handle train stations/railroad between structures.
Changes:
- `RailNetwork` is responsible for the train station graph. Use it to
connect new `TrainStations`
- A `RailRoad` connects two `TrainStation`
- No loop possible in the rail network
- Train stations handles its railroads
- Added a layer to draw the railroads under the structures
#### Clusters
- To speed up computations, each `TrainStation` references its own
cluster
- A cluster is a list of `TrainStation` connected with each other,
created by the `RailNetwork` when connecting the station
- Train stations spawn trains randomly depending on its current cluster
size
- A `TrainStation` decides randomly of the train destination by picking
one from the cluster
#### Production building:
- Added a factory which has no gameplay impact currently. _To be
discussed._
#### Train stops:
- When a train reaches a factory, it's filled with a "cargo". The loaded
trains has no impact currently. _To be discussed._
- When a train reaches a city, the player earn 10k gold
- When a train reaches a port, it sends a new tradeship if possible
- If a destination/source is destroyed, the train & railroad are deleted
too
https://github.com/user-attachments/assets/42375c17-9e04-4a42-98d0-708c81ffd609https://github.com/user-attachments/assets/fbecdb53-a516-4df8-87fb-1f9a62c4efa0
## Please complete the following:
- [x] I have added screenshots for all UI updates
- [x] I process any text displayed to the user through translateText()
and I've added it to the en.json file
- [x] I have added relevant tests to the test directory
- [x] I confirm I have thoroughly tested these changes and take full
responsibility for any bugs introduced
- [x] I understand that submitting code with bugs that could have been
caught through manual testing blocks releases and new features for all
contributors
## Please put your Discord username so you can be contacted if a bug or
regression is found:
IngloriousTom
---------
Co-authored-by: Scott Anderson <scottanderson@users.noreply.github.com>
## Description:
Added XorShift algo for better random number generation
## Please complete the following:
- [x] I have added screenshots for all UI updates
- [ ] I have added relevant tests to the test directory
- [x] I process any text displayed to the user through translateText()
and i've added it to the en.json file
- [x] I confirm I have thoroughly tested these changes and take full
responsibility for any bugs introduced
- [x] I understand that submitting code with bugs that could have been
caught through manual testing blocks releases and new features for all
contributors
## Please put your Discord username so you can be contacted if a bug or
regression is found:
@qqkedsi
---------
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
## Description:
Improve type safety and runtime correctness by:
1. Enabling TypeScript's
[strictNullChecks](https://www.typescriptlang.org/tsconfig/#strictNullChecks)
compiler option.
2. Replacing all loose equality operators (`==` and `!=`) with strict
equality operators (`===` and `!==`).
3. Cleaning up of type declarations, null handling logic, and equality
expressions throughout the project.
Currently, the code allows implicit assumptions that `null` and
`undefined` are interchangeable, and relies on type-coercing equality
checks that can introduce subtle bugs. These practices make it difficult
to reason about when values may be absent and hinder the effectiveness
of static analysis.
Migrating to strict null checks and enforcing strict equality
comparisons will clarify intent, reduce bugs, and make the codebase
safer and easier to maintain.
Fixes#466
## Please complete the following:
- [x] I have added screenshots for all UI updates
- [x] I confirm I have thoroughly tested these changes and take full
responsibility for any bugs introduced
- [x] I understand that submitting code with bugs that could have been
caught through manual testing blocks releases and new features for all
contributors
---------
Co-authored-by: Scott Anderson <662325+scottanderson@users.noreply.github.com>
Co-authored-by: evanpelle <openfrontio@gmail.com>
Evan