Discussing Architectural Patterns in Godot after 2 years of development

[joeblub]

first of all: Thank you for this elaborate response (-:

Have you read our comments, rebuttals, and discussion about that very video in this thread here? Godot Architecture: 7 steps for more flexible, extensible, testable code (video)

I have not. Thank you for linking to it (-:

This is an interesting complaint. Is that because you’re used to multiple inheritance in scripts instead of composition?

That was my first attempt. Basically, in Unity you can attach an unlimited amount of scripts to a game object (or whatever it was called; it’s been some time since I used Unity)
But in Godot you can’t do that. Thats why I had to learn that now everything is a Node in the scene tree. (Ok, almost everything. I have read the docs about when not to use Nodes (-: )

@dragonforge-dev

The video also doesn’t discuss Scene Inheritance which is different from Object Inheritance through scripting. Looking at my scene from above:

I havent heart of scene inheritance. Thank you for showing this to me I will look into it. It sounds very useful.

@dragonforge-dev

I think everything you said in this section is true, but oversimplified.

You are right, it definitely is oversimplified. If I had actually tried to put everything I learned and encountered in the last 2 years in this post, it would have been much longer. (And it already is pretty long.)

@dragonforge-dev

This is not an objective measurement, and so is useless IMO

Spoken like a true natural scientist. I am not sure if I agree. I think subjective soft measurements and skills are very important in development. If you want to measure objectively, you oftentimes get either extremely complicated or uselessly simple results.

@dragonforge-dev

I would do none of the three things you suggested. Here’s the full code for my Health Component:

How do the other objects subscribe to the signals the health object defines?
Signals are great for decoupling, and I use them a lot. But unfortunately, they cannot solve the issue of needing to get a reference to the object that defines the signal.

@dragonforge-dev

If you are not listening, you do not need to know what’s going on in the Health Node.

That totally makes sense. Although I do notice that the getters for the maximum and current are not declared as private. Do you access them from other scripts?

@dragonforge-dev

You’ll notice that my setters are private, and also separate functions. This is so I can extend them using inheritance. that’s because when the player’s health gets low, I want to play a sound. I also want to save the player’s health whenever I save the game. I also want to send a Signal through the Game object, which is my signal bus

I don’t quite get how making them private or extending them in inheriting scripts helps you with archiving those things. Do you have another script that extends PlayHealth and is also responsible for emitting signals that cause sounds or playing sounds directly?

@dragonforge-dev

The HUD and Health component do not need to know about one another at all.

From how I am understanding your code, Game is an autoload, which defines signals that can be emitted and subscribed to using its name. This is actually exactly the pattern I meant to describe with Pattern 3. (Although perhaps I haven’t been clear enough. I think I confused the terms Singleton and Autoload quite a lot.)

@dragonforge-dev

Yes there are. They are just difficult to implement because you have to declare a static signal, then a non-static signal to kick off the static signal. It’s just easier to use an Autoload whose signals are easily available.

interessting.

@dragonforge-dev

Use an Autoload. If you want to use a singleton, you should make an Autoload. Then you should try to refactor your code later once you got things working to see if you can remove it.

@dragonforge-dev

Use an Autoload. If you want to use a singleton, you should make an Autoload. Then you should try to refactor your code later once you got things working to see if you can remove it.

that is what I meant to say (-: sry for the confusion

@dragonforge-dev

Again, using Autoloads solves this problem because they are guaranteed to be loaded - in order - before the rest of your game. But emitting signals from an Autoload is useless because there’s nothing there to listen to it

I disagree. While the autoload itself is loaded first, the same cannot be said about the scripts that use them / subscribe and emit signals. Of course if you manage your functions correctly you can avoid this, but it is very easy to mess up. This is why I have been looking for an architectural solution to this problem. Perhaps there is no good one as of right now. Which would be fine and in of itself good to know.

@dragonforge-dev

Learn how things are loaded, and how to listen for the ready signal, and this will happen much less frequently - and when it does, you’ll know how to fix it.

I do agree that with experience this happens a lot less. I still have a lot to learn. I just wish I could spare beginners from some of the pain I had to go trough.

@dragonforge-dev

No. It’s ECS-lite and it goes against the architecture of the Godot engine itself. It can work, but it fights the engine to make it work.

Good to know.

@dragonforge-dev

You should go look at my GitHub repositories.

I will. (-: The code you shared across various posts does look pretty cool.

@dragonforge-dev

I think you would have learned a lot faster if you had posted questions here as you went along instead of dumping two years of experience in one post. Because frankly, we would have helped you avoid a lot of wrong turns years ago.

I have. In fact some of my questions have very much been about earlier versions of this exact problem. (Earlier meaning I knew less about them)
However often I did not know what to ask for. This post is a great example for this:
https://forum.godotengine.org/t/how-to-do-inheretance-with-different-kinds-of-object/83499
This is one case of me accidentally asking a XY question. (The kind you recently complained about (-: ) What I really wanted to know was how to structure complex systems in Godot and what I asked was how to to complex inheritance, because that was the only thing I knew.

@dragonforge-dev

I love Java.

Im sorry for insulting your baby. It would probably be fairer of me to say:
“It is not clear to me what java is good for” rather than:
“Java is good for nothing”

@dragonforge-dev

No. You can access anything anytime. If you want it in the editor, use a @tool script. But I don’t really know what the question is here.

I can access a reference to an object that has not yet been created? Curious. Altough I think that would be a question for a different post.

@dragonforge-dev

I don’t check to see if I got a player. I do that with the collision layers. No need for extra code, and if I do set the layers wrong - I immediately know because I’m told the ground does not have a damage() function. And I know what I need to fix. The bug never makes it far enough into the game for the end user to see it.

interesting. I have so far always manually checked for types. But perhaps that is the better approach

@dragonforge-dev

game

@dragonforge-dev

Do some game jams. That will help you temper this approach. Your game development speed will skyrocket.

I have, and I will continue doing so. This is really good advice, and I learned a lot from gamejam. However, I learned it by doing everything fast and messy. I still think that there are some things I need to learn with projects that go on over longer periods of time.

Finally:

@dragonforge-dev

There are solutions to this, but this post is so long that I’m kinda getting burnt out on replying.

I know. I’m sorry for bothering you so much. But I don’t think any of my words were unimportant, and I have already learned a lot from the replies (-: So thanks once again.