Cygon
commented
6 years ago While I see that you put a lot of thought into this concept and do not want to devalue your input, I believe this design has been abandoned by modern game engines for good reason.
- Godot scenes already allow creation of custom nodes that can be arbitrarily simple or complex.
The scene tree panel has two buttons:
The first one creates a built-in node, the second one places another scene (= custom node). The window used to select another scene has a favorites list that allows the same two-click workflow possible with built-in nodes.
- When using inheritance in this manner, you invariably run into the "is a rectangle a special case of a square or is a square a special case of a rectangle" problem.
For example, which hierarchy is more correct?
- Entity
- FlyingEntity
- EnemyAirplane
- PlayerAirplane
- DrivingEntity
- EnemyTankor
- Enemy
- EnemyAirplane
- EnemyTank
- Player
- PlayerAirplaneIn one case, you duplicate the Enemy implementation (or write boilerplate code to forward to an external implementation), in the other case you duplicate the Flying implementation.
What modern game engines used to resolve this ambiguity is the "Composition over Inheritance" principle (https://en.wikipedia.org/wiki/Composition_over_inheritance) or more specifially, a "Component/Entity System" (https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80%93system).
This allows an entity (here = enemy/player on airplane/tank) to be composed of individual components that make up the entity. Godot has "optimized" its C/ES implementation by making both components and entities the same: nodes. So your entity would be the root Spatial node and the components would be some of the nodes below.
Unreal Engine 4 has attempted to support both C/ES and inheritance and, this is my personal opinion, ended up in a pretty poor place.
samdze
reduz
ghost
willnationsdev
Type1J
Shadowblitz16
akien-mga
This issue represents a whole new solution on how Godot workflow might work.
Keywords here are: semplicity, consistency, solidity, reliability, intuitiveness, naturalness, integration. Changes to the core engine are minimal. Some changes to the editor.
The general idea is explained here:
TL;DR; Replace the current "attach a script to an existing object" user approach with a more solid, simple, reliable, coherent and powerful "create new objects extending existing ones" approach to obtain custom behaviours.
1st part, workflow, here's a more in-depth explanation:
In my opinion, Godot needs an easy and quick way of defining custom types that act like built-in ones throughout the project. I used and created several game engines, and I have to say that I really like the core design of Godot, based on different types of nodes that are composed and combined to form trees structures. It makes very clear and immediate what is the purpose of every component of the game.
However: I'll say it directly, the entire concept of obtaining a custom behaviour only through a script attached to an existing engine node is not solid. To me, that is not what a full-featured, powerful and serious engine should be able to provide and decreases drastically the ease with which new features would be added. There's need for a more powerful, reliable and unique way to describe gameplay, tools and plugins logic.
The fact is, Godot has a superfluous concept: scripts that must be attached to a node; To do everything useful the engine is capable to do right now, Godot doesn't need an extra concept like that besides the core design solution: the Node. Nodes themselves can provide everything needed following the natural hierarchy that Godot defines. Scripts intended as objects that have to be attached to a Node are just one more completely avoidable extra complexity.
The issue is that Godot uses scripts (composition) to mimic the behaviour of inheritance. Doing that through "scripts that have to be attached to an object" only uselessly adds an extra layer of complexity to the user because no more than one script can be attached to an object: making in fact the extra complexity of having to handle composition completelely useless and worthless. Godot has a wonderful composition system based on trees of nodes, let's leave it there without touching nodes themselves.
How:
The solution is to encapsulate the "script" withing the Object class and to discard completely this "attach script to a node" user approach, making the user only be able to define new nodes (or in general, new Objects) inheriting existing engine-ones. (to the user eyes) From now on, I will refer to the concept of a script to attach to a node as "Godot Script", and I will refer to the new type of script that defines new node types as "Custom Node Script".
Every use case of the Godot Script will be covered, but this approach capabilities go beyond that:
No more "Attach Script" and "Clear Script" on right click on a node in the SceneTree dock (nor next to the "filter nodes" bar, maybe to be changed with a Change Type button). The "Change Type" option will be the only necessary one. Creation of new Custom Node Scripts could be provided adding an option to "Create New Node" and "Change Type" windows, allowing the user to create a new node extending the selected one providing file name and file path.
The only use-case not supported is the current "attach a script extending a node higher in the class hierarchy than the node it is attached to", however that's a very limited and not so useful use-case.
Now, talking about how to automatically generate custom engine-like nodes from Custom Node Script files:
The same solution also applies for Resources, they should appear and be created in the "Create New Resource" window and act totally like built-in resources to the user. (However, making clear that they are custom) Custom Nodes and Custom Resource names/identifiers should be usable like built-in types identifiers. (export variables, for example)
Considerations:
This system will make the creation of custom reusable nodes immediate for games, tools, plugins, etc. No need to simulate any corner case because the system itself would be specifically made to only support new engine-like Objects creation. The changes to the core engine itself would be very little, and if I were to develop the best possible engine, I would absolutely prefer this way over the "attach script to an object" one.
Support for the creation of custom engine-like nodes that are in fact scenes is natural and intuitive. Scenes created with a built-in root Custom Node Script would automatically be processed like Custom Node Script files by the import dock. Having the Custom Node Script built-in into the scene makes sure the Script (Node Type) is owned only by that specific scene, making Node Type -> Scene a unique correspondence. Such scenes become accessible and instantiable through filepath, through "Create New Node" window and through (custom node) identifier. This would be a very powerful feature, perfectly integrated into the new system.
One can still argue: "What changes or how it is better than the current system? This, that and the other things can be done in the current system too, so what's the point?" and that's probably correct. But here we are not talking about new things that can be done. We are talking about the convenience, the speed, the intuitiveness, the elegance, the solidity, the reliability, the consistency of how things are done. This is the whole point of a game engine. What can you do with a pre-made game engine that you can't do without? Nothing, you can write it yourself or develop a game without a clear disjunction between engine and game. It is all about convenience, speed, the power of doing the right things in the minimum amount of time. A game engine hides complexity and imposes constraints, but they usually are the RIGHT constraints, the constraints that permit a project to be built in a solid and quick manner. Ideally, constraints that enforce a structure that allows everything that should be doable, doable in a intuitive, quick and powerful way, and everything that shouldn't be doable, denied or redirected towards the right way that ensures solidity, productivity and organization. This is what this new system is all about. This system permits everything the old one does, but permits it in a way that offers much more solidity and convenience, also semplifying the user-level process. There are fewer components the user has to cooperate with, but the remaining ones allow him to do everything he was able to in a more intuitive way.
Note: the solutions just explained would become much less solid if the old Godot Script was mantained. Users could change the instanced scene root script (via editor or at runtime) and get a broken custom node, toghether with other similiar possible situations that are just not desiderable. Similar problems are valid in many other areas of the engine: everything that "composition simulating inheritance" offers more than simple inheritance is the possibility given to the user to make mistakes, only that.
The Custom Node Script approach provides just the right amount of control to the user to let him do whatever he wants reliably.
2nd part, cross-language support:
Regarding the implementation of this system in a cross-language manner: Every language module should provide a common interface to the core engine, which provides an interface itself, letting them define custom types through a unique entry point. Custom Node Scripts created with language A should easily refer to Custom Node Scripts created with language B and viceversa. There must not be the eventuality that some plugins remain unusable within a project that uses a different programming language. This is important to promote the creation of globally reusable plugins by the community: an engine that is hard/tedious to extend and to customize will never reach high levels.
Possible solution to interface different languages and make them communicate:
If this global registration of custom types is not possible or too complex it would be better to consider to not support at all other languages besides GDScript for plugins. GDScript types should however be visible by other languages.
7402 #17387 #17348 #13357 #6767 #6067