When designing UI screens, do you have bigger scenes or more smaller scenes?

I tend to lean towards factoring out anything I reasonably can. Helps to compartmentalize elements contributing to the thing, so I can worry about them solely in isolation.

E.g. if I have a list of something within a larger scene, not only items are separated (which is basic, since they are repeatable), but the list itself is likely to be its own component as well. With explicit API for managing items.

Am I weird? 🤔

@yurisizov Not weird at all. I do exactly the same.
@yurisizov I think that's the proper way to do it!
I've done a lot of web single page application stuff before (Vue, React) - the general convention there is to build small components (not necessarily reusable, purpose-built is fine) and compose your UI from those. I've found this translates basically one to one into Godot in a very natural way
@yurisizov "properties down, events up" is a common paradigm that translates really well too!
@Ry Aye, Godot's scenes are pretty much the same component model as you'd find on web these days. I apply the same principle on web as well :)

@yurisizov

Unless I reuse I usually chunk them into one scene per screen or function and anything instantiable is naturally a scene and anything that I might want to remove easily is a scene as well.

I often end up creating these manager Nodes to handle some functionality so that I have a bunch of exports that point to the stuff it drives as there's often a need to move stuff around the hierarchy and this would cross scene boundaries.

@yurisizov Also: Apologies for the stroke level sentence I made.

@irve Well, with my example of a list there is nothing that would cross scene boundaries. But it's also not something many people would factor out naturally, only when it gets too complex.

I guess you'd put a list item in a scene, and manage the list in the main scene?