0 votes

So, something I noticed while messing around with the engine, is that, if I wanted to, I could use nodes to achieve a semi-"Entity/component" framework for my project. Using the example that made me discover this:

I was making a 2d game, and needed to make a system that alters a scenes z-index based on it's height in the level, in order for the perspective to look right. This was before I discovered autoload scripts, so what I did was I made a scene that contained only a single node, which contained a script, that contained a function that updated it's parent's z-index. Then, I made an instance of this node in every scene that needed this functionality, and called the function in the top level script.

Now, obviously, in this case autoload would probably have been easier, however, if I ever needed to to reuse MULTIPLE functions, I could see this being pretty useful.

But that's where my question comes in. SHOULD I do this? Is there any inherent flaw with this system that I'm not seeing? I would really like to be sure, because I want to make a tutorial series for godot, and I don't want to teach any bad practices.

in Engine by (36 points)

1 Answer

0 votes
Best answer

You could do either way. Because it is the developers idea on how to structure our own games. In this field of programming games, there is no bad way or a good way. But sure there are high performance and low performance ways. So if your game is working perfect, it doesn't matter how we structure our games, in the end we are only going to maintain it and we know how our game works. If the development is done as a team, then all can come up with a common structure to keep everyone on the same boat.

That said, I personally like all things the modular way - or the component way. It is similar to unity way but not the same. Unity is designed to be like an ECS, so we separate the functionalities in separate scripts. Godot is not designed that way. Sure we can achieve that by using several nodes but I don't think it is necessary. Because from my experience, the things that are mostly reused are locomotion, collectible and animation scripts. All other things have unique features themselves. So I mostly duplicate the scripts. We can also inherit other classes but as the game get complex, inheritance may cause some troubles. By duplicating the scripts we can reduce dependencies. Duplicating code doesn't cause any performance problems.

For easy maintainability, I prefer to write script on a node which contains the features for only that or its child nodes. Sometimes we may need to test the games by disabling something. If some other node is dependent on the disabled item, it will be hard to quickly change and test several features. I generally use - may be we can say it is an - observer pattern. For example, if a score HUD has to show the score, the score node has to ask the score value to the Game Manager script. If we remove the score HUD, the game doesn't break.

Let us understand that there are people who don't know as much as we do and are certainly passionate about game development. Our tutorials may help them to jump start, if they are really passionate, they will find and solve things with the help of others. So go on with your tutorials, we can also learn from teaching, let us make Godot engine popular together.

by (751 points)
selected by
Welcome to Godot Engine Q&A, where you can ask questions and receive answers from other members of the community.

Please make sure to read Frequently asked questions and How to use this Q&A? before posting your first questions.
Social login is currently unavailable. If you've previously logged in with a Facebook or GitHub account, use the I forgot my password link in the login box to set a password for your account. If you still can't access your account, send an email to [email protected] with your username.