No one knows how Godot works. (Re-MultiScript, Re-Class based node) #23052
Comments
|
If the question is simply : "Are there several way to achieve a same result in Godot ?", the answer is yes. And trying to force a single workflow is absurd, as each system in a game might have different requirements. You don't code the same way a system that requires a lot of performances and one that requires to be updated often by a game designer. All solutions have tradeoffs so there is no point is making an "official" workflow. |
With what components exactly? EDIT: And just so you know, one of the issues you cited was closed with the author stating "This idea truly and utterly sucks and is completely nonsensical." |
I don't quite understand what you are trying to say here. Why would someone create a MeshInstance class if there is already one? And why is it a problem that Godot has features similar to other engines? Also, if you are trying to attach multiple scripts to one node you either do not use OOP or you are putting two separate functionalities into one node, which is easily fixed by using Godot's node system. |
If I make a hammer I know what it is meant for, I know some of what it shouldn't be used for even if I do not know everything it could be used for. This is where Godot is at, the developers are swinging in the dark, hoping that somehow this will allow them to create something.
Things like materials and transforms, are these considered part of the original instance or not? What about other task, like "follow target" or "shoot at target" should these be added into the class or attached somehow? We know we can't have everything, so the question is what do we have? How was it design to work? |
|
@MysteryGM Loose and disconnected analogies are not helpful.
Transform is a Spatial property and Materials are a Mesh property. MeshInstance is built on top of Spatial so it inherits all of Spatial's properties. It's a simple hierarchy that makes sense to me.
Why would you create your own Mesh system when Godot already has them?
Code goes in scripts. You can put it in the node's main script or give it a child with a script if you believe it would be more useful to do it that way. |
Because 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. If 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.
But in what way? What I want to know is how does Godot deal with large games with complex systems like weather effects, volumetrical fog and large terrains? |
|
The following relates to me, my opinions and experience, YMMV Every engine has it's quirks, and Godot is no different. If I am being honest, given how long it has been since its first stable release, I am definitely gobsmacked on how good it is and how fast it evolved. That may be a reason for some of the problems we have. The scene/node system is my favorite part, the simplicity of scripted nodes is really what shines for me. Even though it has its downs for me, I dislike python-like syntaxes... and the preload system... couldn't figure out how to get C# working. Taking Unity 4/5 as an example (to which I was chained for years), it has components so bloated that it can't be compared to any other ECS I've ever used. And oh, you want to make an http request? Sure, add a new component to a new object to your scene structure because it makes a lot of sense to couple http requests with in-scene objects and its components. The "save a scene with no changes breaks all UUIDs" feature seemed to be coined just to make it harder for our non-techy designers to use version control. I don't even want to get started on "Don't Destroy On Load" and prefabs. What was the rationale between most of that stuff anyway? I'd say it is probably organic, iterative development, and some hacky workarounds here and there (also found in Godot and probably all other game engines). I mean, it crashed so much that my Swift Keyboard started predicting the words "Unity crashing" every time I typed "With". That was a major part of my workflow, crash -> reimport all assets for a minute, work for 30', repeat. I have seen so much blasphemous monobehavior usage, but who can I blame? The engine does allow people to put a GameState "component" inside a pointlight object. Should we forbid it? How do I argue that the game state data shouldn't even be inside a scene object's component when http communication (or virtually any async work) needs one? That takes me to my point, comparing engines in their different development stages is hard, and indeed Godot is evolving fast and adding/removing features. That does mean our workflow will have to change and adapt accordingly. I have a decent 2D workflow with Godot, it is definitely better than the one I had with Unity. Yes, best practices are cloudy. Yes, if you ask three developers you'll have three different workflows. But I can't say that is a new problem for me, or at the very least it is one present on both the compared engines. I haven't really used Unreal (or any other relevant game engine) for more than prototypes and test projects, can't compare with reasonable depth. |
Put all the functions in one script perhaps? Godot can be used object oriented pretty well, so if you ever used OOP you can use script or scene inheritance, create classes and so on.
Weather effects? Create a scene containing a particle node, a sun and a world environment and attach a script to the root. This script can control the weather. You could also create an empty node and use it as a state machine, attaching empty nodes for each state you have (like rain, sunshine etc). Now just put the code for each state in their nodes. This state machine can be controlled by the root script. This is a very easy to read way of doing things. Volumentrical fog? I think I have seen this in the new FPS Demo. Large terrains? I had a project with procedural terrain meshes once and it was running pretty smooth on my a couple of years old laptop. These are just some functionalities rather than a 'big issue' you where talking about in the OP though. |
Well we plan on being a bit more ambitious than that :) with a region map to tell both the AI where to walk and then using a other channel for rain exclusion zones while keeping the last channel for depth so that snow can build over time.
Space large. We need some way to reset scenes to the Vector3(0,0,0) without it freezing because too many nodes need to be removed. Physics and everything shakes with large floats.
Agreed, components can be awful that is why it wouldn't surprise us if Godot has a different strategy in mind. However we have no idea what strategy Godot planed or if it even did. 2 months of learning Godot has only thought us how to make small games. The last thing we want to do is fight uphill against the engines design while we try to develop the game. |
|
@MysteryGM I really don't understand why you think Godot isn't usable for big projects. Its design really lends itself for big projects because you can split everything into separate scenes and use OOP to reuse work. If your problem with using Godot for big project is that you don't know how to achieve a goal, just ask on the Godot Discords help channels, you will get a very immediate response. |
See #288 |
I do understand it is kind of alien at first, but to me node+script usage it is pretty straightforward. I would definitely recommend taking a look at (at least) the hobby version of this course here: https://gumroad.com/gdquest edit: Actually, you can take a look at the source in the repository, if you don't want the course https://github.com/GDquest/make-pro-2d-games-with-godot |
I guess I'm just a little confused on what exactly you mean by this. You used the hammer analogy earlier as an example, but it's a flawed analogy since a hammer is generally a single-use basic utilitarian tool, and there is a intrinsic understanding of what the tool is used for due to its affordance. Furthermore, while you have listed all of the problems with all of these above systems, I think that the reality of any big software project is that each architecture 'choice' you make will lead to some disadvantages down the road, which you just have to work more with along the way. So are you looking for a silver bullet suggestion? Because frankly, I don't even think most Unity or Unreal projects follow the exact 'recommended' structure and often fork the engine to suit whatever workflow works best for them. I'd even go as far to argue that every game needs to have its own unique idea on node architecture. (A simulation game would have a very different structure than a third person shooter, for instance.) I guess an argument could be made for more documentation on examples of project structure, but I think that's just a matter of more contributions to the documentation. |
Like I mentioned before, moving objects around after signals have been attached is a pain. Especially when they stop working without ever giving a exception or warning. What we want to know is how do we work with these problems, how did Godot plan to deal with these; we tested every workflow I mentioned above.
Thanks for that, we are so use to resting world coordinate, we never checked this.
The problem is not that it is alien, the problem is that it causes a different problem. Mainly that adding more children eventually lags the game or freezes it when we try to unload them. |
|
Why do you need 50,000 objects in your game? Surely this would lag ANY engine. |
Because we use nodes to add extra scripts to the objects. Because Godot's UI tools use containers in containers in containers... to scale things at real time. We have 50 000 objects because a single enemy AI is +/-8 nodes with a purpose and +/- 64 nodes that are only there so we can attach scripts to them. |
|
In that case, it seems like you have breached into the zone where Custom Modules are a good option. edit: Though I'd argue that 800 objects for one (smallest?) ui points towards bad design/architecture. |
|
I seriously fail to understand how you can have anywhere close to 64 scripts for a single object. This sounds more of a design problem of your project than a Godot problem (again, likely to lag any engine). Consolidate your code into fewer scripts. Don't make a script for each piece of functionality, but instead for each type of object (If an "Enemy" node can do XYZ then add that part into the Enemy script instead of adding child nodes for X and Y and Z functionality). If you need more advanced features to do this, perhaps you could make use of custom inheritance and/or C# interfaces. |
See this was one of the things we are wondering about, because all of us know C++ if Custom Modulse is needed we would instead just edit the Godot engine.
Simple, every AI can do more or less 64 tasks, not minor tasks either. Our rule at the moment is to divide user feedback from the mechanic.
If you look at the images and Pseudo Unreal, aka controllers and intermediate. |
I find creating modules much simpler than changing the engine itself, as it builds on top of it, instead of into it. Still can't imagine this scaling to such high numbers though, especially UI with hundreds or thousands of nodes per widget. |
|
In response to the referenced Issues in OP:
Many of the issues raised in the OP revolve around there being multiple potential ways to address a problem, each of which may have various inefficiencies. Usually, when there is a particular way of doing something that would be most optimal, the engine provides its own implementation in the main C++ engine (no need for scripts or plugins) and that's the suggested usage. If such a class exists and people aren't using it, then that's a sign that 1) they aren't properly checking the documentation to see if their needs are already met by the engine / how the engine suggests it be used or 2) the engine / organization isn't doing a good enough job of making the documentation highly visible or accessible to users (since they aren't finding the resources that exist). The only thing to be done to fix problem 1 is for those people to vocalize their problem and for someone else to redirect them to the docs or Q&A site to help them find their solution. I've created an Issue (#23043) that suggests letting people browse and use the Q&A site directly from the editor which should help a lot with problem 2. Reasons are described in the link. (Edit: if there are many ways to solve a problem, and one of those ways is far better than any other, and Godot doesn't yet implement its own native solution for it, then that would be something to suggest as a new feature for the engine. This is kinda how we got the SimplexNoise stuff added since people were writing their own SimplexNoise algorithms in GDScript / shader code, etc.). Based on the "problem board" you depicted, the issue you were having is that multiple inheritance isn't supported (nor a good idea), so you went with component nodes that grant functionality to their parent (which sounds reasonable to me). If you are running into issues with your game lagging because it is simply creating too many nodes, then it seems to me like there'd more than likely be a problem with your general approach (which is what you seem to be recognizing and seeking help for in identifying here). As for your examples of workflows in OP...
Anyway, that was all my experience with the stuff. It would help a lot more for us to know more about your project and what all it is actually doing so that we can give suggestions for your particular use-case. Either way, the problems that you've raised here don't appear to be "new" problems with Godot Engine's design or implementation per se. Godot gives people an API and how people use that API is up to them. If you have an idea of how a particular feature should be made more integrated / available in Godot (for example, re-vitalizing MultiScript), then that would be a fine proposal. As it stands though, the question here seems to be more of a "what's the best way to design a system like X" which...isn't really a GitHub issue. Seems more appropriate in the Q&A site for a "best practices" sort of question. That, or it's a suggestion that we should provide an avenue of making this sort of use-case-specific information more clear / publicly available, which is exactly what my Q&A Issue is about. |
First thanks for the long reply, that is a lot and clearly took some time to write.
I feel like I should explain this. At the time we had very large scripts, each having roughly +/- 30 functions. For that reason we wanted to avoid adding the extra signal functions to the already large script.
That is indeed the root of the problem. Mainly that we tried lots of designs recommended by the Godot community and some from tutorials. Ending up with me here, and I think the last reply addressed a lot of what I was wondering about; I will have to double check tomorrow as it is 2AM over here.
I want to point out that we exhausted most of our other options. Each of us asked around on the Q&A forums, we made friends in the community and collected examples from them. Scanned the documents looking for explanations. Only the last workflow sort of worked, except it had our main programmer banging his head against the table and miming strangling someone. |
|
Sorry to read you're having issues finding solutions to your problems. Will already gave you a long answer so I'll try not to clutter the conversation too much but at this point, it sounds like you'd need more of a consultant to help you solve the specific challenges that arose from your needs.
Most of us in the community work in projects of a relatively small scale. I use a lot of nodes to help get the point and structure of a given system across in tutorials. This will scale fine for most people. But what works for a small or a mid-size game doesn't apply to larger ones. Following on what @willnationsdev said earlier, it might be worth considering back-end code to help the game scale, both performance-wise and just to have less code to manage in the editor itself. I can't help a lot besides that as, like many here, I don't have experience with larger projects. Good luck! |
|
Hi, we just have one more question. If we have two unrelated objects, like a building and water, but we want the scripts of these objects to interact, how do we do this without nodes or preload? |
|
@MysteryGM Are you saying you don't want nodes representing the building and water, or you just don't want scripts attached to them? There's nothing wrong with having data for processing that doesn't exist in some way within the scene tree aside from a single data containing node. If you want to take the ECS approach, instead of attaching scripts to every instance of a type and having them process individually, you can have a single "system" node that'll iterate through and perform processing on the nodes according to a type/group you assigned them. If you want to avoid attaching scripts to nodes for their individual detailed information, you could also store that info in the system depending on how temporal. This keeps your nodes lighter weight, and can be more efficient for you when operating on thousands of entities of the same type. |
|
With having 50.000 of anything you have long exceeded the point where Godot's SceneTree-and-nodes object-based metaphor is useful. That isn't much different from other engines, with Unity you'd reach similar limits with their game objects, GC, or with UE4 you'd find problems scaling blueprints that far - but above all, having that amount of anything means the default visual editors are simply no longer useful, and the provided tools start to break or at least perform badly. In all engines, the solution is largely the same: build your own solutions. What those are depends more on your game, architecture and the details than the engine. Manager classes, pub-sub communication buses, message brokers, instancing managers similar to what is done for particles, object pools, custom shaders to offload work to the GPU, compute shaders, moving processing out to threads or other processes/servers - there are tons of building blocks for possible solutions, and which ones you'll need to combine depend on your specific problem set. Unity makes some of this easier with their new ECS infrastructure. Not sure about UE4. At the end, at this advanced level, you'll have to do most of the heavy lifting yourself, however (or hire someone experienced to do it for you). UE4 and Unity only are easier in so far as that they are older, more established, and thus there is a larger number of people having run into such scaling problems, which means more knowledge (and hireable talent) available for solving it. But really, at the end, no engine will carry you that far. Every ambitious game will run into limitations in any engine. I know of scores of examples for mid to large games in UE or Unity that needed to solve similar problems as well. Either solve them or scale back your scope.
That depends largely on your game. There isn't a straight answer for this in any large engine. All engines offer tons of choices, tons of worklows and a lot of freedom, because there isn't a one size fits all solution. So if you need concrete advice on how to approach your specific game in Godot, how to structure it, what architecture to use, you'd need to provide way more context and information. Tell us what you want to accomplish, and maybe someone can chime in with advice. If not, the only way may be to hire an experienced Godot dev as a consultant. I can only agree with Groud:
|
|
@mhilbrunner Just playing devils advocate here but a better engine design (like proper ECS in the vats majority of cases where performance matters) does make many of those limits significantly higher than almost any game would actually ever experience (this is how the new Rust Amethyst game engine is building up to focus on for example). But yep, I've done an ECS'ish thing in Godot (2) and it worked a lot better than the scenetree instancing style in terms of efficiency and distibution of functionality. It can be done, just a bit painful since Godot lacks some useful primitives for it. |
|
I can only speak for myself, not other Godot devs, and I only have experience with UE, Unity and Godot, so I don't know about Rust Amethyst.
Having a discussion about where it would make sense to add such primitives / how Godot can accommodate such use cases better would be very valuable I think. Maybe not in this issue :) But we should gather this feedback some way. And I agree that there are different limits depending on the engine, but again, I've seen people hit similar barriers in Unity and UE4 as well. Maybe later, maybe those were higher - but at the end, you'll need to be able to solve problems you run into in any engine. :) |
|
@MysteryGM When the milestone percentage completion is high enough / when the core devs have judged the progress to be far enough along that they consider the build to be "stable". Milestone: https://github.com/godotengine/godot/milestone/7 For comparison, 2.1 and 3.0 are currently sitting at 99% completion. Not quite sure if that's the status they were at when they went live though. Basically, the answer is "when it's ready". |
|
Thanks for the responses and we apologize for taking up your time. |
@MysteryGM |
|
In C# I could say that the |
|
Hi, thanks for the continued concern and we are really grateful for @willnationsdev support. We believe that the scripts as export resources solution has a lot of potential. As mentioned in #22660. Because we still have 10 days to decide what engine to use, we have been trying some more with Godot. "The Godot developers keep every Issue in Github on it's own post, always open one issue for one bug, but do not allow the same workflow for their engine."
Yes that is what we want, how do we do it in GDscript?
Godot has Duck typing to do the same thing as Interfaces. What we want is for Burning to be a separate class so we can re-use it, without forcing us to add a node to the hierarchy. What we want is Fire, Burning, Wood. We do not want Fire (Wood+Burning). In C# we will just declare Burning as it's own class. Public class Burning and our problem is solved. |
Without diving into performance optimizations, all I'm suggesting is to move interaction resolving to a separate system script (not in fire, not in wood). The system in simplest case can hold arrays of all objects in the world and handle their interactions. In this case, objects don't have to care about types, only the system cares. To make things faster, one might only perform checks for objects that actually collided (for example, by sending a Some GDScript-specific examples for script cross-referencing (for version 3.0): Here # Cache the enemy class.
const Enemy = preload("enemy.gd")
# Use 'is' to check inheritance.
if (entity is Enemy):
entity.apply_damage()Here onready var runnerGame = get_node("/root/runner")
onready var runnerScript = preload("res://runner/runner.gd")
func _ready():
runnerGame.setMode(runnerScript.SPAWN_TITLE)Here we connect the func _button_pressed(which):
print("Button was pressed: ", which.get_name())
func _ready():
for b in get_node("buttons").get_children():
b.connect("pressed", self, "_button_pressed",[b])See also the docs here, there are some more features available: http://docs.godotengine.org/en/3.0/getting_started/scripting/gdscript/gdscript_basics.html#inheritance |
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. Here is an example: Step A. Except now it can be argued that both Homing Missile and Landmine should extend from a HomingClass. StepB. Later in production the same thing happens with other scripts we have. So we have to keep going through StepA to find the proper inheritance for StepB. It keeps repeating this pattern going beyond StepF etc. We found a way to prolong StepA, We just avoid adding a script to the top node, and always make that a Spatial or some primary node. I apologize for how long this is. |
What you have to understand is that Godot functions no differently in this case. While the go-to solution is to make a sub-Node with its own script (for "Burning" in this case), you can just define Burning as its own class and include/use it via static functions (or instance it and then use properties/methods)
For a Unity/ScriptableObject approach, one can use Godot's Resource scripts for the same purpose.
The easiest way to do this is with an autoload node/scene of some kind. The reason being that even if you only use one node with tons of resources for all of the different systems (to minimize the number of nodes you are using), you still will probably want to have access to a Node that is in the tree so that you get access to delta time, input data, yield operations (esp. combined with signal usage), animation/tween/timer nodes, the list goes on. Furthermore, as an autoload, GDScript again will generate a global variable for the node so that the "systems" can be accessed by name anywhere in your codebase (another suitable replacement for using a script class in this case). I actually have a large refactoring of an old WIP plugin, godot-skills, that I'd like to do that I believe encompasses this and a lot more. Please read the (sorry, long) reddit thread on the topic. It involves examining the viability of using coordinated multithreading in a server architecture (similar to Godot's underlying architecture) to implement a similarly generic and re-usable interactivity system. btw, if you ever wanna chat in real time on the topic, feel free to pm me on Reddit/Discord/Twitter where I use the same username. |
I believe I'm missing something here. Afaik, the proper way to make a "component behavior" node is one that does not change itself, but rather directly modifies a "target" node where the default target is the parent. This circumvents the issue you are encountering entirely, if I'm not mistaken. Something like this would mean you don't have to change anything by simply making a node with the script be a child of the thing you want to have the "homing" feature. You just have to assign the exported property value (either in the scene or at runtime) to tell it what to home TO. Other exported properties can be used to modify the type of movement and that stuff could also be outsourced to a Resource if you want to have different "builds". Again, Godot allows you to be very flexible with your game framework's design. |
|
Some corrections: - C#
- - public class Burning {};
+ - public class Burning {}
- using Game.Burning;
- Burning.apply(wood, fire); // is it :: here? I forget...
- - Burning b = Burning::GetSingleton(); b.apply(wood, fire);
+ - Burning b = Burning.GetSingleton(); b.apply(wood, fire);Semicolon after the class's closing braces is not needed. You use a dot for static members instead of |
|
@neikeq Thanks. I'm way too out of practice with C#, lol. |
|
As for the "Global Scripts" approach, I am very against this. It would encourage devs to code their game in bad ways. A common question of previous bare C++ and Java game devs, when they try Unity/Unreal/Godot/etc, is "where is the main game loop that I can write my code in?". Adding such a system would allow those devs to do this, so they might end up writing code in global scripts that reference the objects they want to modify instead of just using a script on an object. Perhaps instead we could improve the performance of barebones |
As I mentioned, if someone were averse to doing this (reasonably so in a large project), then there's no problem with just creating a "namespace" global script class that maintains constants of other scripts to travel further down the API hierarchy. We're talking scripts only here, not actual node references.
This system is already implementable by anyone in Godot via autoloads (there's no "adding" of a feature being suggested). Furthermore, the problem they are encountering in the first place is that they don't want to add the systems themselves as sub-nodes in the world (though I give a suggestion for that as well in the follow-up comment) since they have to have both the node there AND the script on that node, and potentially refactoring the relationships between all of the nodes and scripts when they later realize things must move around.
In what way? The only way to do this transparently would be to implement a MultiScript system and there are a whole host of problems that come along with that paradigm. The only other alternative I could come up with when trying to solve that problem was the GDScript trait system I suggested in #23101 which confines the MultiScript issues to one language, but comes with its own host of even more severe problems.
Once we fix the array type hints system in 3.2, we'll be able to do this with just... One could even implement the feature now using a Dictionary (to access the scripts by name) and an EditorInspectorPlugin from 3.1 to define a custom UI when those nodes are opened in the Inspector (create a exported-array-of-scripts UI, but have it add the script with a key that matches the filename under-the-hood). |
Ah, I think I found our problem. None of our preload attempts was extending from resource. I don't think any of us even knew we could make custom resources. I also want to point out that no one who shared their games with us or who described their workflow was extending from resource.
Will definitely have to give this a look over. |
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). |
You're welcome. I put inheritance in the end of the comment, because it's not required for implementing the fire-wood system. |
|
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. 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. |
|
@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. |
|
@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. |
|
@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. |
|
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). |
|
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 ***@***.***> 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
<#23052 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADLZ9pw2-G0kE19meyi7iSkceAldfAMjks5uvLb4gaJpZM4XelSe>
.
|
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 :) |
|
@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. |
|
@dejayc While I agree with you minor points, engines should be chosen based on 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. |
|
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. |
and others
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.
The text was updated successfully, but these errors were encountered: