This Week In Veloren 56

This week we keep pushing onwards towards The Content Update. Work on server persistence is being done, and we take a look at its progress. Level of detail changes are on their way, and we see some of their screenshots.

- AngelOnFira, TWiV Editor

Contributor Work

Thanks to this week's contributors, @Slipped, @Pfau, @Shandley, @AngelOnFira, @imbris, @Juli199696, and @Songtronix!

@Songtronix is hard at work on Airshipper. This week, self-updating for Windows was completed, and it also now prunes outdated assets to save disk space. @xMAC94x is working on benchmarks for networking, which should be completed in the next week or so. @Juli199696 is working on a server configuration tool that will help users set up their own servers.

@imbris has taken up the torch on auth this week. They worked on some user-friendliness fixes, such as case sensitivity and hidden password text. @octo and @Snowram have been working on potential theme music, as well as other tracks. @Timo has been working on the character state branch. Now, climbing and rolling require stamina. This is not yet on master.

@AngelOnFira, @TheDip, and @Griffin have been putting in lots of work to player persistence. All of them are new contributors to the engine, so a lot of mistakes were made along the way. @Zesterer and @Treeco are continuing work on level of detail. There will be more news on it next week as it becomes more ready to merge.

Persistence by @AngelOnFira

Hey everyone! This week, I stepped away from my main meta focus. There was a call for a proof-of-concept (PoC) on server persistence, and I thought I would take the reigns. It was a task without a large scope, and it shouldn't need to touch too much of the codebase. Along the way, I got a lot of help from @TheDip and @Griffin.

The goal of this PoC was to create a way for the server to save a player's level when they leave the server. It just needed to be implemented for the server, since singleplayer actually runs a server in the background anyway. There are a few steps to this entire process:

1. Figure out a database to use
2. Set up simple database interaction test
3. Hook up the player stats
4. Optimize method used

1. Database Options

This step is important to get right. We want to make sure we choose an option that will be sustainable for future development, and scalable where needed. It also needs to be as concealed as possible, and shouldn't require setup for someone running a server. We chose to go with SQLite as the database.

SQLite saves the database as a file anywhere you like, and doesn't need to be hosted separately from Veloren. On top of that, it can be bundled into the server executable, and so it is pretty much invisible.

We are also using the Diesel library to interact with the SQLite database. This gives us a lot more features, such as migrations and data models. Migrations allow us to add and remove tables in the database over different updates, so that we don't have to wipe the database with each version.

Data models give us a separation between our use of the data in-engine and how the database views it. Instead of having to deal with datatypes when we fetch it from the database, Diesel takes care of it for us.

2. Sample Database Interaction

For this, we just followed the Diesel tutorial. We had to make some notable changes to the default architecture, however. Our persistence module is a child of the server. Diesel expects itself to be on the top level of a crate. We had to set up the migrations and schema directory to be on the same level as the module.

3. Player Stats

This step allowed us to look a bit more into what we would be storing in the database. At first, we just stored the exact exp. After showing this off to others, it was mentioned that we should just store a Stats object in its entirety. This includes everything about a player, such as a name, level, and items. After hooking this up, the PoC was ready.

4. Optimizing

Throughout the implementation, we fell down rabbit holes of trying to optimize too early. This is easy to do, and speculation on this kind of tech can be really fun. But it can get very abstract quite quickly. We were already talking about query optimizations and read speed when we weren't even sure how the architecture would look.

Since this was our first time really implementing something on the engine, we must get good feedback. So although the PoC is ready, it must be regarded as something that should be torn down if it doesn't complete its objectives properly. That's why it only implements a small subsection of everything that should be saved. We can see if it works and how it performs, but not be too invested to restart.

Over the next few weeks we'll work at integrating it in more places and running tests to explore what restrictions we might run into. Along with auth, this task will be a big part of 0.6, the content update.