This Week In Veloren 133

This week, we hear about updates to the state of terrain persistence. There are also optimizations being worked on with our real-time simulation system. A brief overview of our server history is also included.

- AngelOnFira, TWiV Editor

Contributor Work

Thanks to this week's contributors, @alykhouzov, @ygor.souza, @Sam, @juliancoffee, @imbris, @zesterer, @DanTheOne, @DaniilNemtsev, @xMAC94x, @nwildner, @xeriab, @tygyh, and @klipkonn.

You can read this week's meeting notes here.

RTSim optimizations by @ubruntu

This is still a work in progress, but last week I worked on splitting up the iteration of RTSim entities so that each entity is updated every n ticks (whatever that number ends up being). Hopefully, this improves performance a little as RTSim entities don't need their simulated behavior to happen every server tick when they are off-screen and away from players. This shouldn't cause any noticeable changes for players.

Terrain persistence by @zesterer

Last week, the min_persistent_world branch was merged.

It adds an experimental terrain persistence system. When enabled, changes made to the world with build mode will be written to disk and will not disappear on server restart or chunk unload.

It comes with some very big caveats: the system is not intended to be a player-facing or a general-purpose build system. It is not stable, well-integrated into the rest of the game, nor do we guarantee support for it moving forwards. Additionally, it is intended to be replaced entirely in the future (with no migration) with a proper player-oriented zone-based building system. Things can and will break!

It exists primarily as a way for server admins to add small customisation to their worlds to improve the experience for players.

See this page in The Book for more detailed information about terrain persistence. Here are a few ideas for things that server admins could use the feature for:

• Gliding courses demarcated with pillars and hoops for glider racing.
• A custom spawn zone complete with crafting stations and meeting areas for players.
• Mining challenges (using mineable blocks like WeakRock and ores) that players can partake in. Because mining is not persisted, any mined blocks will naturally regenerate when the chunk reloads!
• Custom mazes and climbing/jumping challenges for players with rewards in the form of chests/ores/etc.
• Pixel artwork and sculptures dotted around the world for players to find.
• Visual customisations to existing world structures like towns and dungeons that make them more interesting to explore.

If you end up making something interesting with the feature, please tell us! We'd like to see what you come up with. Feedback is also appreciated, although bear in mind that the feature is not supposed to be extensive or player-facing.

A brief history of our servers by @AngelOnFira

The following was taken from a thread on the Bevy Discord about server costs.

Just happened across this thread, and although I don't know the entire context, I can give some interesting stats from Veloren. We used to host our main game server out of the basement of one of our devs. But when we had release parties, we would expect around 50 players to join. At the time, we were used to around 1 MB/s of bandwidth per player, and so over a release party, we normally saw around 100 GB of bandwidth used. We were hosting on Digital Ocean and AWS.

Over the last few months, we've been transferring all of our servers over to Hetzner in Germany. Their bandwidth costs are pretty great for cloud servers, 20 TB/month for any instance, and about 1.20 Euros for every Terabyte after. It is still difficult to do NA game servers though. But for distributing our game binary and assets, it works quite well.

A rough estimate from our dashboard shows that we get about 700 downloads per day, and our download size is around 160 MB. So that's about 110 GB of download bandwidth per day. We are running this on a dedicated server Hetzner server though, which has no bandwidth cap.