The same world on every screen
Block worlds with biomes, creators' own game packages and whole maps loaded into a running world. The server decides, and every player's game builds the same world from a few settings.
The last two posts were about how many players fit on one server. This one is about the world they play in. Three things landed for creators since then: block worlds that players dig and build in, private game packages with a creator's own Unreal Engine content, and map instances that load whole maps into a running world. All three follow one rule from our netcode: the server decides, and every player's game ends up with exactly the same world.
Block worlds from one Lua call
A creator switches a block world on with one call in a server script, EnableBlockWorld, without writing any C++. The terrain comes from a seed. The generator is one piece of code shared by the game, the test server and the tests, so all of them build the same world, block for block.
Players break blocks with the left mouse button and place them with the right one, and pick a block from the hotbar with the number keys. A click alone changes nothing. The request goes to the server, and the server checks it first: is the player close enough and not too fast, does the block fit, is nobody standing in the way. Only then do the game's scripts get their say in blockBreak and blockPlace, where they can cancel the edit. If the edit passes, every player sees the change. If not, only the player who clicked is corrected.
Changes are saved and come back after a restart. A save made for a different seed or different biomes is set aside instead of being loaded into the wrong world.
Settings, not trees
Block worlds can now have biomes, and biomes have plants: trees, bushes, rocks and grass from the creator's own game package. A forest holds thousands of plants, and sending each one over the network would cost bandwidth for every player. So we don't send them.
The server sends the world's settings once: the seed, the biomes and up to 256 plant rules with density, spacing and size. Every player's game then works out the plants for each cell of 64 × 64 blocks by itself. Size, lean and depth are rounded to the same small steps the engine uses to replicate them, so the server, every player and our test tools put every plant in the same spot. Plants you can bump into get collision only near characters, the same way on the server and in every game. When the block under a plant is dug away, the plant goes with it.
Biome borders blend their heights over a band, so there are no cliffs where one biome meets the next. Worlds without biomes stay exactly as they were, block for block.
Bring your own content
Block worlds are one way to build. The other is a creator's own Unreal Engine content: maps, models, sounds, and images for web interfaces. Creators cook that content into a game package for one GAMPEON release and upload it to their project, in pieces of up to 64 MB, so a broken upload continues where it stopped. Before a game or a server loads a package, it checks that the package was cooked for its GAMPEON release, and stops with a clear message if not. Players of the project's servers get the package through the launcher when they press Play. While a game is not published yet, its servers are closed test servers that only its team can see and join.
We measured the whole path with the first creator game on GAMPEON:
| One creator game | Size |
|---|---|
| Source content in the project | 743.6 MB |
| Cooked client package | 257.2 MB |
| Cooked server package, without texture data | 52.4 MB |
| Download for players, with web interface files | 270.4 MB |
Unpacked, the client package holds 2,146 MiB, so compression saves about 8:1. Cooking client and server took about 4 minutes.
Whole maps, loaded into a running world
Map instances go one step further. With LoadMapInstance, a script loads a whole map from its game package into the running world, for example a village into a block world. The server and every player load it under the same name. The loaded map's own sky, sun and fog are switched off, so the world keeps one sky.
In the first test, two copies of a demo map with 4,565 actors each went into a running city map, with a dedicated server and two players, one of them joining two minutes later.
| Map instance test | Until visible |
|---|---|
| Server, copy 1 | 2.4 s |
| Server, copy 2 | 2.9 s |
| Players | 3.6 to 8.7 s |
Frame times in and next to the loaded copies stayed about the same as in the rest of the city.
Small tools for every game
Every game can also use the new Sandbox-Kit from Lua: an interaction key, a player inventory, compass markers, and quests with stages and objectives. Games with their own interface can hide parts of the built-in HUD and draw those pieces themselves.
What these numbers do not say
- One game, one test each. The package sizes come from one creator game, cooked once. The map instance times come from one test in an editor build on a test machine, not from packaged builds over the internet.
- Plants are not measured yet. Biomes and plants work on the server and in the game, but we have no frame time measurements for large forests yet.
- Block edits are tested with few players. The server checks every edit, but we have not yet had a crowd of bots digging at the same time.
- The next performance round from the last post is not written up yet. Its numbers get their own post once the load test report is done.
What's next
- Game packages: the creator kit as a download, and servers that fetch their own package from GAMPEON.
- Block worlds: your own block types and textures.
- Server performance: the full report of the next round.
The short version of every change is in the changelog.
GAMPEON Team · Drafted with our AI assistant from the work we merged, and reviewed by the team before publishing.