{"action":"created","issue":{"url":"https://api.github.com/repos/godotengine/godot/issues/23052","repository_url":"https://api.github.com/repos/godotengine/godot","labels_url":"https://api.github.com/repos/godotengine/godot/issues/23052/labels{/name}","comments_url":"https://api.github.com/repos/godotengine/godot/issues/23052/comments","events_url":"https://api.github.com/repos/godotengine/godot/issues/23052/events","html_url":"https://github.com/godotengine/godot/issues/23052","id":370662373,"node_id":"MDU6SXNzdWUzNzA2NjIzNzM=","number":23052,"title":"No one knows how Godot works. (Re-MultiScript, Re-Class based node)","user":{"login":"MysteryGM","id":43343829,"node_id":"MDQ6VXNlcjQzMzQzODI5","avatar_url":"https://avatars3.githubusercontent.com/u/43343829?v=4","gravatar_id":"","url":"https://api.github.com/users/MysteryGM","html_url":"https://github.com/MysteryGM","followers_url":"https://api.github.com/users/MysteryGM/followers","following_url":"https://api.github.com/users/MysteryGM/following{/other_user}","gists_url":"https://api.github.com/users/MysteryGM/gists{/gist_id}","starred_url":"https://api.github.com/users/MysteryGM/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/MysteryGM/subscriptions","organizations_url":"https://api.github.com/users/MysteryGM/orgs","repos_url":"https://api.github.com/users/MysteryGM/repos","events_url":"https://api.github.com/users/MysteryGM/events{/privacy}","received_events_url":"https://api.github.com/users/MysteryGM/received_events","type":"User","site_admin":false},"labels":[{"id":279097162,"node_id":"MDU6TGFiZWwyNzkwOTcxNjI=","url":"https://api.github.com/repos/godotengine/godot/labels/discussion","name":"discussion","color":"ee77ee","default":false},{"id":279097966,"node_id":"MDU6TGFiZWwyNzkwOTc5NjY=","url":"https://api.github.com/repos/godotengine/godot/labels/topic:core","name":"topic:core","color":"ffdd44","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2018-10-16T15:11:51Z","updated_at":"2018-10-16T17:45:15Z","closed_at":null,"author_association":"NONE","body":"This is more of a informal topic but it is a drastic issue if not the main Godot issue. \r\nNo one knows how the developers of the Godot engine, planed on the users using it.\r\n\r\nSome related issues: #19486 #7402 #15996 #8502\r\nThese 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.\r\n\r\nAmazingly 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.\r\n\r\n<details close>\r\n<summary>There is pseudo Unity, aka child nodes:</summary>\r\n<br>\r\nGodot users use child nodes to create a equivalent to MultiScripts.\r\n\r\nMeshInstance(Spatail +script)\r\n--- Mesh(Mesh +script)\r\n--- Material (node +script) - Shader (node +script) - Texture (node +script)\r\n--- Transform (Position3D +script) \r\n\r\nBasically they will use the most appropriate node and code what they need to create what class they want using a script.\r\n\r\n**Problems:**\r\n1.) It is the digital equivalent of adding cold water to a boiling pot; it helps short term but causes more confusion in larger projects.\r\n2.) Most users end up using signals like events, connecting them only to the node sending them and using **Export** to find the target.\r\n3.) Events can be intercepted before reaching the lower nodes.\r\n4.) Performance is slow and at around 50 000 object it can stall when the game tries to load scenes.\r\n</details>\r\n<details close>\r\n<summary>Pseudo Unreal, aka controllers and intermediate:</summary>\r\n<br>\r\n\r\nGodot users make controllers and possessor nodes that manipulate all the children. The trademark of this workflow is the classes derived with extends.\r\n\r\nMeshWithTexturedMaterial.instanced() *only node in tree\r\n-> extends from -> MaterialTextured -> extends from -> Material -> extends from -> Shader\r\n\r\nThis 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\"\r\n**Problems:**\r\n1.) Messy large scripts that is a pain to debug.\r\n2.) Duplicate code in different classes.\r\n3.) Godot doesn't treat nodes as classes; forcing these developers to heavily relay on self coded classes.\r\n4.) Extends don't make sense, like a _combat system_ extending a _weapon system_ and finally extending the player.\r\n</details>\r\n<details close>\r\n<summary>Pseudo Panda3D, aka Preload(Script):</summary>\r\n<br>\r\n\r\nThis one replicates the workflow of how most code based engines work. The developers will often have more scripts than nodes.\r\n\r\nMeshInstance (Node)\r\nPreload (Mesh Script)\r\nPreload (Material Script)\r\nPreload  (Transform Script)\r\n\r\nStrangely 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.\r\n**Problems:**\r\n1.) Confusion on how imports should be called, as constants maybe variables with onready; who knows.\r\n2.) Rarely uses Godot nodes, I have even seen developers ignore the UI tools completely.\r\n3.) Pain to debug as there is no indication of where a script is linked.\r\n</details>\r\n<details close>\r\n<summary>WTF script:</summary>\r\n<br>\r\n\r\nLeft the best for last. Some Godot game developers have managed to make good games using Signals and Groups.\r\n\r\nMeshInstance (Node) having a empty node on top allows for easy moving and re-design of the children.\r\n--- Mesh (Mesh +Script || Signal)\r\n--- Material (Sprite +Script || Signal)\r\n--- Transform (Position3D +Script || Signal)\r\n\r\nWhen 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.\r\n**Problems:**\r\n1.) Signals and Groups allow for whole parts of the game to just fail, without as much as a warning.\r\n2.) Small pointless scripts just loitering around. All they do is send a signal and track a single value.\r\n3.) Moving a object with so many signals attached is frustrating in the least.\r\n4.) Conflicts with instance system. Because instances flow down while signal connect best up ward.\r\n</details>\r\n\r\nYes, I know Godot has a **MeshInstance** class.\r\nThe 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.\r\n\r\nAll these work flows share the same core problem. They are short term solutions to developing a game.\r\nNone of them scales well and debug is flawed in all of them.\r\n\r\n\r\nWhat Godot game developers needs from the Engine developers is a clear deceleration of what the official workflow is for making complex objects and systems.\r\nThat way they deviate but always know how it was intended to be used."},"comment":{"url":"https://api.github.com/repos/godotengine/godot/issues/comments/430331443","html_url":"https://github.com/godotengine/godot/issues/23052#issuecomment-430331443","issue_url":"https://api.github.com/repos/godotengine/godot/issues/23052","id":430331443,"node_id":"MDEyOklzc3VlQ29tbWVudDQzMDMzMTQ0Mw==","user":{"login":"MysteryGM","id":43343829,"node_id":"MDQ6VXNlcjQzMzQzODI5","avatar_url":"https://avatars3.githubusercontent.com/u/43343829?v=4","gravatar_id":"","url":"https://api.github.com/users/MysteryGM","html_url":"https://github.com/MysteryGM","followers_url":"https://api.github.com/users/MysteryGM/followers","following_url":"https://api.github.com/users/MysteryGM/following{/other_user}","gists_url":"https://api.github.com/users/MysteryGM/gists{/gist_id}","starred_url":"https://api.github.com/users/MysteryGM/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/MysteryGM/subscriptions","organizations_url":"https://api.github.com/users/MysteryGM/orgs","repos_url":"https://api.github.com/users/MysteryGM/repos","events_url":"https://api.github.com/users/MysteryGM/events{/privacy}","received_events_url":"https://api.github.com/users/MysteryGM/received_events","type":"User","site_admin":false},"created_at":"2018-10-16T17:45:15Z","updated_at":"2018-10-16T17:45:15Z","author_association":"NONE","body":"> Why would you create your own Mesh system when Godot already has them?\r\n\r\nBecause game objects are just as complex as a mesh if note more so. Remember that engines where part of games original, it was just the part re-used.\r\n\r\nIf Godot can't create a Mesh class inside the engine effectively, then it can't be used to make complex games. All of the games will have to be less complex than the engine.\r\nThis in turn means that it is of no use to a professional team of developers. Unless such a team only uses C++ with the source code.\r\n\r\n> Code goes in scripts.\r\n\r\nBut in what way? \r\nI already know I can't make a child for every script because I will need more than a million functions and even a million empty nodes is too much for Godot.\r\nWhat does that mean, how many functions should be grouped together or should I spend 2-4 months planing my object inheritance on paper?\r\n\r\nWhat I want to know is how does Godot deal with large games with complex systems like weather effects, volumetrical fog and large terrains?"}}
{"actor":{"display_login":"MysteryGM"}}