New Stride Editor #1031
Replies: 6 comments 13 replies
-
|
Some other discussion about stride UI |
Beta Was this translation helpful? Give feedback.
-
|
It's not a bad idea to have a more structured discussion here, because things can get lost on Discord, so thanks for starting a thread. I think that we need to look at Stride from a few different perspectives. There is already a clear division between the Engine libraries and Assets libraries in the code itself, where the Engine part is shipped with a game and the Assets part is used at design time. When designing (architecturally) a new editor, which would be more extensible and hopefully cross-platform, we want to minimize the changes to the Engine libraries and focus on the design time parts. This shouldn't be particularly hard, because the separation is already there, although some things are connected due to some design limitations (like an attribute on a component which determines order in which it will appear in the UX). We can further divide the Asset libraries into (note: I'm categorizing, in each there's a few projects):
When talking about a new editor we generally think about the user facing applications. The GameStudio is working really well considering the amount of code and cognitive complexity that goes into it. On a few occasions I've had a chance to dive into the source code and most of the time was able to successfully modify the editor how I wanted. However, lack of documentation and guides around such a massive code base make this an exploratory mission each time. Thinking I could rewrite the basic tasks of the editor I created the StrideComponentsEditorAvalonia and after a month of working on it had to take a break, because there's just so many things that go into making a working editor that it is quite hard to complete it in a reasonable amount of time (unless you have a team of full time engineers). So now I'm thinking that maybe it's a better approach to attempt a refactor of the existing code first, before we start spending time with a completely clean slate and a mountain of work up front. And the key part of that would be the extensibility that we so much desire. See, the thing is, Stride was initially developed with some ideas around extensibility. There are parts of the GameStudio which are very much expecting to be extended, but the part where an external DLL file were to be loaded is not there and one of the reasons for that is the design assumes all plugins have to be registered before UI components start being initialized. This actually can drive the design of loading external plugins by including them in some way in the Plugins are important in a scenario when I want to create a custom component with a custom asset. To the end user I would provide 2 NuGet packages:
I think the first problem of contributing such a system (after a lengthy discussion on how to implement it) is lack of knowledge among the contributing community of the current design of the whole system and requires first spending some time to document how different parts of Stride interact with each other. From this documentation we can then highlight spots which should allow extending (if they don't already) and work on those. P.S. Stride already has hot reloading implemented the same way as Flax, but an assumption has been made when writing it, that all asset types are provided by Stride and don't need to be reloaded. Which of course will have to change to make it extensible. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! Maybe what I have presented is too complex in some parts but it can a hint. For the extensibility system presented, I think I will develop it alone as a library. I think it's a pretty good system. It clearly better to work on refactoring our editor. For stride hot reloading, I was speaking about the live preview. |
Beta Was this translation helpful? Give feedback.
-
|
In the light of the upcoming .NET6 and the transition to the .NET Foundation I think we also have to explore the MAUI option in more detail. This would make Stride easier to integrate into new MAUI projects by professional applications because then a Stride MAUI component would exist. |
Beta Was this translation helpful? Give feedback.
-
|
On that note - I had an idea recently that it would be pretty neat to have basic CLI tooling for assets so that you can do something like stride asset add Model --url Person -f ../Resources/Person.fbxAnd it would take care of generating the YAML based |
Beta Was this translation helpful? Give feedback.
-
|
@jasonswearingen VS IDE was something we considered in the early steps but the 32 bit limitations at the time was a huge blocker (unless we made it out of process). @manio143 Great idea! At some point when I wanted to have tooling (asset compiler) work under Linux, this would definitely have been a direction to take. I remember also wanting to add a bunch of stride default projects as dotnet new project templates. |
Beta Was this translation helpful? Give feedback.
-
|
IMO, MAUI is the way to go. MAUI has many means now to do all UI composition in C#, not XAML. MAUI has two add-on projects that have been in development for some time as well:
If we succeed at integrating Maui to Stride in both ways -- it'll open new doors and build momentum here. |
Beta Was this translation helpful? Give feedback.
-
|
Last time I looked around the MAUI team did not guarantee any kind of support on their part for desktop Linux, I don't think it's wise for us to integrate with MAUI as long as this issue is still prevalent. |
Beta Was this translation helpful? Give feedback.
-
|
I guess, currently they are just not resources https://www.reddit.com/r/dotnet/comments/r7fwxj/net_maui_and_the_current_stance_on_linux_support/ and some work is happening by community https://github.com/jsuarezruiz/maui-linux |
Beta Was this translation helpful? Give feedback.
-
|
My others suggestions if possible:
|
Beta Was this translation helpful? Give feedback.
-
|
The basic point of the editor is to manage and create assets and scenes. So for code-only solutions, you could still have designers using the editor to set up assets, while the code would handle when to load them etc. On the "independent" part - there has to be heavy dependence in certain places (custom editor for a certain component usually needs to be updated when the component is), but by making everything very modular and organized around plugins, different parts can evolve somewhat independently of each other. The current editor has modularity at a certain level, but it's not easy to understand where are the boundaries exactly, so it takes time to find the code responsible for the thing I see on the screen. |
Beta Was this translation helpful? Give feedback.
-
|
Luckily, I am not scared of the current editor as it is, whatever time it takes 🤣. Thanks for your view. Always nice to have some another input. |
Beta Was this translation helpful? Give feedback.
-
|
I'm for having some demos making use of stuff created in the editor. It then becomes the "upsell" for the code-only folks, making them realize "there even more you can do if you learn or editor". I just hope that the end result of these code-only samples is that there are zero objective limitations to what you can do with the code-only approach. The Editor should simply make things easier (and in some cases, MUCH easier, like laying out a creative/custom scene). |
Beta Was this translation helpful? Give feedback.
-
|
I propose to make an editor based on Avalonia using NP.UniDock. I also think we need to unify the APIs responsible for changing state in the engine (changing the camera position in the editor, updating the editor, the currently selected object, updating the asset, etc). This would allow easy and simple migration to different frameworks, regardless of their internal structure, and would also help to break deep connections within the engine, thus simplifying the code.
|
Beta Was this translation helpful? Give feedback.
-
|
@KanterVault you forgot the link 🤣!! https://github.com/npolyak/NP.Avalonia.UniDock |
Beta Was this translation helpful? Give feedback.
-
|
The big draw of the 'other' game engine was window layout and extensibility by the users. There should be basically zero rationale about what people are doing in the editor, their workflow and what they need to see at any given time (like if they want two project windows). The entire focus should be maximum flexibility and extension to use it how you want... With a default preference included. The sample is nice, I see it as one big dock, with top and bottom reserved for the editor, that will usually be split into a left, middle, right scenario (unless maybe vertical work?), but even then people may want to split along the bottom like for a console. On top of that each docked window can stack windows as tabs or be made floating per window. I think this is a very modern standard for an editor tool like this. This is the current solution to make the editor extensible right? Custom editor windows being currently unfeasible? Seems like the UniDock API has some great additional features as well. I did a quick comparison search on Avalonia vs Uno and it seems like Avalonia is the better path. Addressing the comment to unify API's for editor state. I'm guessing serialization, drag and drop, undo...? If we can help take on the work of refactoring or expanding specific areas for support of this? For each area that needs work specifically, a little bit of history or explanation of current state and the known limitations we should try to address. Could someone with familiarity layout a bit of a roadmap of areas to target for getting things started? |
Beta Was this translation helpful? Give feedback.
-
|
Looks like the repository is made and maintained by a single dev who is struggling to keep up with Avalonia updates. If Stride was going to use this, community members would probably need to devote some time to help maintain UniDock. |
Beta Was this translation helpful? Give feedback.
-
|
As a docking library alternative, one of Avalonia's longtime contributors (Wieslaw Soltes) is also developing one. On the first glance it seems to offer similar features. https://github.com/wieslawsoltes/Dock Here you can see it in action: |
Beta Was this translation helpful? Give feedback.
-
Before starting. I want to apologize for my English as is not my native language. I also used massively Grammarly
Hope you will understand everything.
New Stride Editor
The purpose of this text is to present, my opinion on how we should create the new editor.
First. What do we want?
We want an editor that helps with creating a stride game.
As normally, we should be able to create a game without the editor #986.
So now, what is painful to do without the editor.
The response is pretty simple: Stride specific files.
What we shouldn't put in the editor.
Scripting in editor.
I think coding inside a game editor is a newbie feature.
Most developers, Already use a full-featured ide (Visual Studio, VS Code, Rider, ...)
For me, scripting in the editor is interesting when you do fast prototyping or When the game engine uses a custom language
or project system (.sln)
Anything that relies on editing non-specific stride files shouldn't be inside the game editor.
Ok cool, we define what we want, now.
Second. How to implement it?
To develop our new editor, we need a UI framework.
so what we have?
UI Framework
HTML based UI
PRO
CONS
C++
C#
So what we have in C#?
This solution uses Xaml, supports all desktop platforms, and can support backend integration in Stride.
So they are the same, except for few things.
Avalonia uses a custom Xaml flavor.
MAUI uses a rendering method that needs more work for backend integration.
They can all work with MVVM libraries.
And they have all the same problem, I think Xaml styling is a lot more complicated than CSS.
To conclude, it to the community to decide what framework to choose.
Extension
I love this part, I passed a lot of time to think how to make the best extension system and I think I arrive at something very promising.
First what core of our editor?
To answer this question we take Visual Studio. What we have when we install visual studio with no workload.
Except for Github windows, any other part of Visual Studio can be extended.
In our case, we want the editor to edit stride projects so we can embed the stride project system.
Now let define the core of this new editor.
Core core components :
Core components (technically these components can be a plugin that will default embed):
UI Extension
Now let's see, how our users will extend UI.
We have 3 options.
First, writing XAML control like in any XAML framework. this option is the most low-level option and allows all possible customization.
Second, an attributes-based UI like Odin plugin in Unity. this option is the most hight level option and doesn't allow customization.
And finally, code that creates UI, like in Unity
These three options can be all implemented at the same time.
Code Reloading and Extension System.
One missing feature of the current editor is a game live preview. Adding code reload with solve partially this problem but I will explain why later.
But before enter to madness let see the current state of assembly unload in .net core
Assembly unload has been implemented from .net core 3.0 with the capabilities from domain unload from .net framework or mono.
Except for one thing. domain unload is forced and AssemblyLoadContext is cooperative. so this puts some constraints on how the plugin should be designed.
Editor plugin.
First, we will talk about the editor plugin. this plugin is load from an editor like visual studio.
The first step is to define a plugin.
The plugin will be represented by two assemblies.
The first assembly will mostly contain POCO and Interfaces and represent data that will transit.
this assembly will allow other plugins to extend your plugin our use it.
And will even allow optional dependencies.
The second assembly contains the logic.
this assembly will expose a class that will implement interfaces from the first assembly to the editor.
For the implementation, the editor will need to find and load a plugin.
I will detail this in another discussion but basically, they will one AssemblyLoadContext by plugins and some nested AssemblyLoadContext.
So AssemblyLoadContext will allow to unload or update plugin at runtime.
To find plugins, we can simply use nuget.org and use some custom tags in nuspec.
That will resolve some problems like the editor version, stride version.
Project plugin.
Project plugins are load from the project itself.
The code will the same that you will use in editor plugins but you will not need to define interfaces as this type of plugin is not intended to be extended.
Now, we have a good vision of the extensibility system. But I want to apologize for not giving any code or image to better explain everything but I will try to complete this documentation if people agree.
Hot Reload
Now let's talk about scripts hot-reload.
Flax engine has written an article on how work they hot-reload.
To summarize, the editor saves game state, unload game assembly, load new game assembly, restore game state.
Technically with AssemblyLoadContext, we can achieve the same. but some game scenarios may not work correctly.
Anything game that uses thread may not support hot reload as Assembly in .net core is cooperative.
AssemblyLoadContext can't force stop thread. any strong reference needs to dispose to allow assembly unload.
Stride changes
For sure, to come to this editor alive, we need to touch stride code.
The only big issue is stride project loading that will need to revamp.
Conclusion
For sure, this documents doesn't cover all on how to create a new editor but I am sure it will be a help
I hope this wasn't too difficult to read.
I also think a new editor shouldn't be a prioritized project as we need to stabilize stride.
Like, resolve issues with no workaround.
Switch binding to silk.net
Finish the transition to .net 5 and 6.
Refactoring extension code of stride.
Beta Was this translation helpful? Give feedback.
All reactions