Bevy VS Unity DOTs

Unity Engine
,
1

The advantage of Bevy is that it is a brand-new engine built entirely for ECS, and it can be iterated quickly without historical baggage. If Bevy can learn Unity’s experience and achievements, understand Unity’s current or past pain points from Unity roadmap, forums and other places, and don’t take the detours that Unity has taken, Bevy may be Unity’s biggest competitor in the future.
I have been using Unity since Unity 4 and I have always believed that Unity is the best commercial game engine. I hope Unity can firmly follow the DOTs route, learn the development results of other excellent ECS engines, and increase investment in DOTs development as much as possible. I can’t wait to fully use ECS.

In the link above, Bevy claims that some aspects have greatly surpassed Unity DOTs. Is this true?

4 Likes
2

They show one feature comparison, which is probably least relevant for most DOTS uses.
You want comparison and draw conclusions, build two similar project render 100k fish with boids, collision avoidance etc., or something shooting en mass, then we can compare what is really better.

Don’t forget, Unity DOTS is much more than just ECS and jobs. Show wort comparison, to be able compete.

3

I’ve used both Bevy and Unity DOTS. Bevy seems much easier to use. It would be nice to see a performance comparison between these.

1 Like
4

Way too early for bevy. I’ve seen most of the blog posts and what not.
It will be interesting to see it’s state in in two years or so from now.

Speed isn’t everything, ease of use also matters. I’m not really interested in DOTS, I like the current system.
I’m not sure how good rust would be for game logic. Feels like it’s not gonna be fun lol.

Honestly though, if they want to get anywhere close in the 3D department (graphical features and else), ecosystem including asset store and tools (animations, editor, builds, terrain) it’s gonna be a while, to catch up to unity especially HDRP and unreal engine.

And while that’s happening, both engines are adding more features. In unity’s department, HDRP is probably the one with the fastest and most active development. Compare to URP for example. Maybe a budget thing.

Although it is interesting for sure, and it’s currently what’s hot in th rust gamedev world.
Problems with projects like this is, if the hype dies down, it’ll go into obscurity. Like some other open source projects.

5

This looks like somebody’s pet project. Meaning the creator is very enthusiastic about it and feels strongly about, but betting your money on it is probably not a good idea.

THe project is only one year old, and most importantly it lacks “showcase” or “games made with this engine” section. Meaning, there’s no track record.

6

Bevy ECS code looks very nice,
Using method directly as query is very nice and clean, wish unity to take all good decisions from bevy ECS to Unity ECS

So instead of this:

public class RotationSpeedSystem_ForEach : SystemBase
{
    // OnUpdate runs on the main thread.
    protected override void OnUpdate()
    {
        float deltaTime = Time.DeltaTime;

        // Schedule job to rotate around up vector
        Entities
            .WithName("RotationSpeedSystem")
            .ForEach((ref Rotation rotation, in RotationSpeed rotationSpeed) =>
            {
                rotation.Value = math.mul(
                    math.normalize(rotation.Value),
                    quaternion.AxisAngle(math.up(), rotationSpeed.RadiansPerSecond * deltaTime));
            })
            .ScheduleParallel();
    }
}

we can write this:

public partial struct RotationSpeedSystem : ISystemBase
{
    //generating actual UpdateMethod with job struct that use this method as core logic and provide deltaTime is responsibility of C# Source Generators
 
    [UpdateBefore(...), After(...), WithoutComponent(...)]
    [BurstCompile, Query] static void RotationSpeedSystem( [DeltaTime]float deltaTime, ref Rotation rotation, in RotationSpeed rotationSpeed )
    {
        rotation.Value = math.mul(
                math.normalize(rotation.Value),
                quaternion.AxisAngle(math.up(), rotationSpeed.RadiansPerSecond * deltaTime));
    }
}

After this unity ecs will be as simple to write as MonoBehaviours :slight_smile:
They already do something with source generator and I wish that their api to be as simple as this or even better, because most of the systems really very simple

3 Likes
7

Looks like I have already love SourceGenerators

[ImplicitCastValue]
public partial struct Rotation : IComponentData
{
    private Single _value;
}

//     \/  \/  \/  \/

public partial struct Rotation : IComponentData
{
    private Single _value;
   
    public static implicit operator Single(Rotation v) => v._value;
    public static implicit operator Rotation(Single v) => new Rotation{ _value = v};
}

Amazing thing is that we can implement this on top of current entities even if unity dont want to :slight_smile:

8

You are aware Entities is being rewritten with SourceGenerators right?

1 Like
9

Yeah
There was many messages from Unity Devs about using SourceGenerators for ECS.

As I understand ECS rewrite with source generators was one of major reasons why Unity add C#9 compiler into Unity 2021.2 while not C#9 itself.

https://discussions.unity.com/t/790289/34

1 Like
10

How this is any cleaner/simpler than other?
Also, both examples are not equal.

11

It “was” a pet project, but there is a real and active community around it now. Honestly I’m kinda jealous. :stuck_out_tongue: We’ll see where it goes.

I can give a little bit of insight on this since I got asked this by a couple of different people and did a little digging.
So first off, for the particular callout to DOTS, yes and no. This is ultimately a tradeoff. DOTS uses change version numbers per chunk. Bevy uses change version numbers per element. The latter consumes more read and write bandwidth even when you don’t need change detection. But it is really convenient when you do.

There are other aspects where Bevy may be ahead, and where Bevy is behind. It is important to recognize that DOTS came first and innovated a lot in this space. Bevy was able to look at what DOTS as well as other ECS solutions and take all the best parts. There’s even a term or two in there that looks familiar on a personal level.

Anyways, it is nice to see another player prioritizing both performance and good API design. Competition is good and will hopefully also push DOTS to be better.

5 Likes
12

Code without comments and other things:

this:

public class MovementsSystem : SystemBase
{
    protected override void OnUpdate( )
    {
        float deltaTime = Time.DeltaTime;

        Entities
            .WithName("RotateWithSpeedJob")
            .ForEach((ref Rotation rotation, in RotationSpeed rotationSpeed) =>
            {
                rotation.Value = math.mul(
                    math.normalize(rotation.Value),
                    quaternion.AxisAngle(math.up(), rotationSpeed.RadiansPerSecond * deltaTime));
            })
            .ScheduleParallel();
    }
}

vs this:

public partial class MovementsSystem: SystemBase
{
    [Job] static void RotateWithSpeedJob([DeltaTime]float deltaTime, ref Rotation rotation, in RotationSpeed rotationSpeed )
    {
        rotation.Value = math.mul(
            math.normalize(rotation.Value),
            quaternion.AxisAngle(math.up(), rotationSpeed.RadiansPerSecond * deltaTime));
    }
}

Second version have simple update methods that receive data that it needs, I see it as Zero boilerplate code for job that it do.

Can you clarify why they not equal?

2 Likes
13

Unity very well knows that unless they can make DOTS as sweet and simple as the smallest mono components, they’ve quite a battle on their hands to get adoption. I’m liking the second simpler, comforting coding style. I love performance I don’t have to think too hard about.

9 Likes
14

Yeah little shorter, but not really deal breaker. Isn’t it?
For sure is much better than writing IJobs :wink:
The question is, how would you apply ScheduleParallel, Schedule and Run equivalent?
I assume will be addition to decoration kewyord?
Like for example:

[Job] [Schedule] static void RotateWithSpeedJob([DeltaTime]float deltaTime, ref Rotation rotation, in RotationSpeed rotationSpeed)

The last question, how manual dependencies can be are delt?
Something like that?

JobHandle dependency = [Job] static void RotateWithSpeedJob(..., dependency)

That would cover major variations of things.
How ECB equivalent is handled?
Or how we can create entities?
You know, these all quirks with ECBs and EntityManager, when handling entities …

15

Glad to see a lot of people discussing bevy. Many features that you are discussing are because bevy are writing in Rust with powerful macro for codegen and a lot of language features that HPC# does not provide, and bevy does not have to deal with multiple compiling backend: Burst and mono.

Honestly, Unity DOTS is hitting the limit of C#. There are too many complains about writing HPC#: memory management, no easy polymorphism, C# language-level limitations, and bad eco-system(hard to connect to library from .NET and hard to connect to native plugins). If it was not because of what we have developed in C#, we will probably replace Unity DOTS with a few pinvoke, using use C# as a glue code and Unity as a renderer. At that point, Unity has no competitive advantages comparing to Unreal for us.

With all that being complained, I appreciated the effort from DOTS team to make it work in C#, and I can see them overcoming a lot of challenges. But at the end of the day, I question C# is a right decision for DOTS due to low ceilings at language-level.

5 Likes
16

Unity il2cpp is actually pretty close performance to c++, and you get that while using C#.
Burst and jobs is one of the greatest things to come from unity.

I’m personally not into dots, although I see it’s pros and the great things you can do with it.
Same things with unreal, you get nice performance, but programming in there to me personally, is just not fun.

I feel like bevy and rust would be similar to how things are in unreal, somewhat.
Although I’m not very knowledgeable in ECS so I can’t really comment on the details of of Dots and bevy’s ECS.

Unity’s API’s and C# is just too good. And now we have il2cpp/burst/jobs.

1 Like
17

I thought I read somewhere that Bevy doesn’t use macros, and that’s partly why it is as popular as it is.

A lot of this is because people are coming at this from the wrong viewpoint. Instead of thinking of it as a stripped-down C#, think of it as a beefed up C. It is C with generics, interfaces, encapsulation, properties, and a few other niceties.

I will agree that Unity was hitting the limits of C#, but I think those limits are going to expand fast once source generators land. We’ll have to see how Unity implements it and how customizable it is.

1 Like
18

How valuable is the programming framework to you? Are you willing to live without or have to build the other major features of a game engine yourself? Because looking through what Bevy offers shows it’s nowhere near Unity, and if Godot’s seven plus years are any indication it will never be.

19

Any ECS can surface an idealised abstraction of itself for extreme ease of conceptualisation and usage AND provide lower level access, too.

Not sure why the abstractions aren’t ever very high, nor usefully abstract and considerate of ease of conceptualisation and usage.

This isn’t something difficult to parse, nor to create a simply grammatical structure of and around, with a set of minimal rules that both guide and teach, whilst absolutely empowering.

All can be made highly readable, so much so that visual coding’s clunkiness can be done away with - in the native form of the paradigm:

System – Component(s) - EntityGroup(s)

eg.

Treatment for Pimples on FacialSkin:
apply AcmeClear morning and night

20

I’ve heard this one before.

Didn’t buy it back then, don’t buy it now.

Track record is more important than community, and there is no “games made with this engine” section. Even godot and ogre had one. From my experience, an engine backed by an actual company is going to develop much faster than a community driven one.

Basically, it doesn’t matter if there is community, if it is enthusiastic, or if it is active.

What matters is results and track record.

We had common lisp which had the most powerful code generation facilities forever. You can write code that writes code that writes code and that’s part of the language spec. It also allowed coding in functional style, meaning, no side effects which is great for multithreading.

Now the question is, why is nobody using Lisp for this stuff?

1 Like