VaclavElias
commented
2 years ago @najak3d thanks for your feedback.
I actually started doing this tutorials/examples to bring certain working prototypes together and help/guide a developer to prototype whatever they need to or learn basics in game development. Eventually, these could be moved to Stride repo.
I started with Drag & Drop window as I like this UI feature in games. Then I realised that there is too much going on just for the sake of drag & drop regarding the project set up.
I don't have too much game development experience so many terms and suggestions you made across the other channels are beyond my understanding at the moment but also I wanted to step back as a developer and play with Stride outside the editor as it seems much simpler, including if I would like to teach somebody basics, it is much easier just to use the code in the beginning.
I started digging how to do game development without the editor, there were some approaches and difficulties made by others and I put it together, had discussions with Stride community, did a few tiny PR to the engine to simplify certain things but this is the working prototype for code only approach, just a console app with a NuGet package(s).
https://github.com/VaclavElias/Stride3DTutorials/tree/main/Other/Minimal
You gave quite of feedback across the other channels and also here actually suggesting even more reasons and benefits of code-only approach which I didn't consider and you have got obviously years of experience in game dev which adds more input.
I will be summarising this https://github.com/stride3d/stride/discussions/1253 and create a new issue where we, community can further elaborate what else could be done for a better code-only approach.
Once this is done, I would like to make all my examples in this repo code-only approach and I like all your ideas. I would like to toggle also
- gizmos, as beginners get disoriented
- list entities and components in debug in some way
- show some debug info above the entities
Let me ping you once I am ready but feel free to discuss this further.
I would go ahead with all your suggestions. We can list what kind of examples we would like to have, I like some of the examples from here https://github.com/NotNotTech/Raylib-CsLo (you might find that project also interesting).
I love this project. I modified it to show FPS below the Cube Count, and also to make the 'P' key toggle physics on/off.
Keep in mind that these tutorials aren't just "teaching Stride3D" but primarily are also a "Performance/Feature Evaluation tool". As new devs come to evaluate Stride3D -- these tutorials need to make it easy for them to ascertain the capabilities and performance of Stride3D. In this case, for Drag/DragDrop - We are evaluating physics too.
So suggestions are:
In fact, maybe all Tutorials should have the same HUD which allows the user to do the same variety of things (toggle shadows, physics, and various material effects). This way, they can see some top-end effects, right from the get-go, and also measure their performance.
So of course, we're going to want to be sure to make each Sample as efficient as possible. For the box scenario, we should add a user option to toggle the Instancing method used (not sure what Stride uses here).
=== Also - the code for this demo brings to light a few areas where Stride is failing the "program first" litmus test. I see that Stride required you to start out with a ".sdgamsettings" and ".sdscene" assets, at minimum. This needs to be changed in Stride pronto, and should be easy to change.
For example, we could kludge Game.Settings, the same as Physics was with "Physics.Simulation.IsDisabled" (static field). Similarly, the Game class itself could have a single public property called "Game.DefaultSettings" that you can configure BEFORE you start the game... then in the absence of a .sdgamesettings asset, it will use these Defaults.
Same for Scene -- we need to make this created in C# purely, e.g. "var scene = new Scene()" and then add it to the SceneSubsystem in C# that the user writes.
This is how the competitors work (e.g. Urho3D.NET).
Also -- I think we should have a version of these tutorials that runs with the Stride3D source code, so that new devs can debug directly into the code, and see what's happening (and even tweak the Stride3D code, which is also a great learning experience). The current samples run using Nuget. It would be good, IMO, to use GIT's "submodule" capability to import the Stride3D source repo, and compile it from source code. That way they can see-the-gold while they are evaluating.
This effort you've started here, IMO, is AMAZING -- it's the right idea that will open the doors wide to many more apps, who are just looking for a lightweight .NET rendering solution.
I'm ready to help out. Let me know if you are interested in my help, and if so, how would you like to collaborate?