When to use scenes versus scripts

    Each system’s capabilities are different as a result. Scenes can define how an extended class initializes, but not what its behavior actually is. Scenes are often used in conjunction with a script so that the scene acts as an extension of the scripts declarative code.

    It is possible to completely define a scenes’ contents using a script alone. This is, in essence, what the Godot Editor does, only in the C++ constructor of its objects.

    But, choosing which one to use can be a dilemma. Creating script instances is identical to creating in-engine classes whereas handling scenes requires a change in API:

    In some cases, a user can register a script as a new type within the editor itself. This displays it as a new type in the node or resource creation dialog with an optional icon. In these cases, the user’s ability to use the script is much more streamlined. Rather than having to…

    1. Know the base type of the script they would like to use.
    2. Create an instance of that base type.
    3. Add the script to the node.
      1. (Drag-n-drop method)
        1. Find the script in the FileSystem dock.
        2. Drag and drop the script onto the node in the Scene dock.
      2. (Property method)
        1. Select “Load” from the dropdown.
        2. Select the script from the file dialog.

    With a registered script, the scripted type instead becomes a creation option like the other nodes and resources in the system. One need not do any of the above work. The creation dialog even has a search bar to look up the type by name.

    There are two systems for registering types…

      • Editor-only. Typenames are not accessible at runtime.
      • Does not support inherited custom types.
      • An initializer tool. Creates the node with the script. Nothing more.
      • Editor has no type-awareness of the script or its relationship to other engine types or scripts.
      • Allows users to define an icon.
      • Works for all scripting languages because it deals with Script resources in abstract.
      • Set up using EditorPlugin.add_custom_type.

    With features like these, one may wish their type to be a script without a scene due to the ease of use it grants users. Those developing plugins or creating in-house tools for designers to use will find an easier time of things this way.

    On the downside, it also means having to use largely imperative programming.

    In the end, the best approach is to consider the following:

    • If one wishes to create a basic tool that is going to be re-used in several different projects and which people of all skill levels will likely use (including those who don’t label themselves as “programmers”), then chances are that it should probably be a script, likely one with a custom name/icon.

    • If one wishes to create a concept that is particular to their game, then it should always be a scene. Scenes are easier to track/edit and provide more security than scripts.