6 ms·

Stride – Open-source C# Game Engine

132 points by pabs3 4y ago

college_physics 4y ago
the sponsors link is missing. [0] you probably don't want that :-) [0] https://www.stride3d.net/sponsors https://www.stride3d.net/sponsors
- div72 4y ago
  Seems like a typo, dropping the s at the end works.
bob1029 4y ago
I am curious if this is actually using the official .NET6+ runtime and how gen2 collections are managed. GC can become a monster problem once you start scaling up the # of things in a system like this.
- szundi 4y ago
  Exactly, gc pauses kind of bugging me in a lot of games based on .net, like Kerbal
  - kevingadd 4y ago
    Generally speaking if a .NET game has GC pauses, it's probably because they didn't try. You can represent most game state using structs and arrays without significant ergonomics problems, and your GCs for the classes you do heap allocate will be much shorter if you design your data structures to be quick to trace. Things were different for Unity games using the Boehm collector though, since it's a conservative non-generational collector that as a result is very slow to collect and collects more frequently. That's why you saw a lot of frequent pauses in Unity games (my understanding is they no longer use Boehm). The game I'm currently working on GCs maybe 1-2 times per minute and the pauses are short enough that it doesn't drop frames, despite the fact that it frequently allocates strings and uses 'async Task' extensively. If you tune the collector settings you can control this even more, and you also have the option to manually force GCs to happen while the game is waiting for vsync, which hides them further. Visual Studio has a built in allocation profiler that can help if you're looking to optimize your games for fewer GCs, and to make tracing faster what you want to do is avoid having any reference types in your struct arrays (use handles instead), which will let the GC skip tracing your big arrays of structs entirely. So for example the big tables of draw calls I use refer to textures by numeric handle instead of reference, which means I can have a 50mb table without making GCs slower. Using handles instead of references also means that copying the struct doesn't require write barriers, which will boost your overall perf a bit.
  - pjmlp 4y ago
    Not all .NET games are made equal. First of all, there is the runtime they are actually using. Then the language version. Finally, how well the devs know how to do low level optimisations.
    - omnicognate 4y ago
      Unfortunately you mostly don't do low-level optimisations in C#. You can manipulate raw memory but unsafe C# is horrifyingly unsafe - far more dangerous than writing C - and code written with it has to navigate a minefield to interact safely with ordinary C#. Instead, heavy optimisation in C# is usually "high level but knowing the runtime in great detail" optimisation. Stuff like knowing the hairy details of the GC implementation (eg by reading Pro .NET Memory Management and/or the single 30,000 line C++ file that contains the GC implementation [1]) and using this knowledge to write ordinary C# code in such a way that the GC can handle its usage patterns very efficiently, or doing things like object pooling that try to cut the GC out of the picture altogether. Essentially, it's knowing what you want the machine to do and figuring out a way to trick the runtime into doing that instead of what it wants to do. I find it massively frustrating and after doing it for a few years I moved back to languages that try to do what you tell them to do instead of the other way round. Some people seem to thrive on it, though, and manage to get impressive results - see, eg. Marc Gravell's blog. [1] https://github.com/dotnet/runtime/blob/main/src/coreclr/gc/gc.cpp?raw=true https://github.com/dotnet/runtime/blob/main/src/coreclr/gc/g...
      - bob1029 4y ago
        I agree that understanding how the GC was built is very important. Little nuances like forcing workstation mode and explicitly calling GC.Collect can make all the difference. You can get very far with a GC language like this. The part that bothers me are the built-ins that allocate. TPL, AspNetCore, et. al. If I want a truly zero-alloc C# solution, I have to go all the way to the bottom with abstractions like Socket, NetworkStream, SslStream, etc.
      - pjmlp 4y ago
        I advise to update yourself what using C#11 offers in possibilities beyond only unsafe code blocks. Based on my C and C++ years, it is hardly any difference from doing optimization, knowing what the compiler actually generates, how is the runtime and standard library actually implemented, and above all getting to use the proper data structures, algorithms and a profiler.
- tebjan 4y ago
  Stride is written in C#, uses the official .NET6 and was developed by world-class engineers. It takes this topic very serious. The game loop has almost zero allocations. It's a very good learning source for writing high performance C# for real-time applications. As a Stride user you have to follow similar guide lines in your scripts to avoid pressure on the garbage collector. But that's not so difficult as soon as you get the hang of it.
- alkonaut 4y ago
  Not sure how this works under the hood but if I made a game in .NET I'd basically have a ban on any per-frame allocations. That means you have to be quite non-idiomatic when it comes so C# within the game loop, e.g. no dynamic collections (resizing will allocate), no "foreach" risks allocating enumerators. There are very few "zerp cost abstractions" in C# so when you want zero cost, you must also avoid some abstractions. Basically you use a very C-looking subset of C# for the parts of the code that run in the game loop. Allocate everything up front, use pools and arenas, etc. etc. It's easy to trip up but tooling is good so it's easy to notice when you accidentally introduced allocation. The engine isn't the problem, it's that when you expose C# as your scripting language then users might think they can write "normal" C# in their game scripts. Which you probably don't want to do.
  - bob1029 4y ago
    > I'd basically have a ban on any per-frame allocations. I have a prototype where I intentionally invoke GC after every frame. My reasoning is that some amount of GC will eventually need to occur, so why not do it as frequently as possible and at the exact moment where we can compensate with other measures, such as the frame scheduler & time step abstractions. Even with heavy allocation (i.e. deserializing the scene graph from a wire protocol before every frame), this approach seems to keep GC pauses bounded to ~1-5 milliseconds in my implementations. If I did not explicitly call GC when I thought best, the runtime would decide to run a 100-1000 ms collection at its convenience and the entire experience would become worthless to human perception.
    - kevingadd 4y ago
      This is a great strategy as long as you can keep the pause times low enough - especially if you manage to hide the gc behind vertical sync. Getting the exact timing for that is a little tricky, but if your game is running fast enough you've probably got upwards of 5ms waiting to be used while your main thread blocks inside Present/SwapBuffers. (Because those functions are native OS APIs, there won't be managed code on the stack and the GC should be able to run.)
    - starburst 4y ago
- Kukumber 4y ago
  not just the GC, but also the JIT is a problem .NET platform is server focused, it does a lot at runtime, including recompiling bunch of functions It was a huge problem before Unity had the IL2CPP target, you had to deal with the slow cold start and you also had to manually call your hot functions to avoid getting them recompiled during gameplay, wich would cause ton of micro-stutters Hence people prefer languages like LUA for their scripting needs, even for Unity [1], great perf for interpreted and you can ship it on consoles/mobile platform that forbid JIT Now that .net has a dedicated AOT compiler, things could improve, but i doubt this engine supports NativeAOT [1] - https://github.com/Tencent/xLua https://github.com/Tencent/xLua
- ykafia 4y ago
  Official runtime yes. For having worked with the source, I can safely say it has been written to not stress the GC too much. But it's a very modular engine, you can change parts of it to better accommodate your needs, I'm currently finishing implementing my "no-allocation" ECS library and will 100% try to integrate it into my fork.
rcarmo 4y ago
This is interesting. Anyone have a feature comparison with other engines? Examples of published games for non-PC platforms?
softsound 4y ago
It looks like a cool project very early in development, I'd almost consider using it over Unity but it seems like too much work and too buggy right now but I hope the main dev's are able to get together and figure out the rough points. I know it's a community project but there are always some champions helping direct everything.
- flohofwoe 4y ago
  It should be a mature engine because it's been around quite a while, just under different names. (see: https://www.stride3d.net/blog/xenko-has-been-renamed-to-stride/ https://www.stride3d.net/blog/xenko-has-been-renamed-to-stri...)
raydiatian 4y ago
As somebody with C# scar tissue, I feel like one C# game engine is already too many. But, then again, I haven't touched C# since the advent of Maui & the lessened relevance of .NET Framework in favor of .NET standard. Maybe things have gotten better.
- oaiey 4y ago
  There are a surprising numbers of .NET game engines. Ranging from Unity, over Gadot to things like this one here. .NET is nowadays a very different beast that the .NET Framework. Maui is not the relevant factor. The modernization of the runtime, portability and the language itself changed it lot. Give it another try. You will be surprised. But do not start with Maui :)
  - flohofwoe 4y ago
    C# is only one of several scripting options in Godot: https://docs.godotengine.org/en/stable/tutorials/scripting/index.html https://docs.godotengine.org/en/stable/tutorials/scripting/i... And both Unity and Godot only use C# on the surface, under the hood it's mostly C++ (although apparently in Unity this has started and parts are being rewritten in their low level C# dialect using the Burst compiler).
    - whizzter 4y ago
      IIRC the lowlevel stuff isn't exclusive to Unity's Burst compiler but rather enabled by the Span<T>/Memory<T>+stack-allocs introduced in the C# language (they might've used it more aggressivly though but shouldn't be anything stopping as aggressive compilation with the mainline corert-tool).
    - szundi 4y ago
      Enough to have gc pauses though
    - jayd16 4y ago
      To be honest, what difference does it make? The scripting tier needs to perform well enough too.
flohofwoe 4y ago
Formerly known as Xenko and Paradox, not sure how long they've been around but at least since before 2014.
th3h4mm3r 4y ago
Linux support?
- pjmlp 4y ago
  No need, just let Valve do the work. Apparently it going great.
hyperific 4y ago
Why all the name changes?
- deleted 4y ago
  [deleted]
- ensignavenger 4y ago
  Apparently the community did not own the trademark on the last name- https://www.stride3d.net/blog/xenko-has-been-renamed-to-stride/ https://www.stride3d.net/blog/xenko-has-been-renamed-to-stri...
- ykafia 4y ago
  the engine wa first created as paradox by the company Silicon Studios (they worked on some games and some middle ware for post effects for other renderers) Then it has been renamed as xenko for some reason. Once it has been open sourced in 2018, we wanted to make it part of the .NET foundation but we didn't have the trademark rights for it. Or more like, Silicon Studios was taking a lot of time answering to give us the trademark. We voted to change the name and allowing us to be part of the foundation.
bratsche 4y ago
It says cross-platform: Windows Desktop, Windows Universal, iOS, Android, Xbox One. Does anyone know if it supports Mac?
- tebjan 4y ago
  The editor is windows only, but you can export for all these platforms, including osx. A Stride project is just a normal visual studio solution, so you can build the solution on other platforms too, if you don't use the asset compiler, which is also a windows only application.
bj-rn 4y ago
There is a fairly recent On .Net Live episode giving a nice introduction of Stride: https://www.youtube.com/watch?v=J6g5y8m26zs https://www.youtube.com/watch?v=J6g5y8m26zs
patser 4y ago
[flagged]
joreg 4y ago
We're using it as render engine for our visual live-programming environment vvvv: https://visualprogramming.net https://visualprogramming.net It allows you to play around with the engine fairly quickly. To get an impression, here is an intro tutorial that shows it in action: https://youtu.be/Cs60A_pSIy0 https://youtu.be/Cs60A_pSIy0 Also check out FUSE which builds on top of vvvv/stride: https://www.thefuselab.io/ https://www.thefuselab.io/
- bmitc 4y ago
  Do you have any pointers to calling Stride as a library if you have a GL context?
  - joreg 4y ago
    I'm afraid not. I can only suggest to ask such questions in to the community: https://www.stride3d.net/community/ https://www.stride3d.net/community/

132 points by pabs3 4y ago

the sponsors link is missing. [0] you probably don't want that :-) [0] https://www.stride3d.net/sponsors https://www.stride3d.net/sponsors

div72 4y ago
Seems like a typo, dropping the s at the end works.

bob1029 4y ago

I am curious if this is actually using the official .NET6+ runtime and how gen2 collections are managed. GC can become a monster problem once you start scaling up the # of things in a system like this.

szundi 4y ago
Exactly, gc pauses kind of bugging me in a lot of games based on .net, like Kerbal
- kevingadd 4y ago
  Generally speaking if a .NET game has GC pauses, it's probably because they didn't try. You can represent most game state using structs and arrays without significant ergonomics problems, and your GCs for the classes you do heap allocate will be much shorter if you design your data structures to be quick to trace. Things were different for Unity games using the Boehm collector though, since it's a conservative non-generational collector that as a result is very slow to collect and collects more frequently. That's why you saw a lot of frequent pauses in Unity games (my understanding is they no longer use Boehm). The game I'm currently working on GCs maybe 1-2 times per minute and the pauses are short enough that it doesn't drop frames, despite the fact that it frequently allocates strings and uses 'async Task' extensively. If you tune the collector settings you can control this even more, and you also have the option to manually force GCs to happen while the game is waiting for vsync, which hides them further. Visual Studio has a built in allocation profiler that can help if you're looking to optimize your games for fewer GCs, and to make tracing faster what you want to do is avoid having any reference types in your struct arrays (use handles instead), which will let the GC skip tracing your big arrays of structs entirely. So for example the big tables of draw calls I use refer to textures by numeric handle instead of reference, which means I can have a 50mb table without making GCs slower. Using handles instead of references also means that copying the struct doesn't require write barriers, which will boost your overall perf a bit.
- pjmlp 4y ago
  Not all .NET games are made equal. First of all, there is the runtime they are actually using. Then the language version. Finally, how well the devs know how to do low level optimisations.
  - omnicognate 4y ago
    Unfortunately you mostly don't do low-level optimisations in C#. You can manipulate raw memory but unsafe C# is horrifyingly unsafe - far more dangerous than writing C - and code written with it has to navigate a minefield to interact safely with ordinary C#. Instead, heavy optimisation in C# is usually "high level but knowing the runtime in great detail" optimisation. Stuff like knowing the hairy details of the GC implementation (eg by reading Pro .NET Memory Management and/or the single 30,000 line C++ file that contains the GC implementation [1]) and using this knowledge to write ordinary C# code in such a way that the GC can handle its usage patterns very efficiently, or doing things like object pooling that try to cut the GC out of the picture altogether. Essentially, it's knowing what you want the machine to do and figuring out a way to trick the runtime into doing that instead of what it wants to do. I find it massively frustrating and after doing it for a few years I moved back to languages that try to do what you tell them to do instead of the other way round. Some people seem to thrive on it, though, and manage to get impressive results - see, eg. Marc Gravell's blog. [1] https://github.com/dotnet/runtime/blob/main/src/coreclr/gc/gc.cpp?raw=true https://github.com/dotnet/runtime/blob/main/src/coreclr/gc/g...
    - bob1029 4y ago
      I agree that understanding how the GC was built is very important. Little nuances like forcing workstation mode and explicitly calling GC.Collect can make all the difference. You can get very far with a GC language like this. The part that bothers me are the built-ins that allocate. TPL, AspNetCore, et. al. If I want a truly zero-alloc C# solution, I have to go all the way to the bottom with abstractions like Socket, NetworkStream, SslStream, etc.
    - pjmlp 4y ago
      I advise to update yourself what using C#11 offers in possibilities beyond only unsafe code blocks. Based on my C and C++ years, it is hardly any difference from doing optimization, knowing what the compiler actually generates, how is the runtime and standard library actually implemented, and above all getting to use the proper data structures, algorithms and a profiler.
tebjan 4y ago
Stride is written in C#, uses the official .NET6 and was developed by world-class engineers. It takes this topic very serious. The game loop has almost zero allocations. It's a very good learning source for writing high performance C# for real-time applications. As a Stride user you have to follow similar guide lines in your scripts to avoid pressure on the garbage collector. But that's not so difficult as soon as you get the hang of it.
alkonaut 4y ago
Not sure how this works under the hood but if I made a game in .NET I'd basically have a ban on any per-frame allocations. That means you have to be quite non-idiomatic when it comes so C# within the game loop, e.g. no dynamic collections (resizing will allocate), no "foreach" risks allocating enumerators. There are very few "zerp cost abstractions" in C# so when you want zero cost, you must also avoid some abstractions. Basically you use a very C-looking subset of C# for the parts of the code that run in the game loop. Allocate everything up front, use pools and arenas, etc. etc. It's easy to trip up but tooling is good so it's easy to notice when you accidentally introduced allocation. The engine isn't the problem, it's that when you expose C# as your scripting language then users might think they can write "normal" C# in their game scripts. Which you probably don't want to do.
- bob1029 4y ago
  > I'd basically have a ban on any per-frame allocations. I have a prototype where I intentionally invoke GC after every frame. My reasoning is that some amount of GC will eventually need to occur, so why not do it as frequently as possible and at the exact moment where we can compensate with other measures, such as the frame scheduler & time step abstractions. Even with heavy allocation (i.e. deserializing the scene graph from a wire protocol before every frame), this approach seems to keep GC pauses bounded to ~1-5 milliseconds in my implementations. If I did not explicitly call GC when I thought best, the runtime would decide to run a 100-1000 ms collection at its convenience and the entire experience would become worthless to human perception.
  - kevingadd 4y ago
    This is a great strategy as long as you can keep the pause times low enough - especially if you manage to hide the gc behind vertical sync. Getting the exact timing for that is a little tricky, but if your game is running fast enough you've probably got upwards of 5ms waiting to be used while your main thread blocks inside Present/SwapBuffers. (Because those functions are native OS APIs, there won't be managed code on the stack and the GC should be able to run.)
  - starburst 4y ago
Kukumber 4y ago
not just the GC, but also the JIT is a problem .NET platform is server focused, it does a lot at runtime, including recompiling bunch of functions It was a huge problem before Unity had the IL2CPP target, you had to deal with the slow cold start and you also had to manually call your hot functions to avoid getting them recompiled during gameplay, wich would cause ton of micro-stutters Hence people prefer languages like LUA for their scripting needs, even for Unity [1], great perf for interpreted and you can ship it on consoles/mobile platform that forbid JIT Now that .net has a dedicated AOT compiler, things could improve, but i doubt this engine supports NativeAOT [1] - https://github.com/Tencent/xLua https://github.com/Tencent/xLua
ykafia 4y ago
Official runtime yes. For having worked with the source, I can safely say it has been written to not stress the GC too much. But it's a very modular engine, you can change parts of it to better accommodate your needs, I'm currently finishing implementing my "no-allocation" ECS library and will 100% try to integrate it into my fork.

rcarmo 4y ago

This is interesting. Anyone have a feature comparison with other engines? Examples of published games for non-PC platforms?

softsound 4y ago

It looks like a cool project very early in development, I'd almost consider using it over Unity but it seems like too much work and too buggy right now but I hope the main dev's are able to get together and figure out the rough points. I know it's a community project but there are always some champions helping direct everything.

flohofwoe 4y ago
It should be a mature engine because it's been around quite a while, just under different names. (see: https://www.stride3d.net/blog/xenko-has-been-renamed-to-stride/ https://www.stride3d.net/blog/xenko-has-been-renamed-to-stri...)

raydiatian 4y ago

As somebody with C# scar tissue, I feel like one C# game engine is already too many. But, then again, I haven't touched C# since the advent of Maui & the lessened relevance of .NET Framework in favor of .NET standard. Maybe things have gotten better.

oaiey 4y ago
There are a surprising numbers of .NET game engines. Ranging from Unity, over Gadot to things like this one here. .NET is nowadays a very different beast that the .NET Framework. Maui is not the relevant factor. The modernization of the runtime, portability and the language itself changed it lot. Give it another try. You will be surprised. But do not start with Maui :)
- flohofwoe 4y ago
  C# is only one of several scripting options in Godot: https://docs.godotengine.org/en/stable/tutorials/scripting/index.html https://docs.godotengine.org/en/stable/tutorials/scripting/i... And both Unity and Godot only use C# on the surface, under the hood it's mostly C++ (although apparently in Unity this has started and parts are being rewritten in their low level C# dialect using the Burst compiler).
  - whizzter 4y ago
    IIRC the lowlevel stuff isn't exclusive to Unity's Burst compiler but rather enabled by the Span<T>/Memory<T>+stack-allocs introduced in the C# language (they might've used it more aggressivly though but shouldn't be anything stopping as aggressive compilation with the mainline corert-tool).
  - szundi 4y ago
    Enough to have gc pauses though
  - jayd16 4y ago
    To be honest, what difference does it make? The scripting tier needs to perform well enough too.

flohofwoe 4y ago

Formerly known as Xenko and Paradox, not sure how long they've been around but at least since before 2014.

th3h4mm3r 4y ago

Linux support?

pjmlp 4y ago
No need, just let Valve do the work. Apparently it going great.

hyperific 4y ago

Why all the name changes?

deleted 4y ago
[deleted]
ensignavenger 4y ago
Apparently the community did not own the trademark on the last name- https://www.stride3d.net/blog/xenko-has-been-renamed-to-stride/ https://www.stride3d.net/blog/xenko-has-been-renamed-to-stri...
ykafia 4y ago
the engine wa first created as paradox by the company Silicon Studios (they worked on some games and some middle ware for post effects for other renderers) Then it has been renamed as xenko for some reason. Once it has been open sourced in 2018, we wanted to make it part of the .NET foundation but we didn't have the trademark rights for it. Or more like, Silicon Studios was taking a lot of time answering to give us the trademark. We voted to change the name and allowing us to be part of the foundation.

bratsche 4y ago

It says cross-platform: Windows Desktop, Windows Universal, iOS, Android, Xbox One. Does anyone know if it supports Mac?

tebjan 4y ago
The editor is windows only, but you can export for all these platforms, including osx. A Stride project is just a normal visual studio solution, so you can build the solution on other platforms too, if you don't use the asset compiler, which is also a windows only application.

bj-rn 4y ago

There is a fairly recent On .Net Live episode giving a nice introduction of Stride: https://www.youtube.com/watch?v=J6g5y8m26zs https://www.youtube.com/watch?v=J6g5y8m26zs

patser 4y ago

[flagged]

joreg 4y ago

We're using it as render engine for our visual live-programming environment vvvv: https://visualprogramming.net https://visualprogramming.net It allows you to play around with the engine fairly quickly. To get an impression, here is an intro tutorial that shows it in action: https://youtu.be/Cs60A_pSIy0 https://youtu.be/Cs60A_pSIy0 Also check out FUSE which builds on top of vvvv/stride: https://www.thefuselab.io/ https://www.thefuselab.io/

bmitc 4y ago
Do you have any pointers to calling Stride as a library if you have a GL context?
- joreg 4y ago
  I'm afraid not. I can only suggest to ask such questions in to the community: https://www.stride3d.net/community/ https://www.stride3d.net/community/