Game development in Rust – Current state

#1

I'm not working as a game developer and I have no real experience in game development either (other than teaching some very basic game programming for educational purposes in Scratch and Python). That said, I would like to learn more about game programming.

Looking at some libraries for Rust, I got pointed to the Entity-Component-System concept, which I found quite interesting, and I did experiment myself with that by following a small tutorioal for writing a tiny ECS in Rust. I tried to improve it by using better suited data structures, but didn't do much more. (Side note: I had to deal with downcasting using std::any which behaved a bit surprising, but finally understood that I need to implement methods in each downcastable type.)

I found some websites such as:

But overall it seems like I would need to take a deeper look at each available framework to get an overview, but I thought I might ask this forum if other people made some experiences with these frameworks (or ECS crates). There are seem to be different ones, many "inspired" by others.

I generally like minimalistic approaches rather than huge dependency trees, but I'm also open to try larger frameworks if it's worth using them.

If there are more websites dealing with these issues, feel free to post any links in that matter.

P.S.: How is the progress of Rust support in regard to the "big players" in the gaming world, such as Unity? (I never used Unity myself.)

1 Like
#2

In my view, Rust game engines are kinda split into two camps at the moment:

  • Frameworks: mostly focus on 2D games and aren't too opinionated about how you structure your code. Generally they aim for a similar abstraction level as libraries like MonoGame, Love2D and Raylib, and do not aim to provide stuff like an editor or a complex asset pipeline.
  • Engines: aim to support 2D and 3D, and are much more opinionated about your game's architecture (e.g. many of them have built in ECS frameworks). While none of them are quite there yet, they aim to build something on par with Godot or Unity in the long run, with editors either being built or on their roadmaps.
    • Popular examples: Bevy, rg3d, Amethyst (note that development has recently been stopped on the latter, in favour of other libraries)

All of the libraries I've linked above are solid options in my opinion, so I would recommend picking which of the two approaches fits your needs/preferences and then looking at some example code for each of them.

With regards to ECS libraries - there's a million of them (it's a running joke on the Rust Gamedev Discord that it should be renamed to the Rust ECS dev Discord), but the most widely used ones are:

  • specs: The first one to gain real traction. Uses column-based storage.
  • legion: A spiritual successor of sorts to specs, very feature-packed. Uses archetype-based storage.
  • hecs: An extremely minimal ECS library, very lightweight and unopinionated. Uses archetype-based storage.

hecs is my favourite, solely because it's the least boilerplate-y, but there's lots of good options out there.

P.S.: How is the progress of Rust support in regard to the "big players" in the gaming world, such as Unity? (I never used Unity myself.)

I don't know of any work ongoing to support Rust in Unity, but people have used it in Unreal with some degree of success, and there's a good set of bindings for Godot.

EDIT: I was wrong, people have managed to get Rust running in Unity too, via FFI.

5 Likes
#3

Thanks for your reply.

I wasn't aware of the separation into these categories. From my quick search on the internet, it seems that Engines are bigger (monolithic?) and are kinda "told" how to do things, while Frameworks are lighter (modular?) and more "used" like a software library?

Not sure if there is a clear distinction between those two categories? But it seems like a common classification.

I read of Amethyst before, and it's news for me that they halted development. Last time I looked at Bevy, there seemed a lot to be still "in development".

May I ask what is the difference between column-based storage and archetype-based storage? Does column-based mean that some sort of "slot" is stored for each entity and component, irregardless whether the entity has that component?

I think I was looking into hecs before (has been a while). May I ask what sort of features I might be "missing" when using hecs instead of legion? (If it's easy to answer. I can also look into that myself.)

#4

I'm porting my C++ game engine into Rust now, there are two reasons I choose Rust:

  1. Safety behavior: I wrote C++ for decades, and still got a lot of unsolved bugs due to undefined behavior, much of them are async-memory safety problem.
  2. more powerful "compile time reflection"(not really): In game developing, we often add attributes to field, to make them either become serialized or shown on editors, C++ has powerful meta-programing, but lacking compile time reflection, it is very hard to, for example, iterate fields in a struct. I solve this problem by using Clang-AST to get type information to generate codes. The reason I said not really is because as long as I porting my engine, I found that Rust's derive macros still not as powerful as I expected, it only parse tokens, not a real AST, I still can't get type information. Currently I'm learning rustc driver, I think I'll do the same as I did with Clang-AST. But, still, derive macros is more powerful than C++ in reflection field.

Currently my engine use GFX for graphics, I use WGPU at first, but WGPU do not support multiple families, which may have a performance problem with high-end graphic card.

As for GUI, I decide to use IMGUI for Rust, it works well with GFX, but finally I may write my own UI system.

This is what I got so far, no physics or others, but I don't think it is a problem since Rust works well with C/C++.

My engine is still a no-brainer, and I don't have confidence to public it yet :rofl:, but it's very welcome to discuss game engine in Rust with me.

#5

Yeah, this is just how I personally would group things. I don't think they're super rigid categories, and other people might disagree about the split!

There's a very good blog post here by someone who used to work on Specs, detailing the differences between how Specs and Legion store their data.

Simplifying slightly, a column-based (group-based? I don't know the actual term) ECS stores components contiguously.

For example, if you had 2 entities made up of Position and Velocity, and 2 entities made up of Position and Sprite, the data would look like this:

[Position, Position, Position, Position]
[Velocity, Velocity]
[Sprite, Sprite]

An archetype-based ECS, on the other hand, stores components based on how entities combine them (their 'archetype'):

([Position, Position], [Velocity, Velocity])
([Position, Position], [Sprite, Sprite])

This can be a lot faster when you're iterating over multiple components (which you usually are), because the entities are effectively pre-filtered. This does mean that changing the 'shape' of an entity after it's spawned can be more expensive though, as it requires copying the data to the new archetype's table.

The main bit that hecs leaves out is any kind of built in abstraction for systems/parallel execution - you just query the World directly if you want to get stuff out of it. That's a plus, in my eyes, as I don't tend to really need anything more complex than that in my projects, but if you do need that stuff, there's a library called yaks which extends hecs with a system scheduler.

1 Like
#6

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.