This Week In Veloren 72

This week, we have work from new contributors. We hear from @zesterer about test economic simulations. @xMAC94x has been working on merging networking, and wrote about the process.

- AngelOnFira, TWiV Editor

Contributor Work

Thanks to this week's contributors, @imbris, @Pfau, @WelshPixie, @scottc, @xMAC94x, @Shandley, @AngelOnFira, @xvar, @Songtronix, @Slipped, @yusdacra, and @JamesTai!

@Acrimon has been rewriting the authentication server. He is transitioning from a microframework and tiny_http to warp and hyper which is more robust and gets rid of the currently possible slow loris attack by being async. @Songtronix has merged most of the changes to the book. There are still sections that need to be worked on, but it now has a lot more information. @lobster has been working on improvements to combat. This includes energy regen resetting properly, and ability usage.

@Slipped has been hard at work this week. He added a secondary bow attack and made arrows visible when holding the bow. @Slipped also worked on completing the glidewield branch with @imbris for carrying the glider around on the ground. @Slipped, @Snowram, and @Gemu work on quadruped overhaul branch. @AVeryLostNomad is continuing work on an indoor camera mode.

There have been lots of new contributors joining recently. @WelshPixie has been working on lots of new flora. @mainCharacter is working on proofreading some of the writing with the lore blogs. @RENCURELI is going to be working on a document proposal for level design. It will also include some ideas for world generation guidelines.

Economic Research by @zesterer

Recently, I've been doing a heap of research: Marginalism, the Lange–Lerner model, and various other models for centrally-planned economies. I've attempted to implement aspects of Lange–Lerner into Veloren's economic simulation. I think I've got site economies converging on Pareto-efficient production configurations now so that's nice.

Below is a graph of the rationalised values (roughly analogous to internal economy prices) of various commodities over the 500-year lifetime of a site. A site in this case is an arbitrary village or city type of object. Note that the natural environment and worker productivity is remarkably stable, hence the manner in which value rationalisation converge toward stable values. Also, the value is in arbitrary units (i.e: it's not "per Kg" or something like that) so comparing values isn't really worthwhile right now.

Next, we have a graph of the same site, this time the stocks are maintained by the site of each commodity. In practice, the stock of a commodity is roughly proportional to the demand for that commodity (in arbitrary units) over the course of a year.

Since the Lange-Lerner model involves deriving commodity values by trial-and-error, you can see that the initial values are necessarily arbitrary and so the site goes through a period of economic instability before converging on values that are Pareto-efficient (in a market economy, this would be the market equilibrium).

And, for that same site, below is the workforce allocation for each occupation. The units now are not arbitrary and actually correspond to a number of individuals (fractional values are taken to mean that an individual only performs the given labour for a fraction of the year).

Note that all of these graphs are relatively meaningless right now since I've not set up industries and natural resources correctly yet. I'm basically just using them to ensure that the economy reaches Pareto-efficiency rather than misallocating resources and spiralling off into producing far more wheat than could ever be turned into consumable food (as was an issue I had before).

Interestingly, the economy seems to go through cyclical periods of economic instability. This is expected since it's a chaotic system. You might say that these are analogous to boom-bust cycles that we experience under modern capitalism, although in this case value rationalisation goes through a damping process that should get rid of most of that.

I just added some random seasonal variation for the supply of natural resources and as you can see the respective commodity values fluctuate accordingly to compensate for this (including for goods that are derived from natural resources).

Networking Work by @xMAC94x

The new veloren_network crate was merged into the main source code by @xMAC94x this week. The merge wasn't as easy as it sounds, as there were some still errors in documentation, metrics delivery, and the implementation. Luckily these were found by @imbris and @Songtronix. Additionally, I noticed some timing behavior that occurred on PC's with less than 8 cores. It appeared in CI and was hard to track down. The code has been merged for a week now, and running tests in the background without any problems. The next step towards new networking is to actually start using it in the Veloren codebase and see how it works out.

MacOS Linking Error by @xMAC94x

Recently I found a toolchain blocker that prevented building for MacOS. Usually we update our rust-toolchain once a month. Last time we tried, we ran into some errors in the MacOS pipeline as there was a linkage error. After writing a Rust bug report it seems to be finally someone who wants to fix it, so that we can upgrade again 😄

Compilation Improvements by @xMAC94x

Following the CI improvements from last week, this week now had a series of compilation improvements. This was mainly done by removing multiple versions of the same crate, removing unused features, or switching over to other crates which are more low level and suit our task better. As an example; until now we shipped a full-blown web-server AND web-client with veloren-voxygen. We used a web-server, build for handling hundreds of simultaneous connections to serve our metrics to a single consumer! We replaced rouille by tiny_http as our server. Also, we use a full blown web-client which was build complex tasks to make a few calls to the auth service. We replaced reqwest by ureq as our client.

The result was a reduction in 40 sec in compile time, 12% in total CPU time (across all cores) and 2 GB of cache for each runner: