If you make an script like this:
Then you can add a
CharacterBody2D to your scene, give it an script, and it is write this:
And it should work. You might need to add
@tool to it, depending on what you want it to do.
This has pushed me to make my scripts more reusable. As I often need to consider how to extend them other than adding an script to them. Some times that means creating nodes that expect to be placed as children of a node of an specific type. In other cases it means having a node interact with their children, or adding custom signals, or export nodes variables.
If you were to add the custom class via en
EditoPlugin with the now discouraged API
add_custom_type instead of using
class_name what you would gain is Godot preventing you from removing the script, and avoding a bit of namespace pollution. Which for me be too little gain for the hassle, as
EditorPlugins also need to be enabled in the editor.
However, I want to note that if you need custom behavior in the editor, you could create an
EditorPlugin that handles your nodes (for your case it could handle
CharacterBody2D for example), so the extra logic you need is not on a base class. While the
EditorPlugin won't execute in runtime, it can manipulate the scene in the editor, for example automatically adding other nodes with their own scripts, which would execute in runtime.
However, it seems you want to be able to add a
Player2D to the scene and have it appear without an script... In that case the
Player2D class must not be an script. Which at the time of writing means to either:
This would also allow you to avoid overload from the GDScript runtime. Which makes it a good idea for performance critical code once other avenues of optimization have been exhausted. Also since it is less attractive for quick prototyping, the usual advice is to design what you want with GDScript and then port it.