This Week In Veloren 51

This week, we take a look at some of the finishing touches to 0.5. Lots of progress has been made on quality of life changes, such as translations and visual flares. We hear from @Sharp about map migrations, and from @AngelOnFira about their talk at CUSEC.

- AngelOnFira, TWiV Editor

Contributor Work

Thanks to this week's contributors, @imbris, @Pfau, @Timo, @Acrimon, @JosephG, @Zesterer, @Sharp, @Songtronix, @Payload1, and @Shandley!

@LunarEclipse has gotten controllers to partly work. In-game works, but no menu support, and key binding still has to be set up. @Pfau worked on some nice visual flairs, like colored frames for activated skills, and darkened skills when they are charging. He also worked on scaling character creation to your window size. @Sharp has been working on the map that will be released with 0.5.

@Ender has been working on a localization system. This will allow translations of the game to be easily created. Both English and French translations are nearly done, with the ladder at 75% complete.

0.5 Map by @Sharp

I'm almost done creating the versioned infrastructure for maps. This will allow us to load old maps with when the format changes. The basic idea is that we "chain" migrations of old map types. So each map type just has to know how to convert into the next version, and it will follow the chain until we hit the latest version of the map. The world file format is defined as an enum with a variant index that we set explicitly (this is an available feature on Rust nightly). That way, we can extend their backwards compatibly while still using bincode.

I also support the "legacy" map types that don't have this field, but you have to explicitly know you're loading a legacy one. For every other map created after this change, that shouldn't be necessary. This still doesn't cover invalidating old maps when the code changes, but it at least makes sure people won't be left unable to use their world files. At least, not if they make them on major releases; I don't guarantee backwards compatibility for random changes between releases.

It shouldn't increase the binary size much unless we start to gather a truly absurd number of versions. Postgres supports compatible migrations for something like 5-10 years and it doesn't cause any problems. And if people really want to migrate old maps that have been removed from the binary, they can always grab an older version of Veloren and perform the process manually. This entails migrating up to the latest supported version was that also knew how to read their old file, then jump to the latest version of Veloren that knew how to read that file.

So I don't really see much of an issue either way. That's the nice thing about chaining and supporting migrations from the get-go rather than adding it after there are already several incompatible map types, or using a file format that doesn't know its own version.

CUSEC 2020 Talk by @AngelOnFira

Hey everyone! Last weekend, I gave a talk at CUSEC (Canadian University Software Engineering Conference) in Montreal. The title was "Cultivating a Healthy Open Source Community". I spoke about lots of interesting ideas that I learned from working on Veloren, both from a management and development view.

You can check out the slides here. In the future, I might get the recording of the talk as well. I reached out to some developers to get other ideas to add to the presentation, but I also feel that all of the contributors who added to Veloren were an inspiration for the talk as well. Thank you all <3