[Best Practices] Scene and UI

kisis

Hello !

I worked on Godot for quite a while now, but the game I'm working on currently is a mess that I want to organize. So I've looked up the "best practices" section of the Godot Documentation to find some clues about how to organize my project, what kind of relations my nodes should have, etc etc.

Somewhere in it, it's written that "Scenes should be independant from one another". Which I can understand, thanks to my I.T education. But I was wondering though, must it be that independant that the UI should be handled inside it ?

I'll take an example from my game : I have a Taxi, which can brings you to some other areas via a simple window with some locations. Currently, I have a scene taxi.gd with sprite, logic, and all. It sends some signals at some key moments, that I connect with on another scene (UI.gd) where all my windows, ui and all is configured.

I connect the two inside a main scene, where I have a node "world" (I'll put my taxi as a child of it, for example), and just next to it an instance of my UI scene.

Is this okay to do that, or should I handle the taxi / object's ui into its own scene ?.. :( I can't decide much, since if I recall correctly there should be only one control node for all the ui, right ?...

Thanks in advance ! ^-

dotted

I found after a while that bundling UI input handling into its own scene/node+script very helpful.

The assumption here for such a scene is that it is handling inputs for a certain kind of parent (taxi), and that it may manipulate a UI scene or more likely emit signals. The taxi node can then assume it has some sort of input handler and might trigger actions through it, like telling the handler that it has a flat tire or some other status-ie thing. The handler can then interact with UI presentation to tell the player what is happening.

It is up to you to factor your presentation side of the UI to handle taxi specific scene elements. If your project warrants it, that may be a Good Idea.

But

If you do factor the UI presentation elements you can then bind the presentation with the input handler cleanly. In this way you have factored out details of the input methods from the presentation methods and the "model" ie the taxi from the details of each.

This way you can swap out presentation and key bindings freely so long as the interfaces between each actor remains constant.