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.
Yes and no. You have the choice, the game offer an offline mode, where you are alone with npc in your own little world, or a online mode where you can connect to any server of your choice. The server is open-source too, so you can run your own little Veloren world for you and your friend.
Though, fair warning, the game, at least last time I played it, 2-3 months ago, was still very much balanced toward teaming up with at least one other person to beat most dungeons. You can beat them alone, at least the low level ones, but it becomes tedious since you respawn at the entrance of the dungeon, and they can be quite deep.
I also played an older version on an underpowered GPU (either 2016 Intel laptop integrated graphics or GT 730). I had to reduce the window resolution considerably, and the frame rate was still poor. I might try again on a faster GPU.
Yeah, it probably won't work well on an old laptop with integrated graphics. I'm using using an ancient AMD Phenom 8 core with a Radeon 6900. I think both are close to a decade old now.
Guessing more like Breath of the Wild. Jump off something really tall and open something akin to a canopy that lets you fly unpowered over long distances.
Veloren's is much more physics-based than BotW, you can tilt and steer the glider to control your flight. Here's a good video that also shows off the extreme elevation of the world's mountains: https://youtu.be/w-kYWjrU6IE
That looks fun! What happens afterwards? Do you have to spend many hours climbing back to the top of the mountain, or is there some sort of fast travel?
It doesn't take too long to climb back up; unlike Minecraft, you can walk/run up one level of elevation so it's not like you have to hit the jump key a thousand times. No fast travel that I know of, but dying will reset you to the last campfire you touched, so you could use that in a pinch. Also the game is open source, you can compile it yourself and teleport anywhere with dev options, or add the ability to fast travel. :)
Correct. They never even allowed private servers or mods. This is also what killed Tribes: Ascend. The modern microtransactions model has made games like Starsiege: Tribes impossible to make by profit seeking corps.
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.
This is really interesting, thanks so much for the reply! It's awesome to get a little bit more insight into projects like this, especially because I've got a limited (but growing) insight into both playing games and building projects with game engines.
Just to parrot back what (it sounds like) you're saying: using voxel-based assets in a game with community-contributed assets that extends itself using procedural generation is that the difficult of integration tends to be lower. This is because voxel shapes allow "artists" (which don't necessarily have to be highly-skilled) to build game-appropriate assets fairly easily, and for the generative process to more easily combine those elements into a cohesive world model than might be possible with polygon-based assets. Does that sound about right?
Ya, it's certainly a art style that gets complimented by both the artists, and the developers that work on worldgen. There's a lot of grey edges as well; at our last release party we had an artist create an entire pre-made city, and load that in for players to explore at our release party. None of the city was proc-gen, but it was really great to see how the architecture was put together when it was crafted by a human, compared to how our different proc-gen cities/forts/encampments look a lot more like they're part of the landscape.
So basically
+ Cohesive world
+ Ease for artists
+ Doesn't need to look so real
> So basically + Cohesive world + Ease for artists + Doesn't need to look so real
I think this is the basic principle as to why Nintendo was able to get away with underpowered consoles for as long as they did. At least in comparison against other beefier consoles out during each releases duration.
So long as the aesthetics and quality are consistent, people are willing to accept a lot.
From what I understand about the Dreamcast and even the Sega Saturn, is that both were underutilized in a myriad of ways, but one of the, the dreamcast I think, had technically two gpu chips.
There are comments from some developers over the matter from a while back. I think one of them was Todd Howard, back from when 'Todd rays' still weren't a thing.
Great game! Is there any resources where someone can learn more about procedural generation? Curious to know what places one can learn about "full erosion systems".
There are lots of other blog posts that discuss these topics, I should really aggregate some of these sections in the future. Those links go into the most detail I think, future stuff is more about tweaks than the core systems (we've been putting out a blog post each week for 160+ weeks now!)
bringing the idea further... is it possible to move the game towards something like "noita" where each pixel in noita can interact in a ton of ways etc... except here it would be a voxel?
I don't think so with the current engine, however, we do have a pretty solid particle system that does allow for some cool visuals similar to Notia. But that said, I'm not sure what "Notia inspired" physics would look like in a 3d game... I guess a lot of blocks melting? Could be cool to experiment with :) I know there are voxel engines that are far more geared towareds this than we are, we try to store information about each voxel as compactly as possible for efficiency, and we use LoD at the macro level (mountains off in the distance) rather than the micro level (zoom in really close on a single vosel, more geometry becomes visible).
I do think adding a Noita-style cellular automaton would be fairly straightforward.
Currently Veloren has water and lava, but neither will flow (e.g. if water blocks are manually placed on top of a hill, they won't flow downhill, fortunately this is rare due to worldgen). A simple way to fix this would be to have an ECS system that uses CA-style rules (e.g. a water block with an adjacent-and-below air block swaps places with that air block), though naively doing this would be expensive (iterating over all loaded terrain chunks every tick). A possible optimization would be to detect such blocks, remove them from the main terrain grid, put them in a separate entity-with-terrain-collider (the same kind we use for airships), and only iterate the (sparsely populated) AABB of fluids-that-have-recently-moved. This is similar to what Noita does with keeping track of recently-updated terrain rectangles. Once this is in place, it can be straightforwardly extended with more fluid interactions (e.g. Minecraft-style water + lava = obsidian, more Noita-inspired gases rising).
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.
Actually, completely the opposite is true. There's a reason that voxel games appeared after games with more traditional meshes.
The fundamental complexity of voxel data structures is higher: O(n^3) for iteration, and the density of polygons required after meshing is generally much higher. The only real benefit from a complexity standpoint is that storage and access of specific voxels is much faster, but this often doesn't represent a payoff.
Voxels are great for a lot of things, but making a game like Veloren run quickly is much harder than you might initially realise. There's a reason that we're told at least every 3 years that a new company has come up with the 'engine of the future' using voxel tech only to have it vanish into obscurity as they try to turn it into something that's not a tech demo.
For Veloren, there is a big benefit: we get to create enormous procedural worlds. But actually controlling the complexity of that data and efficiently storing/accessing it is a non-trivial change as you'll see from the project's dev blog.
>and the density of polygons required after meshing is generally much higher.
That seems a bit misleading. With uniform voxels the occlusion culling becomes much easier and you only render surface polygons.
On the other side you don't get hand made imposters so rendering far away mountains and such becomes a challenge. You dont want to render every voxel of a distant object if a voxel is smaller than a pixel.
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 :)
The only hole I found was if you bypass UI hashing you can create an account that can never be logged in to, but... that's the most secure account I can think of.
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 :/
The procedural generation somehow instantly provides a sense of mystery, that makes you want to discover what this "fresh" world has to offer. Like Minecraft, the unexplored feeling adds a sense of adventure, that is hard to mimic in a handcrafted map.
When you climb over a hill and are greeted with an amazing view, you feel like you are experiencing something unique, instead of the exact same curated sensation all the other players of the game will be having.
The fact that you cannot destroy every block in it does make the game feel more solid. The freedom you have in a game like Minecraft also limits certain gameplay aspects: you can always dig a hole and hide.
Personally I don't mind the lack of building options at all. It's fun, but it can get a bit grindy when you are trying to create something big in survival mode.
It was such a shame Cube World never got anywhere, I'm glad this is here to pick up where that left off!
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" :)
That's Cube World. This game looks a lot like Cube World. And not just in the way that Cube World looked like Minecraft in that it was blocks and procedural (which is mostly where Cube World and Minecraft intersected, cw has no block building in the game).
Looking at this game and knowing a little of the saga of Cube World I'd bet Veloren is an Open Source response to Cube World making an appearance, exciting a lot of people with potential, going silent for years, then eventually releasing something less fun than the initial preview and dropping into obscurity. It looks at a glance like this began development during the aforementioned silent period.
Other than the Voxel graphics, games like Cubeword and this have little in common with Minecraft. Minecraft from the start focused more on mining and building than movement and combat. Of course there's mod, and they later added enchantments, but Cube World focused a lot more on the RPG aspect, with classes, fluid movement, magic and extensive weaponry, etc. It's very different from the 1 block jump distance and sword+arrow of minecraft. The game play is also a lot more focused on dungeons, bosses etc. Minecraft shoehorned a dragon battle and "ending", but it's far from being a combat focused rpg.
Its literally three words after the excerpted section, but I agree that Cube World is a more direct inspiration. Certainly Minecraft popularised combining voxel games with open worlds, but I think gameplay wise Cube World definitely belongs first on the list. After all, Minecraft didn't introduce the concept of voxel terrain though, infiniminer and worms 3d being earlier examples of games using it
Having been a part of that era, I can attest that to a certain tribe of young and aspiring programmers, attempting to implement clones of Minecraft and talking endlessly about "procedural generation" and "voxels" and "chunks" was all the rage back in 2012.
Is the user supposed to have to use chmod to make the launcher executable on Mac? The docs don't mention anything about it so I'm not sure how non-devs will figure out how to run it.
Are there plans for an M1 version? I checked Gitlab issues and didn't see anything.
I was curious too, so I decided to build it. The build process took exactly 5min8sec on a M1 Pro, and was pretty flawless. Only gotcha was that I had to install rust v1.59.0-nightly using rustup because of one of the dependencies.
If you want to do the same:
brew install cmake git-lfs
git lfs install
git clone https://gitlab.com/veloren/veloren.git
cd veloren
cargo run
Based on this, I see no reason for a downloadable M1-ready version of Veloren to be made available. Compilation is trivial and fast, so might as well.
It runs on M1 under Rosetta emulation. Performance and stability would be better with an M1 native version.
It looks like the chmod issue has been around a long time. I found Reddit posts going back a year or two. If it's not going to be fixed, why not put a note on the downloads page so people can actually run the game?
Veloren uses some native libraries, so IIRC getting it to work under Rosetta was not completely painless either. That said, the reason native M1 builds aren't currently offered is that Apple makes it a pain to compile from other architectures, not that Veloren doesn't compile for M1 (it does). I believe native M1 builds are actually in progress right now. So is the chmod issue, which AFAIK we only figured out the root cause of relatively recently (September?).
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).
How do you implement all the things the game engine gives you for free? Physics, camera, scene management, lighting, colliders, shaders, navmesh, etc. It seems like an impossible feat to implement all this yourself PLUS build a game on top. Wouldn't just building the game itself be a 2000-20,000 hour project? And I imagine building the game engine would be an order of magnitude more complex, if not more time
It's a lot of work, but there are a lot of tutorials and readymade libraries out there to get you started (which you may end up ripping out if the project grows sufficiently that it's worth doing custom stuff, but most projects never get to that point). It's definitely nowhere near as difficult as it seems like it would be to get a basic game up and running (though it's still very hard)--you're not going to come close to competing with something like UE5, but if you're doing a game from scratch that probably isn't your goal in the first place.
For FOSS in particular, it helps that people are willing to devote massive amounts of free time to programming when the outcome is a video game--it's why a lot of people got into computer science in the first place, after all.
> 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.
Another cost is that you lose support for older GPUs.
This is an overstated problem, in our experience. Most older GPUs that don't support Vulkan, DirectX 12, or Metal, but would be capable of running the game in the first place, support DirectX 11, which is one of the wgpu backends already. An OpenGL fallback on Linux is coming and will help address the remaining cases, but it won't perform well at all (and we're okay with that, since the percentage of our users who actually need it is quite small; Vulkan support on Linux has gotten really good, probably thanks to Valve's efforts).
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.
> Many games written in C++ also take ages to compile.
Only if they didn't took the effort to use binary libraries for third party dependencies, or using hot code reloading tools like Live++ or Visual Studio's hot reload for native code.
Granted, nothing prevents Rust to have similar options, but they don't seem to be a high priority currently.
I mean... if you change the size of a type used by value in a bunch of other places downstream (the equivalent of the change in the video), none of what you're describing is going to help much with compile time, since it's not ABI compatible. For less invasive changes rustc already does a decent (not amazing) job of avoiding recompiling unchanged dependents. As far as initial compile time goes, precompiled binaries would definitely help (on non-overpowered hardware particularly), but initial compile time is not really a development bottleneck since people do not recompile from scratch all that often. I do think people dramatically underestimate how long they would spend waiting for the equivalent C++ libraries to compile when comparing from-scratch compilation times to Rust projects, though, but that's neither here nor there.
When you say 'broken', what you mean is '1 out of every 50 compiles will need a clean of the incremental compiler artifacts, which adds maybe 30 seconds to the subsequent compile but doesn't mean recompiling dependencies'. To call it 'broken' is quite misleading, it's just a minor annoyance that will be gone in the next release cycle.
> This mitigates the effects of a known bug, #94124, which can cause deserialization errors (and panics) during compilation with incremental compilation turned on.
Regardless of what gamedev SDKs with billions of dollars behind them do or do not do, initial compile time is simply not a major bottleneck for developer productivity for Veloren. What is a bottleneck is how long it takes from making a change to seeing it in-game after the initial compile. On that front, C++ and Rust are on pretty similar footing (at least when incremental compilation is working :P) and it mostly comes down to how much the project is prioritizing compile times.
C++ hot reload does not improve compile times beyond what you can do yourself via dynamic linking (and can't help at all within compilation units, or avoid recompiling dependencies when ABI-level stuff breaks--choosing to have relatively small and large numbers of compilation units, or discourage ABI-breaking changes, is absolutely a project-level choice). For stuff that's time sensitive to compile, Veloren already uses dynamic linking with automatic hot reloading with the correct configuration options. I agree it's not as convenient as having tooling to do it for you, but, again, there is a lot more money in that stuff than there is in Rust game development right now.
Like I said, it's not bad at all on an M1 (or other machines aimed at professional developers). A lot of the project's contributors are hobbyists or using less overpowered hardware, though, which is why the project has taken steps to try to make it better for the common cases (CI machines can also be an issue). But there's a huge difference between acknowledging it's a problem, and trying to somehow claim that it rules out Rust for game development (Veloren is an existence proof that this is not the case!).
(there is no good content in this post, they just want to arbitrarily hate. They make extremely basic errors throughout and clear haven't ever used Rust, at least for anything non-trivial)
PS: It would be great with a repository link on the downloads page. I missed the sentence about the license on the front page, and incorrectly assumed the game to be closed-source when the download page only showed binaries.
> An alpha version of [Cube World] was released in July 2013, but saw sparse updates and communication from von Funck, with many considering the game to be vaporware until he officially released it on September 30, 2019.
Depends on who you ask, but it is kinda worse than the alpha, far lesser scope.
Gameplay loop is defined though and it is definitely more finished than the alpha, but there are some very annoying game design choices and it is very repetitive, but people are trying to fix those things with mods, not sure how well since I haven't touched it since launch.
Yes and nope. Some fun and promising features were removed and whenever you switched zones all your levels would reset, except for some minor stats, breaking any sense of progress and nerfing the need to explore.
From their github/cargo.toml it seems to be using "wgpu" (https://sotrh.github.io/learn-wgpu/#what-is-wgpu) which at first glance seems to be an abstraction layer that can fallback to OpenGL/DirectX/etc depend on ng on the platform.
wgpu is based around the WebGPU standard, which is expected to replace WebGL in web browsers for 3D graphics. wgpu (and WebGPU) is closer to DX12/Vulkan/Metal than OpenGL/DX11. Although it's much easier to use than Vulkan/DX12, abstracting away things like synchronization, memory management. I use wgpu in my D application through wgpu-native (offers a C header to interface with languages other than Rust) and it's been a great experience overall.
Look very nice! Somehow I thought since it is Rust and not Java, it should be more fps than Minecraft (many other things seemingly comparable), but it's not, probably wrong assumptions on my end.
The bottleneck for a game like this is the GPU and not the CPU (usually). Additionally, Veloren has a tonne of things that Minecraft doesn't:
- A much larger world (compare the number of blocks in Veloren's trees against those of Minecraft, or the fact that mountains in Veloren are regularly many thousands of blocks tall, compared to Minecraft's 256 block height limit)
- PBR rendering
- Shadow-mapping
- Bloom
- A level of detail system, along with horizon maps for dynamic terrain-scale shadows
- More advanced voxel lighting that respects normals
- Fully volumetric cloud, aurora, and atmospheric rendering with raycasting
- More detailed character models and animations
- A more detailed particle system
- Dynamic point lights and related effects (point light diffusion, for example)
- High-detail terrain objects like grass, corn, etc.
As another poster said, there's not really much point in comparing the performance of the game to that of Minecraft. They have virtually nothing in common from a rendering perspective other than the fact that their polygon normals are mostly oriented toward the cardinal axes.
JITs can sometimes be faster than compiled binaries because they have runtime information, but realistically it's probably because Mojang has had years and years to optimise.
Also, they are two completely different games, there is absolutely no point in comparing them. A single game feature difference can render the comparison meaningless.
I definitely see where you're coming form, but we're quite confident that we couldn't have made this game without Rust!
There are lots of benefits we get, but here are some of the quick highlights:
1. "Code that compiles probably works" means that we can work quite quickly as a diverse team from all around the world, and not spend so much time worrying if our code will break that of others.
2. Our goal is to eventually be able to get 1000 players on the same world, on the same server. So far, the max we've reached is 195 players at our last release party. Our multiplayer server doesn't just send the location of players, but actually runs a ton of realtime simulations of the world, including economy, trade between towns, physics, NPCs, all with more coming in the future. All this to say with all the work that has to be done, we get massive benefits from how easy it is to do multithreading/ECS paradigm work with Rust
But either way, we always like to shill whatever we like best. Still very happy to be a flagship project to show off how cool Rust is!
What's wrong with it? Rust in one of the things I'm interested in, so it really helps when title contains "Rust". If you don't like it ignore it, nobody is forcing you to go through it.
3D free software game developed in modern times and not a fork of Quake 1 or 3 is what makes this a big deal to me. Rust is a neutral point to me, but it does probably make it harder to run on other architectures.
The biggest negative to me about this project has always been the way they push Discord on you. I'll likely never be a part of the community even if I do play it because of that.
Yes, but is it so special that us HNers need to be reminded about it every time someone rewrites some random software thingy in Rust? It gets so boring after a while.
I've never felt like anyone was reminding me about anything, HN is a site frequented by programmers, it's useful to programmers to see what other programmers are building and with what tools. Rust is popular so we see it a lot but we also see X written in Go, or Y written in Python, and so on.
I don’t think that’s completely correct - I think “written in rust” being bandied about as a feature is a somewhat unique feature of the Rust community
Not really. It especially happens with currently "interesting" languages more than with others, but it's fairly standard to mention it in places like here. E.g. a few years ago you saw it most with Go or NodeJS, because at that time those were the "interesting" languages.
There's also people like myself who have a general interest in voxel related software. I've always been fond of the aesthetic but also all of the optimizations people use for voxel games and renderers
Hacker news is a wonderful place where we can share many different projects and a love for tech and software development. Shallow, subjective, emotional comments don't lend themselves towards driving discussion and growth in any form, please consider expanding more fully on how this is "amateurish" and how that detracts from the artform.
You draw the voxels on the screen. You color pixels according to the positions of voxels, and shove them into the framebuffer.
IIRC Vangers could work without 3d acceleration (in the original release, at least), and possibly did not require it at all. Polygons are used for vehicles and items, and there are maybe fifty polygons per a vehicle. You'll notice also that the depth of the voxel terrain is quite limited, as is the main view dimensions.
If you take 'voxel' to mean '3D pixel', then how does Veloren not fall into that category? What does "real voxels" mean? If you're talking about rendering things as point-clouds or using raycasting, then you're not describing voxels. You're just describing one of many possible techniques for rendering voxels. Isosurface extraction into a polygon mesh is also in that set and is no less valid than the definition you're going for.
From what I understand, theres 2 different definitions of what a voxel is.
The first, as is the case with this, is moreso on the data structure side of things, in which a voxel is like a point in a point cloud, but the point cloud is fixed to a 3d grid. The meshes can be anything, but cubes are the most common, and they are almost always polygonal.
The second is, as you describe, a fundamentally different rendering method using "3d pixels" instead of polygons. These kinds of voxels almost always use the same data structure above as well, but as you say they aren't polygons.
Strange we ended up with the same word for both, unless I'm mistaken
Voxels as in ‘3d pixels’ have been around since the 90s at the least, as evidenced by Vangers. Later, some people took the word and used it to describe Minecraft, in the meaning ‘big blobs that aren't even the smallest atomic unit, as there are clearly items that are made with smaller shapes’.
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.