Method document
Bot and load profiles per game
A load profile is a written recipe for what the server has to do during a test: how many players, doing what, for how long, in what world. GameServerBench has not run any of these. The profiles below are a design, published so they can be criticised before they cost anything.
Why idle bots are not enough
A bot that logs in and stands still costs the server far less than a player building, exploring or running a farm. Space-Node, a company that sells hosting, makes this point about modded Minecraft: most bot tools "do not build farms, run machines or open mod menus, and in a modded pack that is where the tick time goes". That is its reasoning and not a measurement, but it matches how these servers spend their time.
Each profile therefore starts from what makes that game's server work hard. Where a bot can't reproduce that work, the plan is to use a pre-built world or save that already contains it, plus recorded sessions of real play. Any bot profile would be compared against a recorded session first, to see whether it behaves like one at all.
Profiles by game
| Game | What loads the server | Planned approach | Open problem |
|---|---|---|---|
| All the Mods 10 | Automation and machines in a developed base | Replay of a pre-built automation world plus recorded player sessions, at 10, 20 and 30 players | Recording a session that represents a real group |
| Cobblemon | Entity spawns across explored chunks | Pack on a fixed version with moving players | Bot movement may not trigger realistic spawning |
| Modded Minecraft in general | Varies by pack | At least two packs on the same hosts | Choice of second pack |
| Palworld | Bases, Pals and player count over time | 4, 8 and 16 player runs, with a recorded session compared first; a 30-day run for long-run claims | Base idling is not assumed to match real play |
| Valheim | Explored world size, player count | Explored world copy at several player counts | Scripted movement in a 10-player design |
| Project Zomboid | Zombies, players, Build 42 animals | Fixed save and player counts | The build is changing; results may date quickly |
| Enshrouded | Slot count and world state | Runs by slot count on a fixed save | Whether load clients are practical at all |
| Hytale | Unknown until builds settle | Decide after the server documentation can be read | The game is in Early Access and changing |
| Satisfactory | Late-game factory simulation | A late-game save, logged server tick rate | Few players, so the save is the load |
| Rust | Population around wipe day | Not designed yet | Simulating a wipe-day population may not be feasible |
| 7 Days to Die | Blood-moon hordes | Scripted horde night | Quiet-hours readings would mislead |
Rules that apply to every profile
- The profile is fixed and published before any host is run. It doesn't change partway through a comparison.
- The world copy is restored before each run.
- Each run is long enough to include the game's expensive moments.
- Bot tools are used only where the host permits them. SoulFire's README, for one, limits its use to servers you own or have permission to test.
- Load stays within what the game itself generates. Flood or attack traffic is never part of a profile.
You can apply the same thinking to your own server with how to benchmark your own game server. The planned method covers what would be recorded during each profile.