stride3d / stride

Stride (formerly Xenko), a free and open-source cross-platform C# game engine.
https://stride3d.net
MIT License
6.62k stars 955 forks source link

Modify the concept of code assets in the editor #1621

Open manio143 opened 1 year ago

manio143 commented 1 year ago

Is your feature request related to a problem? Please describe. Currently the editor iterates over all folders in a project to find C# source files and shows them under a Code folder in the project tree. Selecting that folder allows the user to browse files in the asset browser. The ScriptEditor is used to edit those c# files within the GameStudio.

One of caveats of this approach is that it focuses on source files as assets, when in many cases those files do not hold entities usable in the editor, other than for the purpose of text editing.

We've had issues (mostly around syntax highlighting) with the built in script editor before and while RoslynPad provides good usability it's not the same as using a fully fledged IDE. In my opion with Stride targeting C# developers it is often to be expected that the user would have VS/Rider installed and for those that don't we can encourage use of VS Code. Preferring use of external code editor means Stride has a smaller maintenance burden in this aspect.

Then there's the case of usability of code based assets. At the moment the primary engine entity extracted from code files is a ScriptComponent. There was recently a fix made to the drag-and-drop functionality of dragging a source file asset onto an entity in the scene to add the script component. From what I've seen there's an assumption made there that one C# file holds one script. It also missed the opportunity of allowing dragging over other types deriving from EntityComponent.

Describe the solution you'd like If we were to leave larger code editing to an IDE, we can still keep the script editor for making minor single file scoped changes. Those changes should focus on the code usable in the editor.

I propose dropping the source file view of code assets and transition to a component view where we extract usable types from the source files and present them in the asset view (keeping the source file chierarchy).

Editing a component (double clicking) would still open script editor as the file association would stay there.

There may be a bit to figure out how deleting the component from a source file is treated or how opening two components from one file should not open multiple editors.

Additional context The asset structure in the asset browser

Code
    MyFolder
        MyScript.cs
        MyMultiScript.cs
    MyModel.cs
    MyEntityComponent.cs

Would become

Components
    MyFolder
        MyScript
        MyMulti1
        MyMulti2
    MyEntityComponent
Doprez commented 1 year ago

Would this mean that instead of having the code editor, Scripts would be treated similar to Scriptable Objects in unity? Where you would just have a serialized asset where you could easily modiy the base values of script properties?

manio143 commented 1 year ago

@Doprez No, here I'm talking purely about changing how editor presents scripts to be used on entities the way they already work. For ScriptableObject (which is a horrible name btw) equivalent we would have custom data assets - assets which aren't compiled into something else, just hold data and references to other assets. See #30

Doprez commented 1 year ago

Would this then allow Scripts to be distributed in nuget packages the same way that assets in the assets folder are?

I know recently I have been having to make my scripts in my nuget builds abstract because the only way to serialize the data in gamestudio is if the script comes directly from the project folder. I always make a base class in the nuget package and then inherit the properties in my current implementation.

created a new question as this thread may be unrelated to wwhat Im thinking of https://github.com/stride3d/stride/discussions/1622

Obsdark commented 1 year ago

So, if i understand correctly you want to change the name of the main folder to "Components" instead of code and move the code editor from where it is to inside the asset viewer, am i right?

About the second point no biggie, but i have a question about the first.

do that change of name and order will be enforced by the program?

Because if so, what would happend with the custom folders you create inside your project?

I ask that because that is the kind of behaviour than allow to use other kinds of architecture in the code part, for instance, MVC, so, although is true than controllers today are components in an entity which just that script as a component, and is also true than this new way will not change that, it is also true than keeping the code order is important to keep wherever approach to programming you want to do with your project.

Granted, you want the code to be done in an IDE as is most if not all code done already in stride3d is done this way, i do however 100% agree with that, but the question is, why change the assets/code folder distribution and not only remove the chance to open them from that part of the IDE instead?

You could make than, for instance, if somebody double click a .cs it will open the entire project in VS/Razor and that's it, i think that you may see this approach, why did you decide otherwise?

Am i losing sight of something here?

manio143 commented 1 year ago

@Obsdark

So, if i understand correctly you want to change the name of the main folder to "Components" instead of code

Yes. Currently in the editor there are two virtual folders:

I want to replace Code with Components and instead of having files in there I want there to be types and only those types which have an action in the editor associated with them (i.e. adding component to an entity).

and move the code editor from where it is to inside the asset viewer, am i right?

No, the editor would stay where it is.

Because if so, what would happend with the custom folders you create inside your project?

Folder structure would be preserved - see the example at the bottom of my first post here.