in the Godot game engine version 3.x and 4.x series there is the capability to assign a class_name to a script
this tells the engine to load that script into a global of the same name automatically as if it were a class to be instantiated, it is a little weird but it is a nice feature
You can give your class a name to register it as a new type in Godot's editor. For that, you use the class_name keyword. You can optionally use the @icon annotation with a path to an image, to use it as an icon. Your class will then appear with its new icon in the editor
- official Godot stable documentation
until you try to do literally anything with a class_name script which treats then like a class
when is a class name not a class name?
when it is neither a class nor a name!
see, because class_name does not set the class nor the name
you cannot even reflect on the name of that class, you will always get the name of whatever the base class it extends instead
it also does not allow you to compare instances of that class separately from the base class
you get the global and the autoload functionality and that is it, the rest of the class features you have to implement by hand yourself, and due to limited metaprogramming features in GDScript, you pretty much have to copy and paste the code that implements those features everywhere you want to use them
long time coming
there has been an issue open since 2018 asking for a fix and there was for years no documentation explaining that get_class() or is_class() ignored class_name
it is only if you know to check the footnotes of the functions themselves that you would learn that additional tidbit - and that was added much later
in fact, the quoted documentation at the top is pretty much the entire documentation for class_name as of today
in December of 2023 this one line change adds an unintuitively named method get_global_name() which finally allows scripts to obtain the string representation of the class_name (or fallback to the parent class name)
this change is not part of any released version of Godot despite being added 4 months ago (at the time of writing) because it is slated for release version 4.3, while 4.2.2 is the latest version only just made public last week
judging by the release process of other point releases, we are probably on the final dev preview but there will be anywhere from 3 to 5 more beta releases and at least a couple release candidates before the official release
i have no complaints about a rigorous testing and rollout cycle
just that the one line of code has taken over half a decade to get through the approval pipeline and and it still does not include any support for type comparisons, so you will have to keep using string comparisons or rolling your own type system and to me that is just very silly
type systems
and i get it, type systems are hard, but looking at the dozens of issues and proposals around the topic....
oh, you did not think it was just the one pull request? no there is a whole ecosystem of people trying to get the core team to accept literally anything other than the nothing that GDScript currently supplies
....but while the type system could provide a solution here, it is not necessary
after all most people are just doing string comparisons right now and are just asking for something moderately more ergonomic than that
forward complaints to the dead letters department
is this some kind of deal killer? no!
there are workarounds, it is just a wildly inefficient waste of everyone's time that it is still a problem, and will continue to be probably for years to come!
of the game engines i have research and/or tested (around 35) i still quite like Godot and will continue to use it
however, the more i write about it the less likely i am to forget about these subtle issues and end up burning days in the future trying to debug why my game is busted
and hey at least it is not Ink!
