This Week In Veloren 11

We saw a large influx of users on the Veloren Discord this week! We also take a look at the current 0.2 milestone, and what's required to reach it. We also introduce the Veloren Coding Challenge and take a look at the newly found networking issues. This week's blog was edited by @AngelOnFira, with the art section curated by @Pfau!

Programming

Newcomers :)

This week, we're seeing lots of new potential contributors joining the Discord. This was from a post on /r/rust that can be seen here. It's always great to see new contributors, and they motivate the whole team to push further.

Weekly code challenge

Often in the Discord, there are many people who want to get involved with Veloren but feel that their Rust competence is not good enough. We want to make this an issue of the past!

A solution that we want to try is a weekly Rust code challenge. The challenge will be one that is designed to teach important concepts of Rust but remain accessible to Rust newcomers. We hope that discussion around the weekly challenges will spark excitement in the community around Rust. It would be great to see a lot more people feel more comfortable around the codebase.

If you want to give it a try, check out the challenge here. The challenges are currently being made by @AngelOnFira, with writing help from @Kidsnextdorks.

Asset storage

An issue that was addressed this week was how to store assets. Before the discussion, there were over 200 PNG files in the GitLab repo. The problem with this is that anyone who wants to work on the project must download these files, even if they are removed.

The structure that Git uses doesn't actually keep track of all of the files that are current. Instead, every time you need to update the current files (by switching branches or downloading the repo), Git constructs the current files based on all of the previous commits. And since the PNG files were in the repo at some point in history, they are required to construct the repo.

There are a few different options to this. For most game development, Git Large File Storage is used. The problem is that the data needs to be hosted somewhere. We don't want to rely on a contributor to host it, as it would incur costs for them, and if they leave in the future then the problem would have to be assessed again. A few other ideas were thrown around, including Google Drive and Dropbox. But these all have their issues. As @zesterer put it;

1. How do we ensure that all developers have access to the asset storage?
2. How do we effectively integrate it with the existing build system?
3. How do we ensure it's always up, throughout the entire lifetime of the project, even if members move elsewhere?

A solution to this problem hasn't been found yet. One of the potential solutions being examined right now is Git subtree. More to come on this topic next week.

Some website changes

With the amount of other content starting to form around Veloren, there have been talks of changing parts of the veloren.net site. @Wulkan has spent some time this week adding a new navbar to the site (veloren.net). They have also expressed interest in changing the static site builder, in the hopes that it can start to become a homepage site rather than just a blog site.

There has been more work done on the book as well, as well as automated documentation. Be sure to check it out!

Networked physics

As has been the case in the last few weeks, networking is still a big topic. @xMAC94X, @LunarEclipse, and @YuriMomo have all been providing support in different channels to make sure that bugs are being fixed.

A bigger networking problem lies in the current method of sending world data over the network. Here is an excerpt from @zesterer on the topic.

Ok, so I've been thinking about how we synchronize chunks between clients and the server. And I've realized that it's not a trivial problem, unfortunately. So there are two main models I think are useful to think about when doing this. "push" updates and "pull" updates. With the first, the server would automatically send new chunks or updated chunks to clients as and when they appear. With the second, the client must first request a chunk for it to be sent back. Now, this is all well and good, but it gets more complex when including things like view distances. How do you figure out whether to generate a chunk? Well... perhaps you iterate through all chunks that are within range of all clients, and then figure out which ones are generated and which aren't... then generate the ones that aren't. But that's a lot of chunks to be iterating through every tick (or every few ticks). Let's say the player has a view distance of 1000 (i.e: large, but not totally insane). With a chunk width of 32 and a world height of, say, 16 chunks, that's like... Uh. I hope I just got this wrong. Volume of a sphere is PI (r ^ 3) 4 / 3. The radius in chunks is 1000 / 32 = ~32. So that's PI (32 ^ 3) 4 / 3 = ~140,258 chunks. Is that really right?. Because... God help us if it is. I guess it's smaller for a world height of 16 chunks only. But still... not smaller by much. And we'd have to iterate through that every tick for all players.

Basically, what the problem boils down to is how to send as little information over the network as possible while still representing the game world properly. Some of the ideas being thrown around to try to include some AI solutions, and other ways of representing color data.

In other networking news, there was an issue brought up where the client and server weren't communicating properly. You can check out the issue on GitLab here.

Bigger push on GitLab issues with milestones

With all of the new people joining the Discord server, it has become apparent that certain work has to be made. Better instructions on how to get up and running, more clear communication from the leads, and tasks distribution that can lead towards the greater goal. GitLab issues is a solution to this.

You can see the current 0.2 milestone here. If you go into the milestone (here), you will see the issues that need to be completed for the milestone to finish. Now, that said, this is not to say that we are super close to finishing 0.2 because there are only X issues left. Issues are added as big tasks break down into smaller tasks, and as previously unknown problems come up.

Also, the core dev team is going to start making use of the "beginner" tag on GitLab issues. These issues are designed for new contributors to get up and running with the engine. If you are hoping to get involved in contributing, start taking a look at these issues!

Art