* I'd assume peformance was great, but is there metrics to show?
* Is the client and server written in Rust, or just the server?
In particular if you do the engine as a collaborative piece, then running a game starts to look like any other volunteer group: a bimodal distribution where few old hands keep it on the rails, a lot of new people whose raw enthusiasm overpowers their lack of experience, who need to be given tasks they can not fuck up so badly.
In between it’s a race between burnout and life balance for the people who have shown up for three years. They provide a lot of the leadership and competence, but they also tend to disappear. So you need to groom the newbs to replace them regularly. The old hands are the scribes who provide historical data when those transitions don’t go smoothly. They are continuity and influence, not productivity.
Any system that provides some safety for people still working out how to contribute is going to fare much better than one that is alienating. Rust to me is a mix of both, therefore plausible but not a slam dunk.
Open-source + built in a slightly interesting language are the only reasons we'd be discussing an MMORPG.
Good luck to the team. MMORPG that anyone wants to play is probably the hardest challenge in gamedev and game design.
Did not know that
What does that have to do with the parent comment? The usual argument I've seen is that game developers "move too fast", "don't have everything designed ahead of time", "have to iterate quickly" and Rust's insistence on writing correct code gets in the way of that during the prototype phase.
Java doesn't really have that issue as it is quite a bit more forgiving than C++ and will happily let you hammer a square peg into a round hole at the expense of performance, as evidenced by Minecraft.
And everyone who plays large modpacks, goes around large buildings, or just sets off a ton of TNT has seen how it has suffered for it.
On the other side, anyone who has seen the selection of mods available for Java edition vs bedrock edition (the C++ rewrite) despite a modding API for bedrock being officially supported has seen how it has benefitted from this.
We chose Rust because it's performant, memory-safe, and comes with a host of modern features that make writing code with the language very enjoyable.
We could have chosen C++, but I'm very glad that we didn't. Memory safety is great: I've not needed to break out gdb even once throughout the history of this project, despite the size of the project. This safety means that code is easier to review because it 'does what it says on the tin' and is much less prone to UB and non-local behaviours. It also reduces the prevalence of bugs. I've been shocked by just how much easier it is to write reliable and bug-free code with Rust than it is with languages that I've used in the past (C, C++, Python, Vala, amongst others).
The type system is also very powerful and it lets us encode a lot of useful invariants that can be checked by the compiler. Knowing that what you're doing is correct-by-nature is a great help and it frees your mind up to focus on the logic of what you're writing rather than getting distracted by irrelevant details like representation.
Rust plays very well with data-oriented design. This works great for us. At its heart, Veloren uses a high-performance ECS that is extremely cache-coherent. There's still lots of optimisation work to do, but we're already seeing that servers that can handle hundreds of players and millions of entities without issue, despite the fact that terrain generation is done server-side (and, as such, we have similar performance constraints to games like Minecraft).
The client, server and client/server frontends (frontends are logically independent and alternative frontends can be written for the game) are all written in Rust. In addition, the in-development plugin API will allow for plugins written in Rust and compiled to WASM.
In addition, Rust is also very portable. Compiling the game on (and for) many platforms is incredibly easy. The game runs well on Windows, Mac OS, Linux, BSD, and community members have even gotten it running on the Raspberry Pi and a hacked Nintendo Switch!
I hope this doesn't come across as being overly evangelical, but I think I speak for all of the developers when I say that we have no regrets in the slightest about choosing Rust! That doesn't mean it's the right choice for all projects, of course. The Rust gamedev ecosystem is still relatively immature. Although this is changing fast, don't expect to find any nuts-and-bolts game engines ready to go. However, if you're not afraid of diving down into low-level APIs here and there, Rust might be a great choice.
Edit: At a second glance, I see you're asking more about why mentioning the language is important. As a community-driven project, we rely on encouraging new contributors to work on the game and the choice of language is something that developers usually care about a lot. Extensibility and open development is really important for us and so 'showing the innards' is a big part of what we do when interacting with the community. Unless it's security-sensitive, we'll always discuss development issues and ideas in a public forum where anybody can add their input.
https://rustgamedev.com/episodes/interview-with-team-veloren
Not at all, I'm worried now my post seemed mean! This was exactly what I was looking for. I wanted to know if this was chosen just as a PoC for Rust, or whether it actively made development better (which it sounds like it does :D). There's a big difference between "Here is X written in Rust" and "X is so much easier because we wrote it in Rust!".
The fact you then go on to use ECS within Rust must have amazing returns on metrics. Good luck on your progress!
I think you meant cache-efficient, ie: it uses the cache efficiently. Cache coherence is something completely different.
And in general is should be much easier to create a performance sensitive game in Rust then in Java. Besides that Rust is much more ergonomic to use.
Those things could be a huge deal for any game developer, especially, when you already know Rust.
Consumer software is better without crashes. It's sad how rife software is these days with segfaults that can be prevented by design.
I can see an argument that Rust could also help prevent those as it is a higher-level language and has a few language features to prevent some of the logic problems, but not that many?
(that said, I have personally found bugs in text-based MUDs that could have been prevented by Rust. They were all "just" DoS bugs though, instantly crash the server type things)
Why? Just good language design. Things like "enums" (algebraic data types, not C-enums) making for type checked state machines, really strict typing, immutability by default, simple language semantics, good linters that people actually use, the borrow checker actually does usually lend itself to good design too, and so on.
void inner (const T& t1, T& t2);
void outer (T* t, int i, int j) {
inner(t[i], t[j]);
}
- the pointer `t` is not checked for null
- the indices `i` and `j` are not checked to see if they are outside the bounds of `i` and `j`
- the indices `i` and `j` are not checked to see if they are the same.
Rust will prevent all three, or force you to perform the checks before using an `unsafe` block.
But more than that, this kind of issue crops up due to an inherent weakness of code review - it catches errors in blocks of logic, but not in logic below it and logic above it. Since C/C++ don't have idiomatic error handling worth a damn (the only "idiomatic" errors in C++ are debug assertions, ime) you can't defend against silent logic bugs due to violating invariants of callers or callees that are expressed through Option/Result types in Rust (I mentioned this in a comment above). That's the real benefit of writing code in Rust, in addition to the absence of footguns.
Or, you know, nasal demons
That a stronger type system "eliminates a whole class of bugs" is nice and all, but users should be wary of the false sense of security it gives (in the same way that the weak type system of C gives a false sense of security when you come from assembler programming). You can have proven and certified bug-free crypto routines, and fail pathetically because their a giant hole in your crypto system. Just a friendly warning.