Is there any rule-of-thumb to decide if a script should be embedded to the scene or should be a separate .gd file?

Archive
1
:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By chexmo

I think the title is very descriptive…
I’m currently using only the .gd files because I learnt to do so in the tutorials I followed, but I think the idea of a scene that encapsulates its own script is at least interesting.
I can see some corner cases in both options, but I can’t tell which one is better when.
For example:

  • If you use .gd files…
  • Reusability. You can later use the same file in other scene that behaves the same way. Or even in a different project.
  • Scripts keep available from external tools, maybe.
  • File structure grows up to x2 faster.
  • If you’d like to use the same script in two different scenes you may have to deal with different child-nodes maybe, and handle stuff of both scenes.
  • Less OO design/architecture, IMHO. For instance, although you can inherit one script from other via GDScript, it feels forced compared to godot’s scene-inheritation feature.
  • If you use embedded scripts…
  • To tidy up the files structure seems easier.
  • Scenes made this way are not only a compound of states, but entities with their own behaviours now… which for some reason I feel more semantic that attaching scripts here and there.
  • You only can edit code properly from the godot editor, and even so IDK if godot text editor fully supports this feature nowadays.
  • Too much info in a single place. Breaks the single-responsability principle.

So…
Tell me…

  • What you think about this?
  • How do you work scripts?
  • Is there any rule-of-thumb to decide if a script should be embedded to the scene or should be a separate .gd file?

Thanks

2
:bust_in_silhouette: Reply From: Lopy

If it exist, it means that some people use it regularly. I would recommend against using builtin scripts. Here a a few reasons in favor of having separate .gd files.

  • Script reuse : To put a generic script on many different nodes.
  • Mass file operations : from simply counting your scripts to managing a license header.
  • Access : You can open your file from the FileSystem dock on top of the scene tree editor.
  • Extra features : Things like class_name, or non-node classes like Ressources. Even if you only use them rarely, using builtin scripts would mean dealing with two types of scripts.
  • Peace of mind : I had a some .scn go corrupt. Even if it unlikely, having separate .gd feels safer.