I played a bit into this game (maybe about 20 hours), and it's good. The size of the map dominates the game-play as you aim to explore all the types of destinations. It's a procedurally generated world, and some hilly towns will get a little weird. The glider is really a killer features, because the mountains are really really steep, you climb up to the top and the glide to cover a fairly large distance on the map.
It was still hard to get into the social element of the game, because of so few players and such a large map. I think other players tended to be concentrated at the main spawn point, so a lot of the rest of the world was a backwater essentially.
They also have a giant tree. It will cost you some hours, but it's quite different than anything else you'll find.
> It was still hard to get into the social element of the game, because of so few players and such a large map. I think other players tended to be concentrated at the main spawn point, so a lot of the rest of the world was a backwater essentially.
I'm a little curious, is there a technical reason why voxel games are easier to build than non-voxel ones? The docs mention that all of the assets are community-contributed. Does making them voxel-based just drastically lower the skill theshold to make a contribution, vs. smoother ones in something like Blender? I guess I'm a little curious about the relative amounts of effort that would have been required to make this kind of game (procedurally-generated open world, I believe) using non-voxel assets and mechanics, since the existing set seems to be pretty fully-featured.
Great question! Core developer here, and I haven't thought about this too much.
I think one benefit this gives us is on the artist contribution side. Being an art contributor on the project has a lot less overhead of being a formal "artist", since you can quite easily make fauna or creatures or just concept art. We've seen lots of this in our blog posts!
But also, in terms of terrain itself, I think it allows us to really crank up how wild and wacky our procedural generation is, and still have a great looking world (unlike something higher-fidelity like No Man's Sky). We do a lot of cool things under the hood; we have a full erosion system that creates the mountains out of the sea, a site system that places villages in places that make sense, and the ability to mash together shapes that then get "rasterized" into voxel houses. I don't know how much of this would be possible and still look alright if we weren't taking a voxel approach.
If I put a 5 year old in front of a polygon based 3D modelling program they will have no idea what to do, and even if I teach them the tools they will have trouble. If I put a 5 year old in front of Minecraft they will eventually figure out how to build stuff. I hope this answers your question.
I've always imagined that voxels are the pixel art of the 3D world. Much easier to create from both an aesthetic and development point of view. Hard discrete edges that fall along the XYZ planes are much easier to program for (think collision detection etc).
It's easier to be consistent when everyone is on voxels. If you give all of the artists full freedom then it's a lot of work to make things match in one game.
On a non-voxel game it'd be very obvious that there were a bunch of different artists involved who were working somewhat independently.
As someone who has lead polygon games and voxel games, let me say if you are looking for community contributions, voxels are way to go. Decent looking poly assets need professionals, and professionals are expensive.
There's a benefit to direct manipulation of pixels/voxels within the game.
Imagine, if you would: build a 64x64 "flat" foundation of stone. Clicky-clicky-pokey-pokey to place/remove colored blocks. Post something somewhere to someone: "Hey, I have some fresh voxels for someone to do something with!" => scrape-world.php => asset.vxl => etc...
Basically, games with a built-in level-editor tend to be easier to contribute to. Minimally: the potential "editors" are already familiar with 90% of controls, viewpoints, and can see the asset "in-game" already (and they're probably already "in the game / editor" already, no context-switching to blender or autocad or something).
I'm 1000% sure that if minecraft added some sort of symmetry + polygon + joint/bone/connection-point tooling, you'd see an explosion of polygon assets available within the community.
The technical reason that voxel games are "easier to build" is that you can easily make a 1000x1000x1000 array of integers/chars, and get a 50-"voxel" radius from somewhere and start rendering it with raycasting. Can you render a square? Can you render 100 squares? Boom => voxel engine. Can you get/set a 3d-pixel (voxel)? Can you click "destroy/create" on a raycast target? Boom => voxel editor.
Its easier to generate destructible worlds using voxels than chunking meshes in some other way. It brings on some other challenges and benefits as well.
Guessing here, but perhaps the computational complexity for rendering voxel assets is much more bounded, e.g. you can't make something with a super dense vertex count and complex shaders and other transforms and bog the game engine down.
I feel like some of the "inspired by cubeworld" stuff is a little too heavily inspired, but I really enjoyed taking a quick look at the source and logging in to check things out.
Things seemed pretty clean, and because everything has source posted I was able to mess around with the apis, and try a few things against your services :) (hope I didn't set off any alarms lol). That said, what I'm assuming is Sha256 could always be a bit tighter, consider a strength upgrade on those credentials.
There's a bit of snobbery going on here for go / voxel hate, but I really enjoyed digging into a completely open source setup for something that is already a nice intro of game, services, and execution, well done :)
We currently have an MR where we're overhauling some of the auth, and I know in the future we do want to explore what else we could add/improve for our backends :)
This is great. My kids are very much into minecraft. I am very much into rust.
I would love to help them make the step from playing games to hacking on games. This was very simple back when I was a kid, but is quite hard now. The games you can make are so much less impressive than the games they are used to.
I was also very attracted to this game, but then I found out it's really an RPG and there is no (real) building of any kind. I don't really know anyone who wants to play a procedural generated blocky-RPG they can't modify the environment of :/
See? This is why today's kids making me jealous. Back when I was just a ~10 years old, I couldn't even found a game that worth playing (through I'm picky) and also supports modding, let alone a full open-sourced game written in a programming language that I'm interested in.
Imagine I started learning Rust at 10 years old...
I do! We actually have an episode coming out tomorrow! (today? edit: it's already out!)
I'm really happy that I could get more integrated with the Rust Gamedev "Working Group", since I've been able to chat with so many cool people through the podcast, and host a monthly meetup to see what people have been working on. It's a great community!
Another great Rust gamedev link if you want to see how the ecosystem is doing: https://arewegameyet.com
This game is quite a fun time, even if it is only a short time. I got a bunch of my mates together, and the four of us worked through the main progression. There was a great loop of venturing out to a dungeon or cave, taking on challenges greater than we could handle, managing to scrounge some expensive loot or rare gear, before returning to a village to trade with NPCs. At the time there was also a bug where a very common flower would sell for very high prices, allowing us to get a lot of gold. We could trade this for valuable health potions that help greatly in difficult dungeons.
We got a couple of nights together out of the game. However, unfortunately the game is rather short, and after we had conquered a level 6 dungeon, and obtained the best gear, there was little left to do. Development is still ongoing, and it is exciting to read the devlogs every now and then to check on the progress however. And maybe once there is enough extra content we’ll jump back in for another session.
The world generation in the game is absolutely breathtaking. Might even go as far as saying it rivals that of the new Minecraft 1.18 World generation update, at least with the mountains. And I really love the music in the game, it fits really well with the whimsical aesthetic of the game, and I get it stuck in my head every now and again, even though I haven’t heard it in months.
The game had its fair share of jank as well, as is to be expected with a (pre-alpha?) early version of the game. The movement took a while to get used to, and it felt a bit floaty at times, and didn’t always feel like I was fully in control. As well the camera was really close to the ground, which was a lot to get used to, as I am used to the taller perspective of Minecraft. However, the game does a great job of allowing the player to switch between first and third person, merely by scrolling the mouse wheel. (You can take the camera really far out too to get great cinematic screenshots, of which I have a collection)
The combat felt a bit off at times as well, as the cooldown between attacks, and the speed of the attackers often matching that of the player felt like you couldn’t escape once an enemy locked on. Luckily the middle button roll could usually get you out of attack range, but it felt like this could be improved (and I think it may have been improved since).
At the time I was playing, the trading system was also really confusing, but I believe it has been changed since.
All in all, it is well worth checking out the game. Make sure you play the nightly. Best enjoyed with a group of mates, but it is also fun just exploring by yourself. I can’t wait to see what cool stuff is still to come with this game.
I would expect the game to be short if you abuse a bug to get massive amounts of gold and skip through the progression way faster than you're meant to.
Of all of our inspirations, Cube World is certainly what brought us together to start the project. We originated from a Reddit post on the Cube World subreddit that asked "why not just make an open source game out of what we liked?"
Of course, since that was in mid 2018, many of the devs that have joined the project haven't played Cube World, and are inspired by other games or mechanics they enjoy. We list our inspirations as Cube World, BotW, and Dwarf Fortress as our primary ones. As is mentioned in other comments here, Minecraft is also part of this lineage, however, we aren't going down the path of buildable blocks very much.
Since the early days of Veloren, we've defintely worked to break away from "just a clone", into gameplay that is more derivative of what we can achive with our engine, but there is still a lot of work to go before we consider it "released" :)
I got myself up into the Giant Tree and spent three nights. The colors and effects are wonderful. I could zoom way out to the neighboring mountains and pan around to see the whole landscape, then back in to see the crazy creatures on top of the tree.
I put on my glider and jumped out of the tree and realized I didn't know how to fly yet and splat!!
Even though it's multiplayer and has quests and lots of activities, I had a great time just exploring around by myself. Thanks for a fun game!
This looks awesome and I installed it via Flatpak in my Linux Mint 20.3 to try it out. But the launcher keeps crashing without showing errors. All I see is a window frame with no content inside (it's transparent) and then it crashes.
I downloaded this game to see how well a game written in Rust performs.
I very much appreciate the stability and performance Rust brings. I believe software written in Rust is much more long-lived that similar C/C++ software since memory issues are almost certain to occur with the latter.
Not to mention the security benefits Rust brings to the table.
I don't really care for the game itself. I'm much more a BZFlag player anyway.
The project is using wgpu-rs (and has actually contributed quite a bit to it). Can highly recommend it for other projects, it really is the way to go if you want to be portable but don't want to sacrifice a ton of performance (as using OpenGL does nowadays). Using wgpu generally means you're getting a fast subset of most of the modern APIs, at the cost of some control and performance in certain cases (though not too much performance--we'd like to shrink that even further), so for us it's the way to go.
The other two choices people usually bring up are OpenGL and Vulkan. The project was originally using OpenGL and was quite limited as a result; theoretically, you can do better by abandoning portable versions of OpenGL, but many modern OpenGL drivers are incredibly poor (particularly on Windows), and a lot of machines support, e.g., DirectX 11 or Metal but not a version of OpenGL with the same feature set. Going with straight Vulkan means you're either going through a (slow) translation layer on many older machines (and Macs), or giving up on them entirely. Vulkan is also incredibly hard to use correctly if you're using it directly and want to be portable across GPUs; the spec has a lot of edge cases that are quite unclear even to experts, and often requires consulting with driver developers to figure out exactly how they were interpreted (to be fair, this has become less of a problem over time, but it's still an issue for corner cases in the spec).
Rust is not made for game dev, this project is the proof, your progress will stall at some point because you won't be able to iterate on your game anymore!
That's the curse of Rust
Where are the gamedev that announced using Rust from now on 5 years ago? they still stuck compiling their projects!
Veloren's compile time is bad, but this is hyperbolic nonsense. To address your points in order:
* Compilation is a ton faster on an M1 and with a non-default linker. Compilation from scratch (including all dependencies) took around 10 minutes for me last time I tried; compilation of the main game is much faster (I think in the ~ 1 minute range, which is more than acceptable if you're not doing something sensitive like animation work.). Obviously, not everyone has an M1, but it's hardly a dealbreaker if you've got a machine designed for development.
* The developer in your video is changing a line in veloren-common, a "root" crate that leads to a bunch of other stuff recompiling. The vast majority of changes are in leaf crates, which compile much faster. For animations, in particular (which require quick feedback) we have a separate compilation unit that compiles on the order of seconds and can be configured to be dynamically linked to the main game, so they can get pretty much instant feedback. For as many kinds of assets and data as possible, we also push it out to configuration files with hot reloading, so most people working on models, item and color tweaks, etc. don't have to wait for compilation at all and can just save their files.
* Many games written in C++ also take ages to compile. Rust isn't unique in that regard. Clearly, it hasn't stopped Veloren's development (I can't think of anyone who quit development because of the compile times, though there's a lot of grumbling). In fact, I'd venture to say that Veloren has had some of the most developers and fastest development of any 3D open source game I'm aware of, regardless of language.
* No major developer I'm aware of announced using Rust for games 5 years ago. What are you talking about? If you mean the Chucklefish title, that had nothing to do with compile times. As far as I know, the game companies using Rust right now are mostly using it for tooling.
* The file you linked is the equivalent of yarn.lock, Cargo.toml is the actual dependency file. Dependencies do not need to be recompiled each time you compile Veloren, only the first time. Additionally, most dependencies compile pretty quickly and parallelize well. There are a handful of dependencies (the procedural macro ones in particular) that take a huge percentage of the overall compile time and/or act as bottlenecks, which is tolerated because they are extremely useful.
Veloren could optimize more aggressively for compile time, if the project was so inclined. A lot of that compile time is spent on generated code from macros like serde. Veloren also deliberately tends to use very large crates rather than trying to split everything into very small compilation units (some of them have been split up to improve compile times, but not too much). The project's perspective is that benefits of using those libraries (which greatly simplify development) and having fewer crates (which makes it much easier to avoid exposing internal APIs to get anything done) far outweigh the compile time costs, but not every project takes that approach and there are a lot of games that compile much faster than Veloren. It's really not a fundamental limitation of the language.
[+] [-] AlanSE|4 years ago|reply
It was still hard to get into the social element of the game, because of so few players and such a large map. I think other players tended to be concentrated at the main spawn point, so a lot of the rest of the world was a backwater essentially.
They also have a giant tree. It will cost you some hours, but it's quite different than anything else you'll find.
[+] [-] TulliusCicero|4 years ago|reply
Ah, so it's an MMO then?
[+] [-] NikolaNovak|4 years ago|reply
I miss that mechanic so much I'll try any game to get my kick
[+] [-] Wowfunhappy|4 years ago|reply
[+] [-] qchris|4 years ago|reply
[+] [-] AngelOnFira|4 years ago|reply
I think one benefit this gives us is on the artist contribution side. Being an art contributor on the project has a lot less overhead of being a formal "artist", since you can quite easily make fauna or creatures or just concept art. We've seen lots of this in our blog posts!
But also, in terms of terrain itself, I think it allows us to really crank up how wild and wacky our procedural generation is, and still have a great looking world (unlike something higher-fidelity like No Man's Sky). We do a lot of cool things under the hood; we have a full erosion system that creates the mountains out of the sea, a site system that places villages in places that make sense, and the ability to mash together shapes that then get "rasterized" into voxel houses. I don't know how much of this would be possible and still look alright if we weren't taking a voxel approach.
[+] [-] aufhebung|4 years ago|reply
[+] [-] Computeiful|4 years ago|reply
[+] [-] wmil|4 years ago|reply
On a non-voxel game it'd be very obvious that there were a bunch of different artists involved who were working somewhat independently.
[+] [-] BatFastard|4 years ago|reply
[+] [-] ramses0|4 years ago|reply
Imagine, if you would: build a 64x64 "flat" foundation of stone. Clicky-clicky-pokey-pokey to place/remove colored blocks. Post something somewhere to someone: "Hey, I have some fresh voxels for someone to do something with!" => scrape-world.php => asset.vxl => etc...
Basically, games with a built-in level-editor tend to be easier to contribute to. Minimally: the potential "editors" are already familiar with 90% of controls, viewpoints, and can see the asset "in-game" already (and they're probably already "in the game / editor" already, no context-switching to blender or autocad or something).
I'm 1000% sure that if minecraft added some sort of symmetry + polygon + joint/bone/connection-point tooling, you'd see an explosion of polygon assets available within the community.
The technical reason that voxel games are "easier to build" is that you can easily make a 1000x1000x1000 array of integers/chars, and get a 50-"voxel" radius from somewhere and start rendering it with raycasting. Can you render a square? Can you render 100 squares? Boom => voxel engine. Can you get/set a 3d-pixel (voxel)? Can you click "destroy/create" on a raycast target? Boom => voxel editor.
[+] [-] whatshisface|4 years ago|reply
[+] [-] jayd16|4 years ago|reply
[+] [-] aliswe|4 years ago|reply
[+] [-] colordrops|4 years ago|reply
[+] [-] daguava|4 years ago|reply
Things seemed pretty clean, and because everything has source posted I was able to mess around with the apis, and try a few things against your services :) (hope I didn't set off any alarms lol). That said, what I'm assuming is Sha256 could always be a bit tighter, consider a strength upgrade on those credentials.
There's a bit of snobbery going on here for go / voxel hate, but I really enjoyed digging into a completely open source setup for something that is already a nice intro of game, services, and execution, well done :)
[+] [-] AngelOnFira|4 years ago|reply
We currently have an MR where we're overhauling some of the auth, and I know in the future we do want to explore what else we could add/improve for our backends :)
[+] [-] Jweb_Guru|4 years ago|reply
[+] [-] KyleBerezin|4 years ago|reply
[+] [-] rklaehn|4 years ago|reply
I would love to help them make the step from playing games to hacking on games. This was very simple back when I was a kid, but is quite hard now. The games you can make are so much less impressive than the games they are used to.
[+] [-] skerit|4 years ago|reply
[+] [-] nirui|4 years ago|reply
Imagine I started learning Rust at 10 years old...
[+] [-] dncornholio|4 years ago|reply
[+] [-] Rendello|4 years ago|reply
https://rustgamedev.com/
[+] [-] AngelOnFira|4 years ago|reply
I'm really happy that I could get more integrated with the Rust Gamedev "Working Group", since I've been able to chat with so many cool people through the podcast, and host a monthly meetup to see what people have been working on. It's a great community!
Another great Rust gamedev link if you want to see how the ecosystem is doing: https://arewegameyet.com
[+] [-] orangetuba|4 years ago|reply
[+] [-] brunt|4 years ago|reply
[+] [-] moxvallix|4 years ago|reply
We got a couple of nights together out of the game. However, unfortunately the game is rather short, and after we had conquered a level 6 dungeon, and obtained the best gear, there was little left to do. Development is still ongoing, and it is exciting to read the devlogs every now and then to check on the progress however. And maybe once there is enough extra content we’ll jump back in for another session.
The world generation in the game is absolutely breathtaking. Might even go as far as saying it rivals that of the new Minecraft 1.18 World generation update, at least with the mountains. And I really love the music in the game, it fits really well with the whimsical aesthetic of the game, and I get it stuck in my head every now and again, even though I haven’t heard it in months.
The game had its fair share of jank as well, as is to be expected with a (pre-alpha?) early version of the game. The movement took a while to get used to, and it felt a bit floaty at times, and didn’t always feel like I was fully in control. As well the camera was really close to the ground, which was a lot to get used to, as I am used to the taller perspective of Minecraft. However, the game does a great job of allowing the player to switch between first and third person, merely by scrolling the mouse wheel. (You can take the camera really far out too to get great cinematic screenshots, of which I have a collection)
The combat felt a bit off at times as well, as the cooldown between attacks, and the speed of the attackers often matching that of the player felt like you couldn’t escape once an enemy locked on. Luckily the middle button roll could usually get you out of attack range, but it felt like this could be improved (and I think it may have been improved since).
At the time I was playing, the trading system was also really confusing, but I believe it has been changed since.
All in all, it is well worth checking out the game. Make sure you play the nightly. Best enjoyed with a group of mates, but it is also fun just exploring by yourself. I can’t wait to see what cool stuff is still to come with this game.
Edit: added section about janky combat.
[+] [-] CursedUrn|4 years ago|reply
[+] [-] fbrchps|4 years ago|reply
Well I'm glad to see this so early on, considering it looks like a Cube World knock off.
Although to be fair, I would imagine this game was first thought of as people's expectations for CW fell flat upon the initial (and only?) release
[+] [-] AngelOnFira|4 years ago|reply
Of course, since that was in mid 2018, many of the devs that have joined the project haven't played Cube World, and are inspired by other games or mechanics they enjoy. We list our inspirations as Cube World, BotW, and Dwarf Fortress as our primary ones. As is mentioned in other comments here, Minecraft is also part of this lineage, however, we aren't going down the path of buildable blocks very much.
Since the early days of Veloren, we've defintely worked to break away from "just a clone", into gameplay that is more derivative of what we can achive with our engine, but there is still a lot of work to go before we consider it "released" :)
[+] [-] chinchilla2020|4 years ago|reply
Are we not going to mention the 900lb gorilla, Minecraft?
[+] [-] andyfleming|4 years ago|reply
[+] [-] AngelOnFira|4 years ago|reply
[+] [-] Shared404|4 years ago|reply
Last time I played, it wasn't really there as a game yet, but I think it's about time to try again!
[+] [-] yardshop|4 years ago|reply
I got myself up into the Giant Tree and spent three nights. The colors and effects are wonderful. I could zoom way out to the neighboring mountains and pan around to see the whole landscape, then back in to see the crazy creatures on top of the tree.
I put on my glider and jumped out of the tree and realized I didn't know how to fly yet and splat!!
Even though it's multiplayer and has quests and lots of activities, I had a great time just exploring around by myself. Thanks for a fun game!
[+] [-] elcritch|4 years ago|reply
[+] [-] chimprich|4 years ago|reply
[+] [-] pca006132|4 years ago|reply
Launcher GitHub page: https://github.com/veloren/Airshipper
[+] [-] okasaki|4 years ago|reply
[+] [-] kretaceous|4 years ago|reply
Any help? I really want to play it!
[+] [-] UltraViolence|4 years ago|reply
I very much appreciate the stability and performance Rust brings. I believe software written in Rust is much more long-lived that similar C/C++ software since memory issues are almost certain to occur with the latter.
Not to mention the security benefits Rust brings to the table.
I don't really care for the game itself. I'm much more a BZFlag player anyway.
[+] [-] orangetuba|4 years ago|reply
[+] [-] Jweb_Guru|4 years ago|reply
The other two choices people usually bring up are OpenGL and Vulkan. The project was originally using OpenGL and was quite limited as a result; theoretically, you can do better by abandoning portable versions of OpenGL, but many modern OpenGL drivers are incredibly poor (particularly on Windows), and a lot of machines support, e.g., DirectX 11 or Metal but not a version of OpenGL with the same feature set. Going with straight Vulkan means you're either going through a (slow) translation layer on many older machines (and Macs), or giving up on them entirely. Vulkan is also incredibly hard to use correctly if you're using it directly and want to be portable across GPUs; the spec has a lot of edge cases that are quite unclear even to experts, and often requires consulting with driver developers to figure out exactly how they were interpreted (to be fair, this has become less of a problem over time, but it's still an issue for corner cases in the spec).
[+] [-] Yaina|4 years ago|reply
(But it looks cool, definitely gonna browse through the source code a little)
[+] [-] holografix|4 years ago|reply
Ie: is it authorative? How does it handle collision detection between players, combat, projectiles, area of effect spells etc?
I’m looking more for documentation and thought process vs straight up code as I’m not a rust dev
[+] [-] Shadonototra|4 years ago|reply
I can't imagine myself being stuck for 10 minutes to see a change happen on screen
Just take a look at a Veloren dev changing a line, then compiling it: https://www.youtube.com/watch?v=nR2WDBMjkh8&t=976s
Rust is not made for game dev, this project is the proof, your progress will stall at some point because you won't be able to iterate on your game anymore!
That's the curse of Rust
Where are the gamedev that announced using Rust from now on 5 years ago? they still stuck compiling their projects!
What a disaster: https://github.com/veloren/veloren/blob/master/Cargo.lock
7.5k LOC just for dependencies..
[+] [-] Jweb_Guru|4 years ago|reply
* Compilation is a ton faster on an M1 and with a non-default linker. Compilation from scratch (including all dependencies) took around 10 minutes for me last time I tried; compilation of the main game is much faster (I think in the ~ 1 minute range, which is more than acceptable if you're not doing something sensitive like animation work.). Obviously, not everyone has an M1, but it's hardly a dealbreaker if you've got a machine designed for development.
* The developer in your video is changing a line in veloren-common, a "root" crate that leads to a bunch of other stuff recompiling. The vast majority of changes are in leaf crates, which compile much faster. For animations, in particular (which require quick feedback) we have a separate compilation unit that compiles on the order of seconds and can be configured to be dynamically linked to the main game, so they can get pretty much instant feedback. For as many kinds of assets and data as possible, we also push it out to configuration files with hot reloading, so most people working on models, item and color tweaks, etc. don't have to wait for compilation at all and can just save their files.
* Many games written in C++ also take ages to compile. Rust isn't unique in that regard. Clearly, it hasn't stopped Veloren's development (I can't think of anyone who quit development because of the compile times, though there's a lot of grumbling). In fact, I'd venture to say that Veloren has had some of the most developers and fastest development of any 3D open source game I'm aware of, regardless of language.
* No major developer I'm aware of announced using Rust for games 5 years ago. What are you talking about? If you mean the Chucklefish title, that had nothing to do with compile times. As far as I know, the game companies using Rust right now are mostly using it for tooling.
* The file you linked is the equivalent of yarn.lock, Cargo.toml is the actual dependency file. Dependencies do not need to be recompiled each time you compile Veloren, only the first time. Additionally, most dependencies compile pretty quickly and parallelize well. There are a handful of dependencies (the procedural macro ones in particular) that take a huge percentage of the overall compile time and/or act as bottlenecks, which is tolerated because they are extremely useful.
Veloren could optimize more aggressively for compile time, if the project was so inclined. A lot of that compile time is spent on generated code from macros like serde. Veloren also deliberately tends to use very large crates rather than trying to split everything into very small compilation units (some of them have been split up to improve compile times, but not too much). The project's perspective is that benefits of using those libraries (which greatly simplify development) and having fewer crates (which makes it much easier to avoid exposing internal APIs to get anything done) far outweigh the compile time costs, but not every project takes that approach and there are a lot of games that compile much faster than Veloren. It's really not a fundamental limitation of the language.
[+] [-] coryrc|4 years ago|reply
[+] [-] p0nce|4 years ago|reply