The elephant in the room

[AmbulantRex]

There comes a time in every project's life for self reflection. A stinky fish must be set upon the table and the proverbial elephant or gorilla in the room must be addressed. I'm referring, of course, to Stride's development and momentum. Here is a snapshot of the past month:

Contrast that with the nearest "competitor", Godot:

So where do the differences come from? Godot has 1881 contributors and Stride only has 87. However, the doesn't really explain all the difference. Assuming that all things were equal, we should see a proportional number of each of these metrics. This would mean that we should see something like 26-27 Merged PRs and 8-9 New PRs. Engagement is low, but why?

The engine itself is impressive and has an immense amount of potential. There is clearly a lot of enthusiasm in the Discord channel and some fairly heroic undertakings have been made within the code this year. So what aren't we doing? What seems to hold us back the most? Why aren't we optimizing for the common case and solving the problems that inhibit contributor throughput? Why are there PRs with green check marks and one line of code open since July? Bug bounties are great but pointless if they can't get merged!

Opinion Time:
I've contributed a little to the project. My changes have not been nearly as impactful as many others but that is for a reason. It isn't for lack of ability, it's that all of my contributions sat frozen in an Open PR for months and in some cases years before being merged! That was just to get it merged, I literally started and finished college in the time from when my code was merged to when it was actually deployed in a release of Stride... I want to contribute to this project so bad, but every time I open the code, I remind myself that any changes I make will likely take months to years to even get into the engine. There aren't any weekly or monthly beta releases so I'll have to wire up some janky local NuGet source stuff just to use my own changes.

So to emphasize my point....we have a real problem here. If nothing changes, nothing will change. What are our major hurdles? Is it CI/CD pipeline in TeamCity? Is it lack of reviewers? If I can see a genuine commitment to improvement of contributor throughput from this project, I will contribute more. I'm confident I'm not the only person who feels this way.

[manio143]

I wouldn't speak for the others, but for me the life just put other things on my plate. I'm happy to take time an review PRs (as I've done here and there the past few months), but I don't have the time to code more then a few days a quarter for Stride, which is nowhere near enough to keep up the momentum of things. I do plan to finish the serializer generator rewrite when a hack week at work comes around next quarter.

Stride could very much use a small team of full time devs to keep up the maintenance on a higher level than we currently have. But for this to happen there needs to be some additional interest from companies who want to use Stride and give back to the community. I know there's been ideas of supporting someone with donations, but the cost of full time maintenance is much higher than donations would permit. I don't think it's something solved easily.

Regarding the open PRs - some of them are around graphics, so only contributors more familiar with graphics can review them - some are open because the person who wrote it didn't come back to address feedback or they didn't go pinging anyone after a while of nothing happening. We should do a review of open PRs and try to close down on things - but again it takes time.

The key thing there may be is the shared responsibility - with Stride being in the hands of the community and the contributors not forming a coherent core team with goals and time to execute on them, the responsibility gets a little lost. It's too much for any one person to take on themselves and without a team putting time into managing the project there's nobody paying attention to every single thing and it falls through.

Last year there was a huge problem with the package deployments. It has been mostly addressed, but we haven't had enough changes to justify frequent releases since. And releasing a few hundred megabytes of new packages with a small change isn't the best idea, unless it's a security fix.

For me Stride still has a future and I will be part of it to some degree. I like the codebase and will contribute to it slowly when I have the time. I will be reviewing others code if I have the knowledge to cover it (so for example I can cover code style and patterns even if the key logic is beyond me). Feel free to "at" me 😄

What would be cool to see is small gamedev teams with high C# skill getting involved in making a game with Stride. A huge amount of bugs and fixes will come up when the project is actively used to make stuff. But people aren't engaged because there's bugs, because there's not enough docs, etc. It's a classic chicken and egg problem and the only way through is for somebody to have the time and put in the effort to change the situation.

[ericwj]

From my experience the first problem is that the build system is too complex. Pretty much any larger change is a massive puzzle and a risk due to that.

• The primary example is how the graphics API support is compiled. They should be side-by-side assemblies and selected at runtime from amongst those that were referenced through NuGet or a project reference. The new static abstract members in interfaces feature in C# should make that possible in the highest performing way.
• Stride should not have its own way e.g. to target Android. Not in .NET 6 and above. Not anymore. Nobody likes figuring that out.
• Stride shouldn't compile C++ as part of C# projects. That is hell for C# developers. Put those projects in their own solution/project/repo. Make them .nugets if needs be.
• Stride.Core shouldn't intrude in the build of any assembly that references it. All reasons for that can be taken away and part of that work has already been done. This relates to animate anything, serialization and the asset pipeline.
• AssemblyProcessor should be made obsolete by replacing all reasons for its existence that still remain.

Imho in the end all of Stride will benefit from the project files becoming much, much simpler and more akin to what dotnet new creates. Only the asset pipeline should require MSBuild foo and that could be entirely distinct from how the rest of Stride builds.

Refactor out components, preferably putting them in their own separate solution/project or even repo. E.g. the shader compiler. It could probably be usable entirely standalone. And the UI. See what breaks if all of the WPF is all by itself instead of where it is now. And whether the same can be done for the projects with the logic that drives the UI.

To get these vital parts moving, I think some knowledgeable people will need to make a comprehensive plan and at the very least chop it up in manageable pieces. Pray that Xen2 and Eideren will lend their insight or even a hand here and there, then create the appropriate issues with checklists or a project board so that the community can relatively safely step in and help without getting overwhelmed and quitting prematurely.

[CeSun]

These are good questions. I think the project is generally made well and modular and if enough documentation is provided it should become much more usable. In my view I usually separate code into core, engine, assets, editor. The core has a lot of cool stuff in it that most people don't know about because it's used by higher layers. The engine is what most people touch and where most performance improvements focus - this is what makes the games run. The assets pipeline is designed in a really cool way, but currently very limited in terms of extending (see #1120) - there's definitely room for making things better here as well. Finally the editor - the heaviest layer which is the most important to many users. It is big and has many abstraction layers which makes it harder to make changes to it. It could potentially use an overhaul the most such, but also this is where having a dev team would be needed most. Honestly, even the editor has been designed very modular and extensible from the code perspective.

Stride has incredible potential. I don't know if there's any part of it that can be dropped as such. By enabling more extensibility we can offload the maintenance burden of some features onto extension creators, who would focus on a smaller problem.

I think adding a GamePlay framework might be a point of differentiation. There are too many engines similar to unity on the market, and it is only suitable for large companies. It is very difficult for an ordinary programmer to develop an online game using unity or godot. But using UE is very simple, maybe you can learn from UE's Gameplay framework. I noticed that Flaxengine is also working on a Gameplay framework.

[skohanowski]

I'm actually coming to recognize that one of the largest hurtles to adoption is monetization for indie developers. Large dev companies are generally going to focus on powerhouse engines that push the state of the art. While Stride is exceptional in quality, it's not actively pushing that art. That leaves indie devs.

Game dev in Stride is clean and easy but there are real hurtles for indie devs to rapidly create a mobile game that generates revenue through ads. That's effectively how Unity exploded into the market. It's ridiculously easy to add revenue generation to a simple game and publish it, then move on to the next game. Unity even has it's own add service now. Search "ads in Godot" and you get a dozen demos. The same is true for publishing a game.

I'm willing to bet that adding good easy documentation and support for ad revenue and publishing will see Stride attract a lot of new indie support.

[skohanowski]

The more I think about it the more I think we need a bounty on demo's for ads and publishing. Preferably multiples of each.

[tagcode]

• The primary example is how the graphics API support is compiled. They should be side-by-side assemblies and selected at runtime from amongst those that were referenced through NuGet or a project reference. The new static abstract members in interfaces feature in C# should make that possible in the highest performing way.
• Stride should not have its own way e.g. to target Android. Not in .NET 6 and above. Not anymore. Nobody likes figuring that out.
• Stride shouldn't compile C++ as part of C# projects. That is hell for C# developers. Put those projects in their own solution/project/repo. Make them .nugets if needs be.
• Stride.Core shouldn't intrude in the build of any assembly that references it. All reasons for that can be taken away and part of that work has already been done. This relates to animate anything, serialization and the asset pipeline.
• AssemblyProcessor should be made obsolete by replacing all reasons for its existence that still remain.

I second all this. Top suggestions here.

The build process is too difficult. It deters new contributors and commits. Approachability sets the whole trajectory angle.

Mess is naturally typical for all code bases that have been around for a long time, due to evolution of framework, dependencies, language, configuration, etc.

When MS transitioned to .NET core, they had to start from scratch and build up from small code base. In the same manner Stride should be broken into smaller repositories.

[tagcode]

Thanks, I'll check Godot out. Looks like .NET 6 support is coming into next release, atleast on some level.

Edit: Ok, I checked it out. There is .NET 7 version of Godot4 😀 Godot 3.5 builds to new and old android devices very nicely, 0 issues.

Stride codebase is such a mess that it's impossible to add anything. It is fragile. It is undeterministic. It has crazy nupkg mechanism. Stride project isn't going forward until it has been completely refactored in an overhaul.

Edit2: I've played with Godot for a day. I'm impressed, .NET 7 works nicely, visual studio debugging, breakpoints. .NET 7 + Android isn't ready yet, but probably later. And Godot codebase has 700x PR / month.

[tagcode]

I would refactor code base so that:

1. Every class library is portable and targets to .NET 7 only.
2. Remove every #if and replace with runtime checks.

#if STRIDE_PLATFORM_ANDROID 

Into

If (Platform.IsAndroid) {  }

3. #if:s for graphics APIs would be replaced with API specific fragment class libraries, e.g. Stride.Graphics.OpenGLES. This requires bit more work.
4. Get rid of the nupkg resolver system. Having asset builder and GameEditor to react to stride version number is nice feature, but it would require ton of hours to maintain which is not available. The complexity of it weighs down the build process.
5. Here is crazy idea. Make build-time asset compilation optional. Allow lazy run-time asset compilation on the first run that writes into .cache directory. This way everything would be absolutely portable and easy to maintain. Single build, run everywhere.

All these add to the development velocity, which is currently in paralysed state due to the build scripts of the solution.

This refactoring could be done by starting from empty solution. Add new project Stide.Core, add classes only, no build scripts. Then Stride.Mathematics, .IO etc. Add all leaf class libraries first, then their dependees. Remove #if defines.

Put library groups into different repositories: Stride.Core, Stride.Runtime, Stride.Editor, Stride.Asset, Stride.Graphics. This is must, because otherwise you will cause cyclomatic complexity.

This game engine has lot to love about and has tonnes of exceptionally good design choices. On many fronts this engine is ahead of others. However, the solution has ballast from .NET framework era past and build scripts needs to be put into bin and be reworked.