If you're interested in how the mountains and rivers are generated, it's mostly based on the paper "Large Scale Terrain Generation from Tectonic Uplift and
Fluvial Erosion": Each chunk rises (at a noise-based, constant rate) while erosion is applied based on the chunk's slope and the size of its catchment area.
The result is a river network as well as the central height of each chunk; based on this roads, caves and structures are laid out. The actual voxels are only determined when a player loads the area and are (usually) not persisted.
Also, for some technologies not related to worldgen: Rendering is done via wgpu, models are built in MagicaVoxel, and both client and server use an ECS (specs).
Minor note that installation via the launcher (Why a launcher!?!) seems a bit broken. Both the direct mac download, and installing from Cargo, installs Airshipper v0.15.0. This says that it's outdated and to install a new version. Clicking the button to do this takes you to the Github releases page, where the latest version is 0.14. There's a december release for v0.16 but it's a tag only and has no artifacts. Quit in frustration.
Edit: Despite having an issues page, the GitHub page of the launcher is apparently only a mirror of the GitLab repository. GitLab has artifacts for the latest version. I am mystified why they send people to the GitHub page on their officially linked and `cargo install` downloads.
The launcher was there to make it easier to pull the latest build without needing to check if a new version was available. A couple of years back the updates were irregular (sometimes a few days, other more than a week). We regularized the new builds once a week, but, still, the launcher now serves as a way to explore different unofficial or experimental servers that are being available (via registering in the GitLab project).
Most launchers I see aren't necessary for any technical reason. Most don't even bother to enable any functionality at all to the end user's benefit. They're instead used to exert some form of control in a way that's usually palatable enough to not cause a huge PR backlash. As a default stance, being anti-launcher as an end user seems reasonable.
To me launchers are / can be another pattern of dark-ui. Why is a launcher required?
Is the launcher spying on my system, sending information back to HQ?
Can't you tell me the game needs updating when I play the game and then update the game in-game?
Are you going to throw me advertisement banners when you're not making or being greedy?
What if the update fails?
It's one thing I have to wait upon to play the game but launchers come bloated. A carousel of graphics taking a gig of space then requiring an additional 10GB download for the actual game.
Because Veloren's update cadence for most servers is substantially more frequent than most package repositories are willing to handle (trust us, we've tried!). You can install the game without the launcher, but don't expect it to be compatible with most servers.
> Is the launcher spying on my system, sending information back to HQ?
> Can't you tell me the game needs updating when I play the game and then update the game in-game?
That's exactly what the launcher is doing.
> Are you going to throw me advertisement banners when you're not making or being greedy?
Categorically, no. Veloren is open-source (GPL 3), and developed by a close-knit and dedicated community of volunteers. It's a hobby project and will always be free-as-in-liberty as well as free-as-in-beer.
> What if the update fails?
I'm not sure why it would (bar an iffy connection), but the launcher works in offline mode just fine too.
> but launchers come bloated.
Ours doesn't.
> then requiring an additional 10GB download for the actual game
I think we're up at a few hundred MB right now. Most of that is music. It's worth it :)
Yes, just that server and client are very much tied, and we have a release cadence of one new version per week. So, you would need to track the release of each week and compile it, to be able to connect to the official server.
> Is the launcher spying on my system, sending information back to HQ?
The game and the launcher is published by the same people. If they wanted to spy on you, there's no reason not to do that in the game as well.
> Can't you tell me the game needs updating when I play the game and then update the game in-game?
While not impossible, this is way more difficult to do safely and reliably in-game. There's a reason most updaters live outside of the main app process.
> What if the update fails?
Then it's a lot easier to recover from this in a separate, dedicated, minimal app, than as part of the game itself.
Launchers have their place. For example Minecraft needs a launcher: different servers run on different versions (because of heavy customization that doesn't instantly update on a new game release), so being able to select an arbitrary version and launching it is essential. And the snapshot/beta channel works best if you make it easy for people to play the current, stable version, then quickly check out the latest release, then switch back to stable.
Many early-access games do the same via Steam's "beta" feature. If you don't use Steam, you have to replicate the same in a launcher. Or you do it like Adobe and have an entire separate "not a launcher" program to manage which versions are installed.
Verloren currently doesn't seem to actually offer much version management in the launcher, but it seems like a likely future requirement.
It's not clear to me how these are dark. You aren't being tricked, and all of these traits might be in the game client itself as well (game could phone home, auto update, fail to auto update, be slow, etc)
But I expect to play the game, when clicking the game icon. Not being thrown in to a launcher waiting for me while I then thrown advertisements for their next game.
Take a look at EA Origin, it's horrific. It updates then the whole launcher implodes with some alien error code like as one of a printer.
> Can't you tell me the game needs updating when I play the game and then update the game in-game?
Can you explain this a little? Do you have any examples? Unless you're installing a completely new copy of the game, you're not going to be able to play while you update, making this look an awful lot like a launcher. I'm not aware of any games that are hot-updatable.
Q3 was from times without trivially available persistent internet connections. You had to hunt down the patches and mods yourself manually, hoping not to get malware instead. It was a different time. The updates also were much more spread out - last 3 were from 2001, 2002, 2006.
It's just not comparable to how things work today.
I want to like Veloren, I've been following the project for a long time as I like their design goal and the art direction they have, but even after all this time it's the perfect illustration of what you get when you try making a game with just artists and developers and with no game designers: lots of things are very cool but as a video game it just keep missing the mark.
Agreed. I've contributed to the game, so I feel like I have some sort of insight here. Veloren is a bunch of cool features in a bag, but my impression is that there is little focus on the gameplay loop and the holistic player experience. For rather obvious reasons any change that's not achievable by a single person in their free time is also just very hard to get done. Besides, Veloren is popular enough that drastic changes are unlikely to be uncontroversial. I don't blame anyone for this. I guess it's just the nature of open source game development.
Still, I recommend anyone with a bit of time on their hands try it out. There's a couple of hours of decent fun in it. There's a lot to see and explore. The somewhat incoherent design is a bit of a strength at times, since it means the game is not very predictable. Just don't be disappointed when it's not a polished time sink like WoW.
Veloren's mainline client is built on its own engine.
Tiny Glade uses Bevy ECS, but has it's own graphics stack.
Both Bevy and Fyrox are starting to get pretty capable. They're not Godot yet, but they're getting there. Bevy and Fyrox have very different design goals, so there's something for everyone.
Bevy leans hard into ECS and has a ton of utility crates and third party libraries, such as level builders. Fyrox is not so heavily tied to ECS and tries to build everything in as a complete package. Bevy is the more mature engine, but both are viable.
Both can be easily deployed to the web as WASM bundles, so they're ideal for multi platform targeting.
Rust is shaping up to be a major game programming language. And it's already an incredible web backend / RPC / API service programming language, so you can write your game server in Rust too.
The only currently maintained generally available engines used by major studios are Unreal and Unity. Maybe you could count CryEngine, but afaik only one major developer besides Crytek themselves use it. Some indies use Godot, but that's hardly "major studios".
Also, no, the Rust tools are not there. Unreal and Unity both have entire ecosystems around them that are at least as important as the engines themselves. Plus asset stores, support staff, console support, and all manner of other stuff you want when your headcount enters the triple digits. You can download an open source fork of CryEngine (O3DE - complicated story) right now. It's free, and no one uses it, because it lacks the non-code extras.
781 games written with Godot were released on Steam last year. That's 4% of the 18,887 total games released.
The percentage is growing year on year.
As unencumbered engines become more capable, the reason to use commercial engines that extract profit decreases.
AAA studios won't use Godot yet. But eventually it'll be good enough. There are now dozens of open source implementations of some of Unreal's most advanced features, such as Nanite.
Everyone uses Blender now instead of Maya. The same thing will happen with game engines.
Because it has marginal to no benefit over existing c++ stacks, and more important would be economically detrimental because the majority of game developers doing engine coding are c++ developers.
I don't know if that's true or not but from the perspective of someone who's only looking at open source game engines Bevy looks pretty attractive.
It's looks very capable (Tiny Glade looks amazing), the code base is new and modular. The missing stuff that keeps me away right now is a built-in editor/IDE and scripting and/or node system.
So right now Godot is looking more attractive to me.
I'm also keeping an eye on O3DE but that one I think needs better hardware than I have.
I feel like there’s this assumption from Rust enthusiasts that Rust will supersede all other languages and tools. While it’s cool that these things are being done, it’s not enough to show that it will become a major game programming language. Especially due to how mature and sophisticated other tools are in comparison to the Rust tools.
Nope, there's an inner circle of beta testers but it's still effectively vaporware as far as the general public is concerned, even after a decade of development.
You were downvoted but I think youre right. So many games are made in C++, C#, Lua, GML, Haxe, even Swift, Java and Javascript if you include mobile and web games. In terms of raw number of games, Rust isn’t in the top 10 yearly.
Also to note, games industry is very conservative, it took a few decades for those languages to be adopted, and in many cases a push from platform owner was also required.
My comment didn't add much in the way of discussion, so it probably should have been downvoted. But like you said, Rust isn't making a dent so far, and it'll take much more than memory safety to convince the industry to switch to e.g. Bevy rather than the big 2.
Okay I played Veloren for a bit a few years ago and I'm really impressed with the improvement, will need to give it another go.
One serious question I have, is there a reason with voxels we still need to have block based stuff? Like back when voxel tech first started taking off I kind of thought we'd get to the place where like you have so many voxels and we get so good at calcing the physics interactions it would just look like a normal game.
What are the bottlenecks there? Or is this intentionally stylistic still these days?
From looking at some of the bosses I can tell that's getting closer but we're still further than I'd think
The Finals destruction is not prebaked. The reason it works and is consistent is because everything is done server side and communicated to all clients. The game is very CPU heavy for this reason.
I'm kinda there with you. The first game I ever played that used Voxels extensively was Command and Conquer: Tiberian Sun. All the 2nd gen Westwood games of that era used voxels for their units and projectiles, and nothing about the art style was intended to be heavily cubist like Minecraft popularized. Ultimately I think we built around technology that modeled physics differently, both in hardware and software.
There are a lot of voxel games that aren't visually cubey. Marching cubes algorithm is just example. Here's a voxel game (fully deformable/mineable world) that isn't block based https://store.steampowered.com/app/1203620/Enshrouded/.
This is an open source version of another game called Cube World, which was basically a scam when it came out. Had only a few of the promised features and didn’t update for years.
The project started, as you stated, as a clone of Cube World (the name CloneWorld was thrown a few times, did not stick). But it was rapidly decided that the direction we wanted was different. Veloren is a look-similar (and I would argue that not that much) of Cube Wolrd, but it is headed in a completely independent direction.
Default gameplay maybe? But I'm pretty sure there were servers that tried to do whatever Veloren is doing. The diversity of minigames and whole game concepts on Minecraft servers was pretty extreme for a while.
But Cube World wasn't a crafting or mining game; rather, it was an open-world Zelda-like ARPG, with a lot of progression from randomly-generated gear. The voxel size is smaller, and voxels are untextured, resulting in a 3D-ified pixel sprite look.
Couple of tips for getting this to launch (I don't have deep experience here, this is just what worked for me):
- install the Rust package rather than the Flatpak or COPR
- disable fractional scaling if you're using Wayland
- launch airshipper from a terminal rather than the Gnome app grid (and if you've already done the latter check for and kill any orphaned processes - they seem to get stuck sucking up a whole thread)
If I remember correctly it actually is a typo. Someone typed "verloren" wrong and thought it was a good name for the game. The story behind names is often not so glamorous.
I kinda hate many current game names, I prefer this. Otherwise, making a current_year name is easy: noun adjective: noun. How about "Dark Kingdom: Multitude"?
I remember the last time a tried it on the steam deck, less than a year ago through their launcher, it was completely broken and unplayable. I would love to give it another go if this was fixed.
The result is a river network as well as the central height of each chunk; based on this roads, caves and structures are laid out. The actual voxels are only determined when a player loads the area and are (usually) not persisted.
Also, for some technologies not related to worldgen: Rendering is done via wgpu, models are built in MagicaVoxel, and both client and server use an ECS (specs).