RFC: Should we rewrite or partial rewrite?

[andrewgazelka]

RFC = Request For Comments

Please respond with your thoughts

This isn't final. I want to hear everybody's thoughts, but a big reason for rewriting is also to combine forces with other people. The current way that I'm doing things, I would not be able to combine forces with any team. However, if we switch things up, we could all combine forces and have a lot of people who are fully committed to this project.

Also, I would suggest looking at the alternatives section. I'm not set on using C++; however, some action does need to be taken so we don't accumulate more and more technical debt. This probably means, at the bare minimum, changing the ECS we are using.

Problems with evenio

• evenio does not have sufficient multi-threading support. Efficient multi-threading support is necessary to do this with vertical scaling.
  • but evenio has events... right? Well the more events there are the more multi-threading tends to not be effective. evenio has entity-level parallelism, but targeted events are sent to one entity at a time, making it so no parallelism will be used for targeted events (usually). This was further enforced in my conversations with @rj00a.
• evenio is probably stopping development. @rj00a is considering working on a new ECS that will be more like flecs in that it will be able to be used in untyped languages but also have strong Rust support

Problems with flecs in Rust

https://discord.com/channels/633826290415435777/1090412095893422101/1242639259974762496

Problems with bevy compared to flecs

It looks like although Bevy, in a lot of cases, performs worse than Flecs from what I can tell, they are working hard to it more like Flecs. So in the future, it might be more reasonable to use Bevy, but the issue still stands where we can't use Bevy outside of Rust, whereas with Flecs, we can use it in C++ and then have C# code use the same ECS system. Now, we don't necessarily need to share the ECS system; we could have a separate API layer, but this is something to consider for sure.

It will most likely perform worse for multi-threaded performance with many entities than flecs.

https://discord.com/channels/633826290415435777/1090412095893422101/1246961984654544946

C/C++/Rust for Game engine, other for game

• For this to be effectively used outside our team, I currently believe we will need to have a language which can be hot reloaded. Say C# or Lua for the actual game.
• Also I believe the language will need to be easy to learn/use for game developers. I currently believe Rust is not a language that allows for rapid prototyping.
• flecs supports C# very well (from my knowledge)

Why C++?

• flecs supports C++ well.

Considerations

• maybe there is some way flecs-rs can work in a sound way? I am not sure if this makes sense / is possible.
• Ideally, especially if this project is open-sourced, I believe Rust is more accessible for writing the game engine. I think Rust would allow for more contributors. However, I do not know how much this would benefit the project. It is my belief that a few dedicated programmers will advance a project a lot more than dozens of semi-dedicated open source contributors.

Alternatives

• use Rust 100% for game engine and game although I am not sure I like this idea. If people demonstrate that using C# will not make their game development times faster, then this could be a consideration.
  • we could use bevy , they seem to be implementing more flecs features
  • we could wait until @rj00a finishes his new ECS, but I do not like the idea of waiting this long and flecs is already stable.
• write C++ 100% using something like entt. I do not think this is a good option as IMO C++ is a little overwhelming, especially to actual game developers.
• keep using evenio for the time being and then do a major refactor later on.

Related

• Rewrite Project valence-rs/valence#599 (comment)
• https://loglog.games/blog/leaving-rust-gamedev/

[TestingPlant]

I currently believe Rust is not a language that allows for rapid prototyping.

I believe that C/C++ are worse for prototyping since it also has a nonzero compilation time and it's also significantly easier to cause UB, especially when writing multithreaded code. There's tools like ubsan and asan, but it's a lot nicer and faster to fix compile time errors like Rust provides. It's also more difficult to add dependencies in C/C++.

For this to be effectively used outside our team, I currently believe we will need to have a language which can be hot reloaded. Say C# or Lua for the actual game.

Should we plan to continue supporting Hyperion after the 10k player event? If it's only for the 10k player event, I don't think it's worth the cost of setting up FFI with another language.

In general, I believe that if we want to rewrite Hyperion, it could possibly be better to avoid ECS since we learn about the pros/cons of a specific ECS system by using it a lot like we've seen with evenio. If we learn that an ECS system we switch to has a major issue, it'd require another rewrite. Some other Minecraft server implementations like Bamboo don't use ECS and use regular structs instead (code here). Doing this would also allow us to adjust how we multithread everything easier. Bamboo also has a method to write your own minigames which we could take inspiration from but I'm not familiar with how it works.

[andrewgazelka]

I currently believe Rust is not a language that allows for rapid prototyping.

I believe that C/C++ are worse for prototyping since it also has a nonzero compilation time and it's also significantly easier to cause UB, especially when writing multithreaded code. There's tools like ubsan and asan, but it's a lot nicer and faster to fix compile time errors like Rust provides. It's also more difficult to add dependencies in C/C++.

For this to be effectively used outside our team, I currently believe we will need to have a language which can be hot reloaded. Say C# or Lua for the actual game.

Should we plan to continue supporting Hyperion after the 10k player event? If it's only for the 10k player event, I don't think it's worth the cost of setting up FFI with another language.

In general, I believe that if we want to rewrite Hyperion, it could possibly be better to avoid ECS since we learn about the pros/cons of a specific ECS system by using it a lot like we've seen with evenio. If we learn that an ECS system we switch to has a major issue, it'd require another rewrite. Some other Minecraft server implementations like Bamboo don't use ECS and use regular structs instead (code here). Doing this would also allow us to adjust how we multithread everything easier. Bamboo also has a method to write your own minigames which we could take inspiration from but I'm not familiar with how it works.

So, I agree, I think C, C++, and Rust are all bad for prototyping. I do think that Rust is easier to use if we have a homogenous codebase with one language. I would go with Rust 100% of the time over C++ just because game developers, I think, can learn Rust a lot easier than they'd be able to learn C++, and you can be more confident that the code will work if you have an inexperienced developer. This issue will affect the long-term development of Hyperion a bit, but then, I mean, we'll get so much coverage and there's a good chance that we can leverage this coverage in a useful way. I've been thinking more and more about this because I really do think that there is a lot of need for these large events where companies, especially if they're mostly virtual, want to have a giant online launch party. I think this is decently popular post-COVID; having something like this would be super useful, and it doesn't really exist. It's nice to have a common, well-known game such as Minecraft to do these things on, so I think we could capitalize on this, especially if we see significant interest. We could have this all without an ECS, and we could have some type of API layer. It's something that I want to explore more concretely. For instance, the way that Bukkit works is without an ECS. I wonder if we could have an API that was somewhat similar to that, or if that would not be a good idea.

We could even support something like a Skript, maybe. 😭

[eduxstad]

Can we add entity level parallelism and modify evenio to be efficient with multiple threads? We'd have to rewrite evenio, but we wouldn't have to rewrite hyperion.

[andrewgazelka]

Can we add entity level parallelism and modify evenio to be efficient with multiple threads? We'd have to rewrite evenio, but we wouldn't have to rewrite hyperion.

I think I found a solution that doesn't require rewriting most of it, but I have been told to not disclose it yet. 😭

[andrewgazelka]

we rewrote :)