How to refactor Groups

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By teedoubleu
:warning: Old Version Published before Godot 3 was released.

I’m having hard time understanding how a project is supposed to be maintained over time. With dozens of separate scenes and hundreds of nodes I cannot imagine how one is supposed to manage - for example - changing a name of a group.

Is there a way to find all references to a given group? Am I missing some functionality?

:bust_in_silhouette: Reply From: eons

For keeping track of groups in scenes there is a plugin in the asset lib (could be nice to have this on the editor as feature):
https://godotengine.org/asset-library/asset/3

If you want to find all the nodes in a group on all the project, added by script and scene editor, I guess the best tool is a clean design.

Now if for some reason you want to rename a disperse and varied group (added by scenes, scripts), then another editor or a console command to mass replace text could be better (if your group names does not match with anything else, again, your design may help or not here).

:bust_in_silhouette: Reply From: breadbox

When you’re building a project of that size, then likely it becomes necessary to be more organized in your design. Make use of inherited functionality as much as possible.

For example, instead of controlling the behavior of many disparate objects by adding them individually to a given group, you would instead have all of the objects inherit from the same scene. The base scene can have nodes that are in the group, or a script in the base scene can explicitly add the nodes to the group.

Depending on your needs, you can make a base class in a plain script instead of a full-blown scene, and then have your objects inherit from that. Sometimes having all of the objects provide a given method makes a better design than using group membership.

And my gut instinct is that as projects get large, more functionality gets moved into code instead of being set up in the editor. Code tends to be easier to share between objects, and is generally easier to search through.

:bust_in_silhouette: Reply From: Zylann

Code wise, an easy thing to do is to list your groups in constantsconst var GROUP_NAME = "group_name" for all groups, and put them in a common script. Then whenever you need to use a group in code, include it like this:

const Groups = preload("res://common/groups.gd")

And use like this:

node.add_to_group(Groups.GROUP_NAME)

This allows to spot and search group usage easily through code, because otherwise they just look like simple strings.

However it doesn’t cover editor usage, where groups will still end up as basic strings in .tscn, though you can identify them as property assignments in scene files (which is guaranteed, while in code you could have indirections).

On very big project I’m not sure I would even recommend using groups, eventually as a last resort solution, because usually other systems come in handy to manage that in multiple contexts instead of a global thing.

And as usual, good organization always help. Separation of concerns, DRY, no script behemoths, contextualization (as opposed to all-global), generic/specific segmentation, sensible inheritance (though in my opinion it shouldn’t be abused, I’m not a fan of it^^)