If you make an script like this:
@tool
extends CharacterBody2D
class_name Player2D
Then you can add a CharacterBody2D
to your scene, give it an script, and it is write this:
extends Player2D
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 EditorPlugin
s 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.