The Future of Rustecs

[hannobraun]

Hi everyone,

this is both a heads up regarding the current status of Rustecs, as well as a request for feedback regarding its future.

Current Status

I think you can tell that Rustecs is currently unmaintained. The build has been broken for a while and nobody has stepped up to fix it. As for me, the reason is that I wrote Rustecs for my own use in a game project and, due to a detour in said project, I'm not using it any more.

This detour is about to end, however, and I'm going to need something like Rustecs again in the near future. I'm not sure whether I should resurrect Rustecs or try a different approach. Rustecs as it stands has a few problems, and I don't know if it's worth fixing.

The Problems

• It uses syntax extensions. This is a problem for two reasons: First, it makes it hard to debug problems as any compiler errors point to code that you can't see. Yes, it's possible to tell rustc to expand any macros, but that's more fiddling around than I would like. Second, syntax extensions are considered unstable and thus won't be available in stable Rust releases.
• It tries to do too many things. While I like Rustecs' general approach to managing game data, I'm not really happy about the infrastructure around it, namely the half-finished systems support. The current approach makes Rustecs responsible for calling systems, which implies it needs to handle the events that trigger those systems. I don't like this. I believe Rustecs (or a library like it) should be great at managing data, but leave the events and logic to other libraries (or custom code by the user).

The Future

I haven't fully decided yet, but I think I'll try it again with a new approach, instead of attempting to fix Rustecs. That code will probably live in the private repository for my game until it matures a bit and becomes useful. That would mean Rustecs would become deprecated and I will at some point release a new library, probably under a different name.

What Do You Think?

Is there anyone still interested in the project? If so, what's your opinion?

I'd especially be interested to hear what people use instead of Rustecs. I'm aware of several ECS projects in Rust, but haven't really looked into any of them besides cursory glances at the code.

[mtsr]

I'm definitely still interested to see others' approaches to an ECS in Rust. And if at some point somebody comes up with a really great solution, I'll be happy to help out.

I was working on my own ECS, but all my gamedev is on hold for a bit. I'm still thinking about how I'll do it once I get back to it though. Systems is definitely one of the things that's getting a lot of thought, since a half-baked implementation is worse than none at all. Also I'm rethinking how to parallelise system updates.

[viperscape]

I was inspired by your library and started, but have now paused, work on my own ecs and even a basic entity collection-- which never made it to my ecs project ironically. I was interested mostly in concurrency and ended up working on a message passing concept. I'd like to see a more generic approach that supports systems being on threads, I'm not sure your library could achieve this easily.

[hannobraun]

@viperscape Interesting, thanks for the links!

I was interested mostly in concurrency and ended up working on a message passing concept. I'd like to see a more generic approach that supports systems being on threads, I'm not sure your library could achieve this easily.

I don't know. Honestly, I haven't really thought about it much.
Running the game logic on multiple threads is not important to me right now. Maybe my game will require it at some point, but until then I'd like to keep things as simple as I can.