Veloren – Open-source MMORPG written in Rust | Hacker News Reader

Veloren – Open-source MMORPG written in Rust

veloren.net

308 pointsagluszak143 comments

I've been keeping an eye on this one, it's not quite there yet if you are looking for a game to play. However, it has a massive amount of potential, and I'm looking forward to seeing where it goes from here.

I've also read the code looking for examples of how to do things in Rust, and found it quite pleasant.

It’s like the first large scale game written in Rust.

what would be the advantage of this vs established libraries written in C#? any thing Rust offers that other languages don't? website is short on details, would be great if they could display its features. There are other MMORPG/MMO frameworks that are quite mature but this looks promising too.

edit: reply to one of the comments below regarding the argument Rust = good therefore great for gaming. This. Neither does a good engine. For me I stopped UE4 and went to Unity because of the sheer lack of documentation and community support behind C++ with UE4. C++ is a powerful language but man was it hard finding tutorials and documentation that was up to date.

The goal is making these libraries in Rust. Rust is fundamentally a better language for game development than C#.

0 games have shipped in Rust and there is no plan anytime soon in the future that it will.

People think that a good language would make a good game, that's error #1. The ecosystem matters more than the language itself, basically using Rust is starting from scratch so you can't use all the good things that C++ / C# had for the last 15 years.

Edit: I want to clarify that I know that Rust is a good language, but as of now in 2021 it's just not ready for games, and there is no sign of change. It's fine to say "I can make games in Rust, it's going to be hard and painful but I can get something, but saying it's better than C# is definitly wrong.

> 0 games have shipped in Rust and there is no plan anytime soon in the future that it will.

That's trivially false.

> Last week, I released A Snake’s Tale on iOS, Android, Windows, Mac, and Linux.

> A Snake’s Tale was programmed entirely in Rust, and to the best of my knowledge, it is the first commercial game made in Rust to be released.

Dated 09 May 2017.

https://michaelfairley.com/blog/i-made-a-game-in-rust/

I think the parent means like AAA games.

Moving the goalpost

As someone replied I was talking about AAA games indeed, everyone can make a game in any language with 50 reviews on the app store after 3years.

AAA games are coming, there's at least two studios public about their in-progress Rust work. And backchannel whispers that may or may not come to fruition with more.

Time will tell.

And another one left Rust behind.

That wasn’t an AAA studio.

Ok, thanks for the correction.

What AAA games exist in C#?

Kerbal Space Program, for one

https://unity3d.com/showcase/case-stories/squad-kerbal-space...

Isn't Unity itself written in C++?

Isn't Rust itself built with a C++ based compiler, and binding to 3D system libraries written in C and C++?

There's a pretty big difference here though. In the case of Unity, most of the very hot code is C++. With a custom Rust engine, most of it is Rust.

On modern engines most of the hot code are GPGPU shaders, specially on cards modern enough to support mesh shaders.

Secondly, there is the ongoing rewrite from C++ into HPC#.

Third, I still remember the days when Pascal, Basic and C compilers were deemed worthless for professional game engines, followed by similar remarks to C++, back when Abrash books were still hot of the press.

Finally, languages don't dictate how fun games are and how much they sell.

Depends on how you define “c++ based compiler.” In the sense that it uses a library written in C++, yes, but “based” is kind of a stretch. It is an important one but not irreplaceable.

Yeah, I am splitting hairs on purpose, because at the end of the way winning benchmarks on the playground is meaningless on the business side.

Yes, Unity uses C++ in the core engine, just like in the old days the first wave of games written in C were full of inline Assembly, while the first wave of Objective-C and C++ games were plain old C.

Yet the Switch has outsold the DS, and Unity powers more than 50% of the games sold on the platform.

C# 9 is at the same level as D and Nim, minus a couple of little things that could still be added. To the point that with .NET 5, Microsoft has started to rewrite the runtime in C#, whereas Unity is slowly porting the rendering pipeline into the HPC# subset.

So if they would decide to have Unity on D or Nim, compiled with the LLVM compilers, which kind of discussion would we be having, which compiler makes clever use of LLVM IR?

> C# 9 is at the same level as D and Nim

What do you mean? How does one reach D/Nim levels of performance (or did you mean expressivity) in C#? I'm experimenting with Nim for gamedev these days, I might be persuaded to take another look at C# depending on your answer.

Also, what is the HPC# subset? Any resources to read about that?

As of .NET 5 and C# 9 (also applies partially to F# and VB) you can:

- use structs like in C

- do safe stack allocations for arrays

- use GC free heap allocations and map them to memory slices

- GC free code regions

- static lambdas

- machine numeric types

- static lambdas

- native function pointers

- native sized numeric types

- more control over structs layout and usage

- using available in any type that implements Dispose pattern even if the interface isn't adopted

- you can make use of Roslyn to ensure using is not forgotten

- unsafe and native pointers

- vector types for SIMD, NEON and AVX

- you can generate MSIL on the fly similarly to what C++/CLI compiler would have done. Naturally this trick requires unsafe Assemblies.

HPC# is a C# subset created by Unity with the long term roadmap goal to replace C++ on Unity. Although it looks like a C# subset and plain .NET types, there is a new compiler, Burst, that is aware of those special types.

There is also an ECS framework that goes alongside it, DOTS.

The founding members of the projects are ex Psygnosis employees well known in the C++ community.

https://docs.unity3d.com/Packages/com.unity.burst@1.5/manual...

https://youtu.be/BpwvXkoFcp8

https://youtube.com/playlist?list=PLX2vGYjWbI0QRLkvupULwSZCP...

Gotta start somewhere.

Sounds to me like those things just need to be rewritten. Or is the plan to keeping using the same language and libraries for the next 60+ years?

If you ask UNIX clones developers....

> 0 games have shipped in Rust and there is no plan anytime soon in the future that it will.

The language is still pretty new but there is a lot of people investing in this. Embark studios and Ready at Dawn come to mind.

> People think that a good language would make a good game, that's error #1. The ecosystem matters more than the language itself, basically using Rust is starting from scratch so you can't use all the good things that C++ / C# had for the last 15 years.

It's not an error. Ecosystem matters but to a point. Like game engines are written with a particular type of game in mind. If your game doesn't fit the particular use case, it might make more sense to roll your own. Also, if you have been building your own game engines in C++, doing it in Rust should not be much of a problem.

If you're waiting for some AAA title to ship, you'll be waiting a while. Big studios aren't going to be first adopters and they have expensive commercial tools for building games already. That said there are a bunch of toy project Rust games you could say are complete or "shipped" and many more games under development. There's no reason to be pessimistic about its use in the space. https://itch.io/games/made-with-rust

Rust has an interesting way of handling memory so that you don't need a GC. GCs can cause stutters in games.

You can do a full GC between loading levels, while using a little allocation as possible during a frame rendering.

Three is really no reason to have any time "between loading levels" these days, especially in an open world game.

It's a game not a framework unless I'm completely misreading their website.

The advantage vs some C# library is essentially the advantages of Rust over C#: precise control over memory layout and usage, no GC, higher performance, an ecosystem that was designed to be x-plat from the beginning instead of bolting that on after the fact.

I bet there are more platforms supporting Unity and Unreal (which also has C# support) than Rust.

C# also has all the C++ like mechanisms to do GC free allocation.

I've written a lot of high-performance code in C#, and in general I like it. What's really great about C# is that you can write maintainable, idiomatic, managed C# (using the GC etc), that is actually very performant for many cases. The you can dip into unsafe code (unmanaged memory, pointers etc) just for the really performance critical parts where managed code isn't fast enough (e.g. if you need to write/manage a lot of buffers).

There is more "ceremony" involved with unsafe C# code, but things like Span<T> and Memory<T> have made high-perf code so much easier in many cases.

Still, so for something that's basically all highly performance sensitive, something like Rust would be a good choice (I don't actually use Rust yet, but am planning to learn).

Well, the .NET team is the opinion that C# is becoming good enough to start rewriting the runtime in C#, which they started doing in .NET 5, with enough benchmarks to show where they are now and what might still be done in the .NET 6 timeframe.

I'm not sure this is why they did it (I doubt it is), but reading through the documentation I saw that it's playable on Linux, Mac and Windows. I don't know when I've seen an MMO that's not browser based that was playable on all three platforms. C# engines usually ship to Windows and Mac - though, in saying that, I'm not sure if that's engine enforced or developer choice.

The most likely reason they chose to do it in Rust, though, is because they wanted to and no one else had.

BSD too!

Zesterer (a dev) answered this in depth to another comment on this thread, ctrl-f for that name ;)

Alternatively, here is a link to the in-depth comment!

https://news.ycombinator.com/item?id=26038027

Likely a joy for Rust and a desire to try something ambitious that hasn't really been done.

Rust doesn't have the mature libraries that C# offers, but it isn't barren anymore either. It does offer nice assurances like entirely avoiding race conditions by default (when using safe Rust). Rust often leads to performant code, but it's hard to say if that's really a feature of the language or just a bias due to the kinds of people using it and the projects they work on.

If you're just looking to get into game development without any other goals in mind, then C# is a safer choice

>Rust often leads to performant code, but it's hard to say if that's really a feature of the language or just a bias due to the kinds of people using it and the projects they work on.

It does make memory management much more explicit, which makes it at least easier to write performant code.

The question however is what your program is doing. If it's limited by network requests or something similar with high latency you won't be able to optimize much on the language side of performance.

If however you're processing a lot of strings, the safe borrowing mechanism can help you avoid most copying.

For example on my previous job we had a part of our CI build that would parse a huge text file and combine it with some information from an ELF's debug info in Perl. It took 45 mins for one execution. It was also impossible to read.

I rewrote it in F# which after some heavy optimization work worked through it in 2 mins.

I had just heard of Rust and rewrote it in Rust, basically transforming F# to Rust syntax and trying to eliminate as many copies as possible. Now the whole execution took 8s.

So at that point I was sold on Rust, however the library ecosystem was still lacking. Nowadays it's much better.

Trust in Rust.

> I had just heard of Rust and rewrote it in Rust, basically transforming F# to Rust syntax and trying to eliminate as many copies as possible. Now the whole execution took 8s.

For what it is worth, I've had a very similar experience with the re-write of an internal tool in Rust.

I was in pure disbelief, running the next command in the toolchain this tool runs in, expecting it to fail on some empty input files but it worked. 20x speed-ups almost feel like some essential work must have been missed or skipped but when you realize that's not the case, it is a different kind of pleasure.

> It does offer nice assurances like entirely avoiding race conditions by default (when using safe Rust).

Doesn't it "just" prevent data races? I don't think it prevents all race conditions.

You are correct, yes.

Data races is what I meant; good catch.

Two Rust features stand out to me: no GC, and Rust’s excellent wasm support. In the Unity games I’ve played GC doesn’t seem to be much of an issue but your code is always going to be faster in Rust.

I use C# (.NET) daily and I think it’s great for game development, but Rust certainly has its own advantages.

> In the Unity games I’ve played GC doesn’t seem to be much of an issue

Remember that all of the 'hot' code is internal to Unity and is not written in C#. C# basically just takes on the role of a particularly powerful scripting language and isn't dealing with cleaning up huge amounts of data as would be the case for anything dealing with assets directly.

Unity is rewriting their C++ code in the HPC# subset and Burst compiler toolchain.

There are a couple of talks related to it.

It's very easy for it to become an issue if a game was written in Unity though. It tends to be really sluggish. E.g. Disco Elysium (amazing game) but the load screens were too much.

I don't know why but performance issues have become very common in modern games. Lots of games fail to scale to significant multiplayer populations. I still remember playing San Andreas Multiplayer/Multi Theft Auto and Just Cause 2 Multiplayer. In all three the multiplayer support is provided by a third party mod and they still managed to scale to hundreds of players per server.

To add to what others have mentioned, relevant features that come to mind (when comparing with C++):

a) Module system lowers the complexity overhead of using third-party libraries, which means you aren't tempted/required to reinvent as many wheels

b) Easy, reliable, monolithic build system, particularly for cross-platform builds

c) Ease of writing bug-resistant concurrent logic (my understanding is that concurrency doesn't get used much in games because it's so hard to get right)

Of course the above can mostly be said for C# too. But Rust could maybe be seen as the best of both (C++/C#) worlds

I would say its biggest disadvantage is simply that neither major engine uses it (officially). Unity and Unreal are so powerful at this point (and free for smaller projects!) that you're better off using them for nearly any game project, unless: a) you just feel like writing your engine from scratch for fun, b) you're doing something wildly novel, or c) you're a AAA studio that can afford to hand-roll an engine in order to save on licensing fees down the road. Maybe Rust will see adoption in category c one day, but there's a huge amount of institutional momentum to contend with.

Where Rust really shines compared to other languages IMO is when software grows beyond a certain scale. The way the language forces and encourages you to "do it properly" really prevents a lot of lazy decisions that would come back to haunt you later in unexpected ways.

The magical part about Rust really is how accurately (compared to other languages) you know which little gear in the big machine is failing. Often you even know precisely why and how it is failing.

Precondition for this is of course that you really grok Rusts ownership and type system.

You can do it non-properly in Rust as well, e.g. using unwraps, etc. but even then it's still way better than an UB-ridden component of a C++ codebase.

Using `unwrap` is not something that can come back to bite you in a long term (other than API design wise). Replacing it is dead easy, as the compiler helps you. Also, you can replace it with a call to `expect` to give a relevant message too.

That's why I said it's way better. It's usage is still not considered good practice for most scenarios.

Those .unwrap() and .clone() calls make the points for optimization or improvement very obvious.

Sure you can create these situations in Rust as well, but it makes that choice very obvious. So instead of being like: Damn, there was a case that I didn't consider at all you usually are like That case I decided against handling before must be handled now.

Of course you could still ignore it then, but the language made make this choice at every point consciously so it is totally your fault if it bites you later.

I e.g. tend to comment on unwraps why they cannot panic, and if they could (because I wanted to follow another strain of thought first, I use except and a message or writw a TODO comment.

Rust offers more performance. There are some big 3d games written in C#, but they have also suffered from performance issues.

C# performance is quite alright when people know how to use the language.

> this is only a partial list of changes made to improve the GC itself, but that last bullet brings me to a topic of particular fascination for me, as it speaks to a lot of the work we’ve done in .NET in recent years. In this release, we’ve continued, and even accelerated, the process of porting native implementations in the coreclr runtime from C/C++ to instead be normal C# managed code in System.Private.Corelib. Such a move has a plethora of benefits, including making it much easier for us to share a single implementation across multiple runtimes (like coreclr and mono), and even making it easier for us to evolve API surface area, such as by reusing the same logic to handle both arrays and spans. But one thing that takes some folks by surprise is that such benefits also include performance, in multiple ways.

https://devblogs.microsoft.com/dotnet/performance-improvemen...

> In a community run benchmark of different gRPC server implementations, .NET gets the highest requests per second after Rust, and is just ahead of C++ and Go.

https://devblogs.microsoft.com/aspnet/grpc-performance-impro...

From experience playing Veloren, it’s one of the least buggy alphas I’ve ever played, and it runs incredibly smoothly. Not sure if that can be attributed to language choice, but I thought it was pretty remarkable when trying it out.

Context: For those of you who still remember it, CubeWorld was a Minecraft-like RPG game that had a wildly popular Alpha, was eventually abandoned by its developer, was later revived, and was then universally vilified by the masses because the developers "ruined" the game.

Veloren is the spiritual successor to CubeWorld, made by disappointed fans wanting something better.

Just a small correction to that (because I don't like the hate that the Cube World devs get):

They never abandoned the game. It was a two person team (husband and wife), and both devs worked full time jobs while making CW. After the initial alpha release, CW got a ton of attention and became a DDoS target, which triggered some mental issues in the lead dev.[1] They went dark after that for a long time (probably because everything new was usually posted by this lead dev).

The silent mystery with the game just built up even more hype over six years until the full game finally released, and the massive attention and disaster seemed to happen all over again. Every post about the game complained about the new design decisions with leveling. The lead dev seemed to think this was the best version of the game (based on his comments in his blog) and he seems to not have taken the criticism well, leading to him going dark again.

I wish he would have taken the hits and continued with the game, but if it's affecting his mental health in this way, he is probably better off abandoning it. I hope he gets better and I am still looking forward to anything he and his wife make in the future.

[1] https://web.archive.org/web/20190910123212/http://wollay.blo...

Yep, this is correct. All of us Veloren developers very much appreciate the work the Cube World developer put into the game: it's great fun. Veloren isn't trying out outright compete with the game: increasingly, the project is adopting goals that differ. Over time, I'd like to see Dwarf Fortress be the game Veloren is most frequently compared to instead, since that seems to be the direction of momentum.

Thanks for the clarification. Not to throw shade on the original CubeWorld developers - the work they did and the level of polish they were able to achieve was quite incredible for such a small team.

Anybody looking for the actual source code, it’s here:

https://gitlab.com/veloren/veloren

I've been hearing about this game for a while now, I'm very glad it's making progress. I'm going to start following the blog as I'd like to try it out myself. I'm also glad that it's written in Rust, as I would very much like Rust to succeed as a high performance programming language :)

Is it me, or are the voxels way bigger than in 90s novalogic games? It's hard to say for sure because it's rendered at a much higher resolution, but it sure looks that way. I know the depth-of-field was crappy in those, but this just seems like not even as good as 25 year old technology.

Size isn’t really the focus. It’s a stylistic choice. These days if you built something with the limitations that Delta Force had, you’d probably be able to render scenes in the quadrillions of voxels. The largest scene I’ve seen is 1,000,000^3 voxels at < 1mm/voxel.

Okay, that makes sense. I'd probably get it if I'd ever played minecraft.

I read all the HN comments and it wasn't until I saw the logo on the site that I noticed the game isn't actually called "verloren" ("lost" in German). That makes me wonder: How did you come up with this choice of name?

I still pronounce it as "Verloren" as that was my initial impression as well lol

Been following this project for a while. Incredible community & devs, and it's getting better with each update. Surprised at how well it runs, too.

two years of weekly blog updates on the project! that's super impressive

in open source, talking about the work is really as important as doing the work. a key catalyst in turning "free as in beer" to the kind of communal shared understanding anarcho-syndicalist working practicing healthy community. i want a "free as in ourselves" mantra or some such to trot out here. anyhow Veloren keeping their story of development alive is such a respectable powerful act, keeping users & developers & everyone in between engaged & interested & learning.

This is super neat, I've been looking for an experience just like this recently. I think I'll be spinning up a server!

That's great! Make sure to tell us if you do, we'd love to put it up on the public server list!

Yup definitely will let you know

There was an interesting talk about how Veloren is structured at the Debian gaming mini-conf: https://peertube.debian.social/videos/watch/2670c322-0bcb-47...

Looks neat. I'm struggling to get why Rust is important in this context? Is it a demo of Rust's features and a fun way to learn, or is it a major feature of the game which lets you do things that games like Miecraft (in Java) couldn't do?

* I'd assume peformance was great, but is there metrics to show?

* Is the client and server written in Rust, or just the server?

I think it's important piece of information for HN given it's open source. I wouldn't care if it was closed source.

Rust is probably mentioned for the more up to date language concepts and type safety, as in "Look, our code is probably more reliable than the code of many other games.", which in turn might mean, that the user experience will be better.

Those things could be a huge deal for any game developer, especially, when you already know Rust.

I think Rust makes a compelling case for production code with a high degree of reliability without sacrificing too much performance. Something I think developers don't appreciate enough is that Rust helps you write code that doesn't crash nearly as much as something in C/C++, particularly with respect to how library authors express fallable code with option/result types and the lack of memory safety footguns like iterator invalidation.

Consumer software is better without crashes. It's sad how rife software is these days with segfaults that can be prevented by design.

But is Skyrim even worth it if you don't have mammoths walking in the sky and broken necks from overzealous head tracking?

Superficially speaking, I've seen a lot of comments around Rust's mismatch for assuming C++'s duties in game development so perhaps this is one of those "Rust in Production" signals

Minecraft was written in Java, so that can't be it.

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.

> Minecraft was written in Java

Did not know that

> Minecraft was written in Java, so that can't be it.

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.

The only evidence is that school kids cannot write mods like AAA studios, it wouldn't be any different if those mods were written C++, or JavaScript (Bedrock)

> Minecraft was written in Java, so that can't be it.

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.

2nd system effect, badly written mods perform poorly regardless of the language.

Hi, I'm the founder of the project.

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.

I think they were more asking why Rust matters to us as readers or users. Not that it isn’t great insight, but your answer is more like why rust matters to you.

The answer matters to people who write games in C++, or anything in C++. They want to know that Rust can handle/be productive in various domains.

Agreed

I heard about Veloren from the Rust Game Dev Podcast (Aug 2020). I really enjoyed listening to the team talk about details of the game's development, thank you for talking about it so openly.

https://rustgamedev.com/episodes/interview-with-team-veloren

The fact that you haven’t used gdb is a huge deal. This is very rare in large C++ projects.

"I hope this doesn't come across as being overly evangelical"

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!

> At its heart, Veloren uses a high-performance ECS that is extremely cache-coherent.

I think you meant cache-efficient, ie: it uses the cache efficiently. Cache coherence is something completely different.

In general in most modern languages there aren't really things you "cannot" do with one language that you could with another. It's more of a question of how easy it is to do something.

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.

Rust is more performant, but Java is actually much more ergonomic, since you dont need to worry about borrow checking concerns and its frequent refactoring. Still, the tradeoff is good for a game like this.

I wouldn't say so. Rust borrow checker is really only an issue for novices. Whereas Javas NullPointerException is the bane of even the most experienced dev.

As a part time game developer who uses mostly C++ and a bit of Python, I have considered writing a project with Rust a few times, but I've always struggled to find meaningful examples. This is game-changing.

The #1 problem in MMORPGs is people exploiting bugs for personal gain at the expense of the game's economy and competitiveness in PvP. Some of those bugs end up being in NPC scripts, but most are the kind Rust helps prevent.

Which bugs? I wasn't under the impression that exploiting memory safety issues was the dominant type of bug to gain an advantage in multiplayer games, but usually logic errors or some kind of broken script, corner cases in nested control structures, that sort of thing.

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?

My knowledge is many years out of date, so I might be wrong.

I'm also not really that familiar with either Rust or modern multiplayer games, I'm just speculating. It seems like if you could buffer-overflow the server, there are more sinister things you could do besides game-the-game...

(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)

Honestly, I think rust actually prevents a lot of logic problems, but it's hard to quantify and a subjective feeling that I'm not sure how I'd even go about trying to "prove". Order of magnitude I'd say 50% less logic bugs than a language like Java.

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.

This is a good summary tbh

Why must you trigger my inability to stick to a programming language? Elixir, Clojure, or Rust - round-a-round in my head they go. Will it ever stop, hell if I know. sigh

It's a mixed bag. Short of defining a formal spec and writing the program with a theorem prover, "bug-free" code isn't really a realistic goal. However, Rust does come with tools that at the very least allow the building of APIs that are very difficult to abuse via the trait system and other features such as sum types. Ultimately, spaghetti code is possible in virtually any language, so keeping a good eye on architecture is necessary no matter the language. What I would say is that Rust makes it easier to keep architecture constrained and correct.

There are memory safety bugs that won't cause a segmentation fault or create a buffer overflow exploit, but result in logical errors. For example:

    void inner (const T& t1, T& t2); 
    void outer (T* t, int i, int j) {
      inner(t[i], t[j]); 
    }

There are three memory safety bugs in that code:

  - 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.

The first bug will cause a segfault and crash. The second is a potential buffer exploit. The third is a logical bug that can be exploited depending on what inner() is supposed to do. Most people know to check the first two, the third one is subtle and isn't necessarily a bug. But it may become a bug that can be exploited inside `inner`, especially over the lifetime of the code.

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.

> The first bug will cause a segfault and crash.

Or, you know, nasal demons

It is sad to see that sibling answers are somewhat avoiding the question. I concur, "exploits" in MMORPG are about abusing unintended consequences in the design of the world, not in the design of the program. Like spawn locations where mobs are trapped and easier to kill, or combinations of weapons/gears/abilities that give an unforeseen advantage.

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.

This is not true, Rust woudn't prevent anything in most cheats / issues you see in online games. 99% of them are busines logic related.

It’s a dev community. The language is important as a hook for people interested in writing code in the language.

For certain classes of developers (of which I'd include myself), Rust is more accessible than C++. The tooling is more modern, the APIs feature functional constructs I'm used to for other languages, and it's not like C++ doesn't have its own feature explosion. If you're an open source game project, then it's signalling what developers might be most interested in the source in the hopes that some will then contribute, when addressing a forum of primarily developers.

As a wannabe game designer who moved on quickly to other things: object lifetime problems are a bane of game design. They give you memory leaks, and in some situations are how item duplication bugs work.

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.

What is the gameplay like?

We're aiming for something that plays a bit like Legend of Zelda but allows you to interact with the world in a manner closer to Dwarf Fortress. We're also trying to keep movement fluid and dynamic with lots of opportunity to use the environment around you as you move throughout the world.

All of this is a work in progress (hence the pre-alpha versioning), but we already have a few hours of gameplay with dungeons and caves to explore, lots of items to craft and find, and several skill trees to upgrade. In the long-term, we're aiming for more procedural interaction with elements of the world.

Is it possible for players to modify the world's landscape, like in Minecraft? If not, is this planned for the future?

Yes, but only via the admin-only /build command. It's not an ordinary part of gameplay, aside from the limited destruction you can do with some of the weapons. We're considering adding some sort of building system, but we've not reached a consensus on how to best implement it yet.

This game looks a lot like Cube World -- is this just a Cube World clone?

As someone who has never played cube world, why compare this game to cube world rather than to Minecraft? Looks very Minecrafty to me. Does cube world have something that makes it significantly different than Minecraft?

It doesn't look like minecraft, though. The character design, scale of the player to the world, design of the world (trees, houses, even mountains) looks identical to Cube World. The skill bar at the bottom looks like Cube World.

I encourage you to bring up a screenshot of Cube World side by side and see if you can tell the difference between this game. Looks nothing like Minecraft, except for it being blocky.

I like how everything written in Rust gets upvoted here.

Jokes aside thanks for sharing. It’s always interesting to read game source code and Rust beginners can learn a lot reading this code.

This comment was written in Rust

I'm out of the loop, what is the huge fascination with Rust? I see people getting excited about normal sounding projects that are written in rust - is it the new C? new python?

For me personally:

* It has the performance profile of C

* A really good package manager

* I don't have to worry about segfaults/runtime issues from manual memory management

* I love the type system (yay expressive static types with pattern matching)

* Also prevents data races and other things like iterator invalidation

* Also, null safety, among other things leads to a lot fewer runtime issues I need to figure out

New C since it's about zero cost abstractions (in the don't pay for what you don't use sense)

It does this well, since at the same time I was able to write 10k lines of JS game code into 10k lines of Rust game code: https://www.reddit.com/r/rust/comments/k3jy5g/i_rewrote_10k_...

Have since rewritten server from nodejs to Rust. There the line count grew. But async/await was splendid there, & serde made implementing the json server/client protocol straight forward

Others may give a better answer, but from my perspective -- a data engineer who started learning rust maybe 8-10 mo ago -- I find that I am enjoying Rust because:

* It has algebraic data types, pattern matching, etc. - language features that just don't exist in most languages I've used. (I did play with F# for a bit and really loved its capabilities, but I've never had the occasion to get into F#, unfortunately.) Once I start using these features, I suddenly find that all these other languages are sorely lacking.

* Its safety guarantees mean that I spend more time in the IDE fixing compiler errors and less time in the running exe finding my problem. I often find that when my program compiles, it is generally correct. This has given me a lot of confidence in the quality of my releases (borne out in actual production code, not just toy projects)

* Speed of execution is (in my experience), better than an order of magnitude faster than in other languages for a similar implementation.

YMMV, and there may be some of that New Relationship Energy here, but I can absolutely see why it's been on SO's most loved languages for five years in a row[0].

[0] https://insights.stackoverflow.com/survey/2020#technology-mo...

Closer to the new C

The thing people get excited about are guarantees you get when compiling your (hopefully well written) Rust code.

A huge chunk of software we have today is built upon other software that is built upon other software that ... but that whole foundation is rather shaky and probably incorrect. Basically, if you want to express it that way: Everything is broken and we have played the wrapping game for far too long as a professional group. There will probably forever remain bugs in that gigantic mountain of code, that we rely on.

People get excited about rewriting things in Rust to avoid a good chunk of the legacy code written in languages that are not memory save and that do have a lot of undefined behavior or allow for race conditions easily once you even as little as touch concurrency. People want to finally have a solid basis, which is proven to be correct in implementation. Rust goes a long way towards this goal, so people like it.

I subscribe to some great projects' repositories and read the issues. These projects sometimes bring me great value and I am not saying they aren't useful. Usually however, non-trivial C++ or C (and other languages) projects have all the same kind of issues. People thinking every noun has to be a class and the standard paradigm of mutating everything everywhere, be it through setter or directly, then forgetting to update state at some point, where it was necessary. People sharing state across multiple threads and forgetting to acquire a lock or releasing it. Or in some other way building race conditions. People thinking they will be able to do manual memory management correctly and then having segfaults, which require long debugging sessions or a lot of experience to fix. Use after free bugs. Security issues resulting from such causes. This and all that kind of stuff, that a good type system should prevent you from doing. And that is where Rust delivers.

Here's a relevant statistic. Microsoft tracked all their security vulnerabilities over 10 years and found that 70% of them were caused by memory-related bugs.

And yet the only language allowed on Azure Sphere, their high security IoT device is C, while WinUI marketing line is being written in C++, go figure.

Are you sure it wasn't the Chromium project? I have this one in my mind: https://www.zdnet.com/article/chrome-70-of-all-security-bugs... But then again it could be the same for other projects and just be a general thing that happens.

Borrowchecker and lifetimes automatize a big chunk of verifying all the states my code can yield.

Rust has many zero cost abstractions that make writing things easier.

It’s super high level at the speed class of C - sometimes even faster given that libraries for common tasks are well programmed. With the high level abstractions the compiler may probably reason and optimize better?

Aside from being a generally well-designed modern language with good tooling, I think the most interesting thing about Rust is that it accomplishes something that I wouldn't have thought was even possible until Rust came along: they made a memory-safe language that doesn't use garbage collection. The end result is that if you want to write high performance code, you don't have to do it in a language that's difficult to use correctly.

Reminds me of the three or so years HN was obsessed with all things node.js and npm that ended about three years.

Rust is a great language, not my preference (Julia is better imo, and I still absolutely love C), but the community and tools being built in Rust are fantastic.

> Julia is better imo

Can we please stop saying X language is "better" than Y? It really does not make any sense. Both languages were designed with very different goals in mind. Each of them is a good fit for their respective use cases, but saying Julia is "better" than Rust makes no sense.

Completely disagree. There's a tendency these days to say that because you can't quantify better-ness, things can't be better. Which isn't true at all; betterness can be subjective or heuristic or approximate.

Of course, saying something is better than something else is always prefixed with an implicit "I believe that...", so it's fine to argue with it. But that doesn't mean it's an illegitimate thing to say.

No, definitely not. There are so many programming languages and they are all usable for >90% of all the programming problems out there. So there's significant overlap.

Some languages are better: more conducive to popularity; safer; more conducive to not wasting resources; nicer to work with; more expressive. We don't have reliable methods of objectively measuring these metrics, but they do exist.

Rust, I believe, has a pretty high aggregate score.

Would have been better to do the game on a commercial basis and release the engine open source if they wanted to demonstrate the viability of game dev in rust, but otherwise it looks promising

Reply on news.ycombinator.com