Interviewed - Veloren, an upcoming FOSS multiplayer voxel RPG

Today we have something a bit special for you, an interview with one of the team working to produce the free and open source multiplayer voxel RPG named Veloren.

Recently, the Veloren team put out their 0.6 release, bringing a lot of extra content to try out and so we felt this was a good time to have a chat about the project.

GOL: Could you please introduce yourself and the Veloren project!

F: "Hey! My name is Forest, more commonly @AngelOnFira, and I’m one of the developers on Veloren. I’m a university student studying computer science in Ottawa. I joined the project at the beginning of 2019 when Veloren was going through an engine rewrite. I’m the meta team lead, and I focus on topics from continuous integration, to running team meetings, to writing the weekly blog!

Veloren is an open source, open world voxel RPG. It is inspired by other games like Cube World, Dwarf Fortress, and Breath of the Wild. Development was started in mid-2018, and we did an engine rewrite at the start of 2019. We are currently working on version 0.7, so it’s still in the alpha development phase. We have around 20 active developers working on the game, with another 20 artists, writers, designers, and composers contributing as well. We’ve seen around 100 people total contribute to the project."

GOL: Let’s talk code! Your team went with Rust, a language that appears to be picking up a lot of steam. So, why Rust?

F: "In the games industry, C++ has historically been the language of choice. Both it and Rust are robust systems-level languages that perform at near-optimal speeds. However, Rust is much newer than C++. It was released in 2010, and doesn’t have many games written in it. That being said, there is nothing holding us back from doing so ourselves! We have no technical debt in switching to it like game dev companies might since we are writing Veloren’s engine from scratch. There are also many libraries available that help with our graphics and data pipelines. Check out arewegameyet to see how the Rust gamedev ecosystem is doing.

Rust has many features that work quite well for our use case. The key ones are what are known as the “Rust trifecta”: safety, speed, and concurrency. Rust’s safety helps us completely avoid many types of memory bugs that are incredibly tedious to debug and fix. Rust’s speed is comparable to that of C++, and allows us to use any function of the language without worrying about being able to write it better some other way. Rust’s concurrency allows us to make great use of multi-core CPUs without the unpredictable behaviour of “race conditions”; the possibility that threads corrupt shared memory through mutual access. Rust is also highly portable. This allows us to develop how we like, and export to whatever operating system we like quite easily. We currently have automated builds for Linux, Windows, and soon, Mac."

GOL: Why not go with an off-the-shelf game engine?

F: "The big game engines like Unity or Unreal are great for general-purpose games. They’ve been heavily optimized for genres like first-person shooters, or games with meshes that you just import from your modeling software. However, once you want to dictate the rules on how the complex fundamentals of your world are created, you can run into some issues.

Engines have a lot of overhead and provide you with high-level abstractions. It’s as if you’re given Steve from Minecraft to control, but you really want to be controlling Qwop from QWOP. It’s a lot more work, but you have more precision in moving the way you want. Among other things, these engines would have a representation of what an “object” is. In Veloren, we would need each voxel in the world to be represented by this “object”. Internally, we represent voxels with as little data as we can, of which is very specific to our needs since we have that level of control. On the other hand, engines would store a lot more metadata about it, since engines need to work more generally for any type of game. It might include unneeded physics abilities, or the functionality related to meshes other than cubes.

On the other hand, there are other game engines that are more specific, such as the Amethyst engine, which is also written in Rust. It offers lots of modular functionality, where we could pick and choose systems that we like, or use the engine as a whole. However, Amethyst is still being developed, and wasn’t far enough along when Veloren was started.

Our approach to custom engine development has resulted in some unique systems. The land formation is sculpted by an erosion system that simulates over millions of years, and creates realistic features such as downhill rivers. Our procedurally-generated villages already have some simple economic simulation. This comes from attracting developers that are interested in experimenting with ideas that are niche and novel, and have an incredibly flexible engine to work with."

GOL: Veloren is free and open source, do you ever plan to charge for it? We’ve seen other games do something similar to support further development.

F: "Veloren will always stay open source and free. It is a collaborative, community-driven project and we would be nothing without the dedicated volunteers that work to make it what it is. Historically, Veloren’s development has been done by people who worked on it as a side project. This allows people to come, implement what they like, and not feel bad if they leave.

However, we have been exploring the possible benefits of having dedicated contributors working full time on the game. We recently launched an Open Collective account that will help with server infrastructure costs. The next step is to come up with a plan to get some of the contributions to our core developers. There is also the potential for other business models that don’t involve selling the game. Server hosting is a big market in multiplayer games. Depending on how game design goes, it could be a great option to bring in some money for the project."

GOL: What’s it really like to organise development on such a big game? Can’t be easy dealing with multinational developers, plus the community aspect to it.

F: "There are definitely a lot of steps we take to improve development. We’ve learned a lot on the way about what works well for us. There are many ideas that didn’t work as well. I think our Trello board lasted for half a day. We have around 20 active developers per month right now, and so that might dictate why we do or don’t do certain things.

We follow a working group structure to separate development by category. There aren’t strict boundaries between each, developers will often be part of multiple, and discuss topics in any group that they need. Each group does have a lead, who represents someone with domain-specific knowledge in the topic, and is able to help anyone who needs it.

Tasks that need to be completed are managed through Gitlab issues. Bugs are reported there, as well as features that would be nice to have at the current point in development. We can assign issues to particular working groups as well. We tag issues to what version we expect them to be done for. This allows us to have a burndown chart of each version. A burndown chart shows us the number of issues we have left compared to the remaining time. We can more accurately predict when we should start limiting a version’s features with this chart. We also have an RFC (request for comments) system as well, in a Gitlab repository. This is where we discuss larger ideas and systems. Someone documents the original idea, and then it can be refined by people commenting their thoughts on it.

We have contributor meetings at the beginning of each release. Sometimes we have the meetings mid-version as well, but that tends to only be when we have the energy to do so. These meetings act as a way for everyone to see where each team is. It also helps to reinvigorate developers. We host the meetings in voice channels on Discord, and anyone is free to join them. After each meeting, we all hop on the server and give it a little stress test. It’s a great way to catch some bugs, and check in with other working groups on what they’ve been up to.

We find that the best time to host meetings is often around 18:00 GMT on Sundays. Unfortunately, this is quite inaccessible to developers in Asian time zones, however we find that most of our developers are in Europe or North America. Nevertheless, the globalization of project development has great benefits. We have a great team of translators, who have already worked hard to translate Veloren into several different languages. We also see models and music that is inspired by the locality of our developers."

GOL: What would you say has (so far) been the most challenging part of getting involved in making a game?

F: "There are many obstacles we’ve had to overcome. We’ve gotten discouraged many times, but luckily we have a solid net of developers to fall back to when we run into a problem. It’s difficult for new developers to get started on the project. Also, feedback on different social media can be disheartening.

For those wanting to start contributing, there is a significant learning curve. Many people join the project and want to contribute since they’re inspired by what we’re working on. However, they might not have used Rust before, or they feel like they can’t find the help they need to get started. We try to mitigate these issues as much as possible. Rust has a super great ecosystem for learning, primarily with the Rust book. We have learning and questions channels on our Discord, and are quite active in them.

When posting on social media about Veloren, we often get quite the spectrum of comments. It’s good to hear criticism about the game, or ways to improve, but there are people who choose to leave more toxic comments. Sometimes we try to discuss the issue presented if we think it’s a misconception. Other times it’s easier to let it be. However, these comments are often outweighed by the positive ones."

GOL: I imagine that building a game in the open, one that enables many people to meet up together in an open-world can be quite rewarding. What has been the most memorable/rewarding part for you so far?

F: "Each person who contributes to the game uses their unique skills to add something meaningful that they worked hard on. They found a hole that they could fill, and did so. However, it’s really easy for their efforts to go unnoticed. For me, showing off their work is the most rewarding part of this project. I do this by writing the blog every week, in which I try to push the developers to write about what they’ve been working on. This gives them a way to show off their work, but also reflect on it themselves.

As an open source game, we’re a side project for most of our developers. Because of this, we can all explore what is most rewarding for each of us. From this, I hope that Veloren can bring more interest and excitement to future development in Rust for other games!"

GOL: If someone wanted to get involved in open source, game development or something like managing it all - where would they begin? What advice do you have to kick-start them?

F: "There are a lot of different types of jobs within open source projects. Lots of the time, it will require your own initiative to find your place. Sometimes projects have issues that are designed for beginners. Other times, you might find an issue in a project that you want to fix yourself. Either way, it’s still intimidating to know where to start. I think there are some steps that can be taken to remedy this.

For projects that you want to start contributing to, the first step is to know the language the project is written in. You don’t have to be an expert, and you can always ask for help, but you should know where to go when you run into problems. Second, you should read the project’s documentation. Finally, dive into the codebase. Familiarizing yourself with the structure will allow you to more easily know where to put your code.

For projects on the other hand, there are steps they can take to decrease the learning curve for new contributors. Primarily, having channels for people to reach out and discuss the project with the developers. As I mentioned above, it’s important to have curated issues for beginners. These issues document what needs to be done, as well as who to contact for help. It’s also important to select a license suitable for your project to protect the work of contributors. Permissive licenses are great for libraries, but end products that wish to cultivate a strong and dedicated community should consider a copyleft license that gives due credit to contributors and keeps their work safe.

With Veloren, we try to improve as many of these points as possible. In our Discord server, we have a learning channel where people can ask questions about Rust, among other topics. The Rust language is known for the positive community behind it, and we want to add to that as much as we can. We also work to modularize Veloren where possible. This makes the codebase easier to read, and also easier to know who to contact about any part. We curate beginner issues as we go, and support those who want to work on them. We try to leave easier tasks undone so that a new contributor can work on it instead."

GOL: Your ultimate goal for Veloren?

F: "For each of us, it’s different. The project was originally started by people who wanted to make an experience that would fill the void created by Cube World. However, since then, many people have joined who had never played Cube World before. The project founder, @zesterer, wants to create a dynamic world where settlements and cities interact economically and politically. @Songtronix’s goal is to improve the user's experience with Veloren, primarily by working on our launcher, Airshipper. @Pfau, wants to create a vivid world from the art of our many artists. @Slipped wants to create a captivating animation system. @Timo wants to create a dynamic experience that friends can have. @Sharp is using real-world natural processes to simulate our world generation system. With everything that inspires each one of us, I think we can create the game we are hoping for."

GOL: Any last words to share?

F: "Thanks for reading all the way to here! If you want to read more, you should check out our weekly blog. I also want to mention that although I wrote most of this interview, it had ideas, was proof-read, and was commented on by lots of other people on the Veloren team. This includes @Songtronix, @Slipped, @Vechro, @zesterer, @Yurimomo, @Timo, @Acrimon, and likely others that I’m forgetting.

It’s very exciting to talk about what’s going on with Veloren, but we have to remember that it is an incomplete game. We’ll do our best to make it everything it can be, but for now it should be regarded as a fancy tech demo. If you want to see where the progress is, you’re more than welcome to download it and give it a try! If you’d rather wait for the final product, that’s definitely a safe call. We want to do our best to avoid a “hype-train” around Veloren. Either way, I hope to see you on the server sometime!"

Our thanks to Forest for reaching out about the interview, and for everyone else working on Veloren that joined in as it all sounds very exciting for the future of this free and open source game.

Want to check out Veloren? See it on the official site.

Interested in having a chat with us here at GOL about your game? Reach out to us any time.