join efforts?

[andrewgazelka]

At this point, Valence and Hyperion have remarkably similar goals, yet neither project is attracting the contributors needed to reach their full potential. I'm exploring whether combining our efforts might be mutually beneficial.

What We Share

• Both projects are "nothing included" frameworks in Rust
• Both use ECS architecture with performance and ease of use as a primary goal
• Both aim to provide high-performance Minecraft server implementations

Key Architectural Differences

• Hyperion's architecture is specifically designed to handle thousands of concurrent players. We require a proxy layer (which allows $O(n)$ broadcasts instead of $O(n^2)$ from the game server) - this proxy can now be embedded.
• We use flecs for our ECS implementation while Valence uses Bevy. We will need to decide to unify on one. For me to want to go fully into Flecs Rust I think @Indra-db needs to figure out a way to get more funding/time for https://github.com/Indra-db/Flecs-Rust to fix the existing safety issues. For us, Flecs Rust not being fully safe (in Rust terms) has been a big hurdle for contirbutors.

I've seen excellent performance with flecs and believe strongly in its capabilities. However, I recognize that Bevy has broader adoption in the Rust ecosystem and might bring in more contributors familiar with its patterns.

By pooling our resources, expertise, and codebases, we could create a single, stronger project that benefits from both approaches. Rather than competing for the same limited contributor pool, we could leverage our combined strengths to build something neither team could accomplish alone.

What are your thoughts on this potential merger?

Questions

• which repo/org would this go under? I am somewhat concerned about perms in valence given @rj00a has been AWOL for so long and there is a good chance he will not come back.

[andrewgazelka]

@maxomatic458 @JackCrumpLeys

[JackCrumpLeys]

I have almost no position on this. I'm not sure what Hyperion features can be easily merged into Valence (or vice versa), can you be more clear what you're asking for? By all means make a copy of Valence, I will probably work on it if it becomes the key fork.

[Indra-db]

to fix the existing safety issues.

I'm actively working on it, but was sick for a while

[maxomatic458]

I've seen excellent performance with flecs and believe strongly in its capabilities. However, I recognize that Bevy has broader adoption in the Rust ecosystem and might bring in more contributors familiar with its patterns.

In my opinion makes more sense to use bevy for a project like this, since its actively maintained + purely made in rust.
Also how impactful are current performance drawbacks with bevy and are they actually a problem in realistic environments?

both bevy and flecs are probably fast enough for 95% of use cases, so i believe we should focus on making a server-framework easy to develop with (offering low level and high level apis) instead of mainly focusing on performance.

since bevy is still relatively new, we can probably expect big performance improvements in the future.

[dyc3]

Seems reasonable to me. Given the lack of perms on this repo, it would make the most sense to move to the hyperion repo. RJ never gave me or anyone else full perms to this org or the discord server, so staying here isn't an option long term (unless RJ comes back of course). I won't have much time to contribute engineering, but I'd like to be involved to help manage the project so this doesn't happen again in the future. Perhaps we could discuss details of that in DMs, @andrewgazelka?

To merge successfully, we'll have to make sure we are aligned on project goals, scope, governance, etc.

Valence's scope is:

• No vanilla behavior, (unless notchian clients do state prediction for it). In other words: Users should be able to make a "vanilla" experience with Valence, but users have to implement that themselves.
• Users should be able to build highly customized experiences (eg. hypixel) with relative ease.

---

With regards to flecs vs bevy, I'd have to agree with @maxomatic458. Bevy has treated us well, even with the breaking changes, and its popular. Contributors are more likely going to be familiar with Bevy, it is well documented, and it has a thriving community and ecosystem around it. Considering how fundamental the whole ECS thing is to both projects, I think that is way more important than the potential performance gains, if any are to be had.

In #683, @maciek134 has been hard at work making a new metadata extractor (details in that thread, its pretty cool!). I would hate to see that effort go to waste, so that would be my first candidate for things to be brought over to hyperion.

[Kumpelinus]

I really love Flecs and how flexible it is, but all the random crashes and undefined behavior - without any helpful error logs - are driving me crazy right now. Plus, being able to advertise the server engine as “pure Rust” would probably draw in more people over time, so I’m leaning toward Bevy.

Bevy has also added a lot of the core features it was missing compared to Flecs (proper events, an ECS explorer, and more) since Hyperion started. Those updates make it a much stronger contender.

Just my two cents for now. If we decide to go with Hyperion, we’ll need to settle on a scope that works for both projects. Hyperion covers more ground (it includes commonly used tools in the main repo opt‑in, of course, so you can still build low‑level systems easily), but we should make sure everyone’s on the same page.

[maciek134]

Just FYI, the extractor is currently not bound to any project since I'm at the stage of outputting an intermediate representation of the data - I'll keep an eye on this though so I don't go generating code before this is settled.

I actually looked at Hyperion before deciding to use/work on Valence and it mostly came down to Bevy vs Flecs (tbf, I had experience with Bevy already).

Btw, for the performance-minded, Bevy supports tracing ootb - set up Loki and you get live performance metrics and structured logs. After using that for a couple of years, it's hard to go back when debugging production issues (granted afaik Valence doesn't use it explicitly).

[andrewgazelka]

I have almost no position on this. I'm not sure what Hyperion features can be easily merged into Valence (or vice versa), can you be more clear what you're asking for? By all means make a copy of Valence, I will probably work on it if it becomes the key fork.

@JackCrumpLeys I'd like to have something like valence but has my architecture / optimizations I have done in hyperion that should allow for many many many more players. We already use valence_protocol along with a forks of other valence crates. I think first steps would be:

1. us convert to bevy (started here refactor: bevy hyperion-mc/hyperion#882 )
2. move in valence-* dependencies into the main hyperion repo so they can be centrally managed/maintained

Also how impactful are current performance drawbacks with bevy and are they actually a problem in realistic environments?

@maxomatic458 I think single-threaded I am not too concerned. However, I am concerned about parallelization in bevy as it is not deterministic and low overhead like it is done in flecs. However, this has the potential to change and I feel like it is something they could allow in the future

Perhaps we could discuss details of that in DMs, @andrewgazelka

Yes dm me @dyc3 andrewgazelka

have to make sure we are aligned on project goals, scope, governance, etc.

Agreed. I think we are pretty similar right now. Let's also make sure that if I hit by a bus at least one other person has full admin rights. Also, I want to ideally have a couple events in the hyperion repo so we can make sure that we can design the API well for real world projects. Then when the API becomes stable perhaps we can move htem out.

Bevy supports tracing

@maciek134 all the systems in flecs in Hyperion have tracing enabled too. :)

---

would love to talk more in Discord. https://discord.gg/WKBuTXeBye

[maciek134]

@maciek134 all the systems in flecs in Hyperion have tracing enabled too. :)

Hmm, I found nothing for flecs so I didn't even check Hyperion itself, nice! I guess looking at traces for a similarly-setup server could be a good comparison for anyone wondering about flecs vs Bevy performance.

We already use valence_protocol along with a forks of other valence crates.

That makes my job with the extractor easier then :)

[andrewgazelka]

@maciek134 all the systems in flecs in Hyperion have tracing enabled too. :)

Hmm, I found nothing for flecs so I didn't even check Hyperion itself, nice! I guess looking at traces for a similarly-setup server could be a good comparison for anyone wondering about flecs vs Bevy performance.

We can compare traces after hyperion-mc/hyperion#882 is finished. Flecs handles multi-threading with significantly less overhead than Bevy does - it maintains a constant number of sync points rather than Bevy's variable approach.

The fundamental difference is that flecs leverages row-level parallelism while Bevy uses column-level parallelism. With higher thread counts (say 8 threads), I'm almost certain flecs will demonstrate superior performance. Even if it's only 2× faster though, I'd consider that an acceptable tradeoff given Bevy's other advantages.

Long-term, I'm hoping Bevy will eventually support row-level parallelism as well, which would narrow this performance gap considerably.

[maciek134]

I might be a bit rusty on the terminology, but this is the first time I see row/column-level used in context of multi-threading. Feel free to drop some links (docs/books/etc).

Tbf it's been a while since I cared about multi-threading too, last couple of years has been either just throwing more pods at it or embedded. Next thing I wanted to try after the extractor was a k8s operator to do seamless multi-chunk overlapped sharding - but that was more for redundancy and resource optimization than scaling, so I'm not sure yet whether this is easier with Valence or what Hyperion does.

[andrewgazelka]

I might be a bit rusty on the terminology, but this is the first time I see row/column-level used in context of multi-threading. Feel free to drop some links (docs/books/etc).

Tbf it's been a while since I cared about multi-threading too, last couple of years has been either just throwing more pods at it or embedded. Next thing I wanted to try after the extractor was a k8s operator to do seamless multi-chunk overlapped sharding - but that was more for redundancy and resource optimization than scaling, so I'm not sure yet whether this is easier with Valence or what Hyperion does.

think about postgres / a table.

row level parallelism:
we running the same system but different rows (= entities) are being processed at the same time. This is kind of like what rayon does ... but flecs handles it much better because it actually groups together systems into a "super system" where you need many fewer sync points. It only needs to sync when there is some dependency which will grow cross-entity and cross the parallelization boundary (say an entity attacking another entity).

column level:
we are running multiple systems and querying different columns at the same time.

Think system that looks at Health and system that looks at Name can be run in parallel because no overlap.

[maciek134]

Huh, RDBS was my first thought but I didn't make the row = entity / column = component connection.

To be honest I'd rather switch the runtime to a single thread and parallelize with multiple manually coordinated instances. More control over resource allocation and usage and you could avoid synchronization altogether in some cases by paying the cost of moving the entity between instances (with the extreme case being an instance on another machine).

Though this is getting a bit off topic, thanks for explaining the terminology!

[andrewgazelka]

Huh, RDBS was my first thought but I didn't make the row = entity / column = component connection.

To be honest I'd rather switch the runtime to a single thread and parallelize with multiple manually coordinated instances. More control over resource allocation and usage and you could avoid synchronization altogether in some cases by paying the cost of moving the entity between instances (with the extreme case being an instance on another machine).

Though this is getting a bit off topic, thanks for explaining the terminology!

If you have a good idea on how this can be done with flecs/bevy lmk but this is usually easier said than done in my head.