For a menu/dialog screen is it better to create separate scenes for a menu system and its child menu scenes, and connect them by coupling the scripts together or by having a signal emitted from Script A to B?
Take for example a scene called MainMenu, if there are 3 children called Option1, Option2, and Option3 each with their own scenes and scripts for their sub-menu logic, is it feasible to use a signal in MainMenu to connect the sub-menu scripts to the main script? Or does it make more sense to couple them and have MainMenu call var script = Option1.script.new() to handle the sub-menu logic.
I guess, as a third option you could even use the MainMenu script to house the entirety of the menu-handling logic (down to the sub-menu’s). But I’m curious which design pattern is recommended. I’d ideally like to split up the scripts to prevent one script from becoming so massive future development becomes cumbersome.
Generally, if you’re concerned about a script getting to large than that’s a good sign you should find a way to break your logic into more discrete parts. The common saying is “call down, signal up” (or something like that).
Honestly, it’s tough to give advice without seeing code or more of how your project is structured… but for what it’s worth (and take it from someone who has been doing this for a while) what you’re describing SOUNDS like it could be done either way.
In order to develop a 6th sense about which is right for your design style… I would say pick one and take it until the point that you see why that was a bad choice OR find out that it was the right choice. I don’t mean for this advice to sound lazy, but the truth is that what you’re describing doesn’t sound too tough to have to rewrite if need be. Sometimes it’s about personal preference and other times it’s a matter of scale (or desired reusability). But if you try one pattern and it doesn’t work, you’re going to really own and appreciate the reason - which levels you up as a developer. And the next time you’ll be able to see farther into the future when setting something like this up - there’s no substitute for experiencing your own dead end code.
I tend to like to break things up into scripts that do very specific things and I make pretty heavy use of signals BUT there are times when the scope is small enough that handling the sub-menu stuff with a direct call works perfectly fine. I really does come down to preference and scope.
Free yourself from analysis paralysis and pick one If it doesn’t work, rewrite it and pocket the experience. If it doesn’t and you’re not sure where to go from there, you’ll have a more specific question and we’ll be here to help.
I hope that was helpful. Sometimes we just need to give ourselves license to try something rather than worrying about how to “do it the right way” - I appreciate that you’re asking these kinds of questions because it means you’re thinking critically about how you structure your code, which is half the battle. Good luck, my friend!
That’s all good advice, thanks! My only concern going forward is really the maintenance scope of the game project as it grows. The plan is to keep scripts small and direct, so I was wondering if there is a standard architecture in Godot that makes sense for said scripts to connect with each other. Call down signal up is probably as close to a standard as it gets .
Thanks again for the response, and you’re right, not having a set standard or best practice might be the license to experiment and see where things end up.
If it doesn’t work, rewrite it and pocket the experience. If it doesn’t and you’re not sure where to go from there, you’ll have a more specific question and we’ll be here to help.