No one knows how Godot works. (Re-MultiScript, Re-Class based node)

[MysteryGM]

This is more of a informal topic but it is a drastic issue if not the main Godot issue. No one knows how the developers of the Godot engine, planed on the users using it.

Some related issues: #19486 #7402 #15996 #8502 These are the top 4, but there are lots of similar ones that all aim to solve the same problem: Everyone is looking for a usable workflow.

Amazingly Godot users have managed to create inefficient workflows that copy other familiar engines. To demonstrate this I will use a mock class of what a MeshInstance, if made in Godot would look like.

There is pseudo Unity, aka child nodes:

Godot users use child nodes to create a equivalent to MultiScripts. MeshInstance(Spatail +script) --- Mesh(Mesh +script) --- Material (node +script) - Shader (node +script) - Texture (node +script) --- Transform (Position3D +script) Basically they will use the most appropriate node and code what they need to create what class they want using a script. **Problems:** 1.) It is the digital equivalent of adding cold water to a boiling pot; it helps short term but causes more confusion in larger projects. 2.) Most users end up using signals like events, connecting them only to the node sending them and using **Export** to find the target. 3.) Events can be intercepted before reaching the lower nodes. 4.) Performance is slow and at around 50 000 object it can stall when the game tries to load scenes.

Pseudo Unreal, aka controllers and intermediate:

Godot users make controllers and possessor nodes that manipulate all the children. The trademark of this workflow is the classes derived with extends. MeshWithTexturedMaterial.instanced() *only node in tree -> extends from -> MaterialTextured -> extends from -> Material -> extends from -> Shader This system requires heavy planing, or you end up with similar code in many classes. Like a camera, character and vehicle classes all containing their own copy of "follow target" **Problems:** 1.) Messy large scripts that is a pain to debug. 2.) Duplicate code in different classes. 3.) Godot doesn't treat nodes as classes; forcing these developers to heavily relay on self coded classes. 4.) Extends don't make sense, like a _combat system_ extending a _weapon system_ and finally extending the player.

Pseudo Panda3D, aka Preload(Script):

This one replicates the workflow of how most code based engines work. The developers will often have more scripts than nodes. MeshInstance (Node) Preload (Mesh Script) Preload (Material Script) Preload (Transform Script) Strangely it is these developers who refuse to abandon GDscript, even when C# is clearly better for this approach. That is why I assume they are familiar with Python. **Problems:** 1.) Confusion on how imports should be called, as constants maybe variables with onready; who knows. 2.) Rarely uses Godot nodes, I have even seen developers ignore the UI tools completely. 3.) Pain to debug as there is no indication of where a script is linked.

WTF script:

Left the best for last. Some Godot game developers have managed to make good games using Signals and Groups. MeshInstance (Node) having a empty node on top allows for easy moving and re-design of the children. --- Mesh (Mesh +Script || Signal) --- Material (Sprite +Script || Signal) --- Transform (Position3D +Script || Signal) When the tree has to connect objects 2 scenes or more deep, a group will be used instead. Notable about this workflow is how it has shallow trees. **Problems:** 1.) Signals and Groups allow for whole parts of the game to just fail, without as much as a warning. 2.) Small pointless scripts just loitering around. All they do is send a signal and track a single value. 3.) Moving a object with so many signals attached is frustrating in the least. 4.) Conflicts with instance system. Because instances flow down while signal connect best up ward.

Yes, I know Godot has a MeshInstance class. The point this demonstrates is that most of the workflows used by developers right now can make a class as complex as MeshInstance with multi components; except each workflow is seriously flawed.

All these work flows share the same core problem. They are short term solutions to developing a game. None of them scales well and debug is flawed in all of them.

What Godot game developers needs from the Engine developers is a clear deceleration of what the official workflow is for making complex objects and systems. That way they deviate but always know how it was intended to be used.

[willnationsdev]

@MysteryGM

I don't think any of us even knew we could make custom resources.

Yes! I just recently added a section to the docs that outlines the process. :-D

You can extend ANY engine type with a script, including Object, Reference, Resource, and, of course, Node (or any of these classes' derivations). The only things that can't be extended are engine and editor singletons (like OS, Engine, or EditorFileSystem).

[starry-abyss]

Thanks for your input in the topic. The problem with inheritance is that it only works if we know all the relationships of classes when we implement them.

You're welcome. I put inheritance in the end of the comment, because it's not required for implementing the fire-wood system. It seems that you have already a solution in mind using paradigms you're used to, and your issue is not how to create a fire-wood system, but how to use the favourite paradigms. I apologize then. I'm not familiar with GDScript inheritance, but I believe others already answered your question.

[MysteryGM]

OK, we have had some time to test the new method and found it to work perfectly. We where able to replace hundreds of nodes with scripts already; greatly improving performance.

Considering that the Resource preloading solves the problem of Including scripts. Also can be used as a alternative to both Unity's MultiScript and ScriptableObject by exporting a resource variable in GDscript. Combined with the fact that the Documents have been updated to explain resources in more detail. Not to mention that Godot 3.1 will also have script classes that should allow for even more workflows.

I think the original goal of this issue has been resolved, and this issue can now be closed?

Again I want to say thanks to everyone for participating in the discussion, and especially thanks to @willnationsdev who provided a huge amount of insight into the Godot engine.

[pgruenbacher]

@MysteryGM I think your thoughts at the start of this thread and end of this thread may be good to write up in a blog or a godot-docs draft. I think most early users often make performance mistakes when trying to achieve complex scripting organization, we need good write-ups of "before" vs "after" in terms of learning. The lessons and patterns we learn in early tutorials won't translate well to large-scale games, which to me just means we need more blogs / advice on large-scale lessons.

[MysteryGM]

@pgruenbacher ,it is a great idea. There is two problems for our team with this, one only two of us know English to a useful level, and second is that it will take a lot of time.

Even so there is a good change that we will make a development blog, and we do keep notes of everything we discover. It is possible that we will make a "Transition to Godot" blog entry.

Right now I am working on some "Godot crash course for artist" PDF tutorials, because we want to hire freelancers for the team, but Godot isn't well known yet. These tutorials are aimed at introducing Godot to professional game artist. Once I have these done I will share them with the other Godot users, I will keep them PDF to start with, because it is easier to correct mistakes while I am still learning.

[willnationsdev]

@pgruenbacher @MysteryGM While not in the same vein of a before/after experience with Godot, this Issue and some related reoccurring questions have prompted me to start working on a scene/script design best practices article for godot-docs. I've got a branch on my fork, but it's very early WIP atm.

[Aaron-Fleisher]

Reading topics like this are extremely disheartening (in the sense of making me second guess if we chose the right engine). Our project is well over 15,000 LoC and organized perfectly and runs great. (i'm not gonna go into details of specific points because other people here are much smarter than myself).
With that said, I'm glad you will stay with Godot, MysteryGM! Def looking forward to reading the dev blog

[pgruenbacher]

Meh in my opinion games with significant logic are better off with the code isolated from the game engine anyways, so it shouldn't really matter how the engine works. My node scripting is mainly used for interface rendering and physics logic. The game logic is a shared library compiled separately

On Wednesday, November 14, 2018, Aaron-Fleisher notifications@github.com wrote:

Reading topics like this are extremely disheartening (in the sense of making me double check if we choose the right engine). Our project is well over 15,000 LoC and organized perfectly and runs great. (i'm not gonna go into details of specific points because other people here are much smarter than myself). With that said, I'm glad you will stay with Godot, MysteryGM! Def looking forward to reading the dev blog

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/23052#issuecomment-438871197, or mute the thread https://github.com/notifications/unsubscribe-auth/ADLZ9pw2-G0kE19meyi7iSkceAldfAMjks5uvLb4gaJpZM4XelSe .

[kavika13]

@Aaron-Fleisher

... making me second guess if we chose the right engine

If the engine you are using now is working for you, even if you have to do some work-around, then there's no reason to fret. You may get some players (or other devs) questioning your ability/sanity, but that's just the reality of game development. Lots of passionate people talking with apparent authority (often way above their actual skill level).

You are the one who knows your problems, and you are the one who is going to have to do the work. Avoid getting paralyzed by what would have bought you maybe another 10%-20% productivity. Save it for the next game. Or don't, since you've already invested a ton in learning the tools you already know. Your choice :)

[willnationsdev]

@dejayc That is strange. I've never had issues with the Project Manager myself (with 3.0.6 stable or even the master branch) on Windows 10 or my Linux Mint device. I would recommend you create a new Issue about your problems here (as this isn't really the right Issue for such a topic), and hopefully someone can offer better assistance.

[starry-abyss]

@dejayc If we all donate to Patreon, Godot project would be able to hire the full-time usability guy.

While I agree with you minor points, engines should be chosen based on marketing posts in social media how critical are their drawbacks for the particular project. And sadly all of them have a lot of drawbacks, which are deeper than the surface level of UI...

That said, I opened a suggestion issue about Project Manager, given some free time, I'm going to work on some improvements in the area.

[jluini]

I have worked with both Unity and Godot and found the general workflow and structure much better and intuitive in Godot (specially the scene model instead of scene/prefab from Unity, the "single-script" model instead of the multiple-components, the speed when downloading/starting the engine and exporting and the ability to fully work offline).

There are lots of posible workflows and models in both of them and it's never easy to know which one is the better for you.