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
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.
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!
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" :)
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).
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?).
tl;dr, Discord is forcing bots that are in over 75 servers to make use of slash commands, because Discord will no longer send raw messages starting April 2022. So no more `!pause`, or whatever else you might normally type. And this change isn't easy to implement for Discord.py, and would require full bot rewrites for devs using the library. So along with a lot of other negligence towards bot developers from Discord, Discord.py's single developer has stepped down, and no other core library developers chose to step up.
> Discord is forcing bots that are in over 75 servers to make use of slash commands, because Discord will no longer send raw messages starting April 2022
Can someone explain why that is? My understanding is that adding bots to a server requires Admin/Owner access, who are already at liberty to read all messages. If you don't trust bots scraping your messages in a server, don't you implicitely distrust the owners? Just leave the server?
I wonder if it's the real target here is bridges - without being able to relay messages (without ToS violating puppeting), it's going to get a lot harder to migrate users from discord.
I remember a while back reading a thing where basically there were bots out there essentially scraping entire chat logs without its users really being aware of this. There's probably also a lot of stuff going around with identity (like people making bots that look like official ones but aren't) etc.
I get people complaining about this situation, but there is a gradient of access between "no content access whatsoever" and "the bot can see everything". Slack's API does a pretty good job of making some of this work
There is a third party you have to implicitly trust, the bot developer. Given most of these bots are used to provide specific functionality, them being able to read messages seems too broad in scope – I know I don't want to have to trust another invisible party to also do the right thing.
That said, this looks like very poor communication and imposition of a lot of developer toil on Discord's part.
They should allow server owners to choose whether every bot they have added can read every message or just /commands. But that would require too much intelligence on their part :P
The problem is admins haphazardly adding tons of toy bots to servers with sometimes hundreds or thousands of members, and those bots being a front for storing tons of user data (including eg. user online status, user tag (name#1234) history, a large DB of the users' messages across years). The users in these servers aren't informed of such change and Discord can't trust these developers to say "we don't log messages" without requiring them tie a legal identity to any potential malicious logging.
> Unfortunately, at the same time, there were growing concerns with a user-bot ring that made a website and scraper known as "dis.cool", which farmed user information.
> Most library developers felt the changes were misdirected and targeted the wrong type of bot. The threat model was based on user-bots being bad actors, and not regular bots, while the changes targeted regular bots. We also felt that it was easy to sidestep the restrictions by just having a bot ring, similar to what is now done today with user-bots.
> Discord claimed [the new requirements, including government ID] would help with security and privacy by preventing malicious bots from growing and obtaining sensitive data. The library developers responded that it wouldn't help since malicious bots had to be invited and the crux of malicious bots were, and still are, user-bots.
Seems like a reasonable description of the issue to me, covering everything in that comment.
If you feel it gets lost in the words then I think the proper thing to criticize is the writing style, not the credibility.
(If the term is unclear, "user-bot" means it's a normal user account being used in an automated way.)
Yes. That is the case, and we (developers) argued that, the response we received was "but the _users_ may not know, even if the owner has authorized the bot".
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