It doesn't say a scene is not a class, because it is, the root being SceneTree.

We must distinguish between the representation of data and that of programming logic, and what's inheritance and what is composition. A lower node in a tree of inheritance inherits from the upper levels, but can additionally (or replacing) have other traits. See a script like an object being attached to a node in the SceneTree, but not inheriting from the node itself. Or, more abstract, a representation of the behaviour of an object in the scene tree.

In OOP the ability to store a script can for example be realized by storing what's called a pointer to a data structure representing the script, or even to a chain of such structures. This ability itself can be inherited from the root all the way down, but what is actually connected to this pointer (or whatever method is chosen) can differ.

Like you can have dad being a merry fellow with a blue hat and yellow boots (hello Tom) and his son being more down to earth wearing sandals and a baseball cap :-). Yet still both are humans and one inherited from the other, with different scripts attached for mood and clothing. They even can change their scripts, by changing their minds, but they can not escape the tree of inheritance. Same with OOP inheritance and composition.

Hope that wasn't totally incomprehensible.

Thank you for the explanation, however regarding the documentation honestly seems too confusing to me in a general sense I mean

Don't get hung up on little details like that. What matters is if you can use scripts and scenes to build a game.

Yeah, some things are confusing to newcomers in the documentation.

A scene can be best thought of as a composition of its true object set (ie the Nodes it is composed of). Nodes are true OO, because well, they are C++ classes underneath.

A script attached to a Node type should be considered a decoration adorning an object instance.

For example, you are a human (a class) who can put on hiking gear and become a 'hiker'. As such you have some boots, and a tent, and a camping stove etc. So while you can think of yourself as hiker as a class, the script is only an adornment on an instance: A hiking 'script' could also be attached to a humanoid robot and it too could have all the attributes of a hiker and here we note that a Hiker could be-a human or could also be-a robot.

Because GD script is duck taped, binding a script to a node is only really constrained by the base type it can be bound to (ie extends Object, Node or Node2D). Scripts can be bound to any sub-class node of the one its (root-base) script extends.

Thus scene tree objects and the scripts attached to them are not the same thing, say like in Unity where you subclass a traditional Object.

Further scripts can inherent from each other so in that sense scripts can be seen an object oriented, but much of their true nature is related to the specific node type they are bound to.

A class is just a thing. For example, an animal is a class of living beings. And a cat is a type of animal, it is also a class of beings, and a child of animal. A car is a class, as a type of vehicle. A plane is also a class, as is a tank, and they are both types of vehicles. In fact, almost anything can be a class, if it has a name and represents something. Food can be a class, sushi (inherits from food), pizza is a class. Basically whatever you want.

The script is a class that extends a node. So you customize nodes using scripts.
I see scenes as a different paradigm on top of nodes. IMO Godot is not fully OOP.

Right, Godot is not exactly real OOP, so you don't have to bother learning what it really means (and it takes years to actually understand OOP). The only thing Godot uses is basically classes and inheritance. A class is any type of thing (which is basically any concept that can be named). And other classes can inherit from that class, as a specialized type of thing. That's all you need to know.

  • Byl replied to this.

    cybereality Ok guys what I understood in all this talk is that as cybereality wrote : Godot is not purely a software that "stores" OOP, but that it only makes use of "classes" and "of inheritance" and these two concepts in Godot are not completely related to pure OOP as for example "Java". If I am wrong please correct me.

      I think what cybereality meant by "Godot is not exactly real OOP" is that it doesn't let you fully encapsulate objects in the way that object-oriented languages usually do. But I might be wrong.

      Hehe, semantics, I love it :-)

      @Byl : I'd say just play around with the editor, plant nodes, set them in a meaningful order, attach scripts to make them jump around or whatever, you get a feeling of how things work together. And it actually doesn't matter if that's an ECS whith components stitched together below or an OO-approach with a scene-tree of nodes and inheritance and sideways attached scripts.

      At least not at an entry level.

      Have fun :-)

      • Byl replied to this.

        Pixophir Whatever, guys, in conclusion you are telling me that I don't have to think about OOP with Godot and that I just need to "get my hands dirty" with the editor and see how it all works...

          Yeah, I believe the docu page was written for people with a foot in programming, specifically C++ or C#, and/or people who had contact with unity before.

          If we take a look at unity there are objects placed and then components attached, while in Godot there are nodes placed in a hierarchy. Both, components and nodes still need tweaking of a bunch of parameters, but the basic structure between the two approaches is somewhat different. But let's shrug that off and make games :-)

          So OOP can fill entire books. But there are 4 main tenets. Inheritance, encapsulation, abstraction, and polymorphism. Inheritance is just the use of classes and objects, which can have bases and children, which Godot supports. Godot also supports polymorphism in some limited sense, in that child classes can override methods in base classes (though in a language like C++ or Java you can do more). However encapsulation and abstraction are totally missing in GDScript (though I guess could be used in C#, I haven't used it much). This is where you can define interfaces or custom APIs for your object, such as with public methods. Languages like C++ have everything private by default, meaning objects cannot access properties of other objects without permission. This is very useful for organization and design, and keeps code cleaner. It is not 100% needed, you can write games without it, but it helps with more complex design. But, to be honest, people have been moving away from OOP in games in particular, because you end up wasting time designing things that aren't necessary. So with game scripting it is not the end of the world, and you end up writing games faster without OOP. And you don't even have to learn it to make a game. Especially for simple games, just using inheritance may be enough. Only if you were writing like The Sims or something, you would need a complex design.

          • Byl replied to this.

            cybereality So you're saying that for simple games you don't need to learn OOP, whereas you do for more complex games. But another doubt arises for me that is : shouldn't the more complex games from the way you described it, have let's say the same "structure" as the simpler games? I mean, without using OOP?

                Byl But another doubt arises for me that is : shouldn't the more complex games from the way you described it, have let's say the same "structure" as the simpler games? I mean, without using OOP?

                It is useful to study it. Use it if necessary, but you have to know what it is and why it exists. There is a book called Game Programming Patterns. It's free. It deals with this question.

                • Byl replied to this.

                    Tomcat Is that supposed to help me get a good understanding of how Godot works?

                        @Byl : @cybereality said you need "more complex designs" for games like The Sims than for simple games, and she certainly meant much more than OOP which is just one tool in the box of a programmer.

                        We can't explain in forum posts what we've learnt from books, study and experience in several years. All this is understandably just as confusing as it was to me a few years ago.

                        You really need to cast away your doubts and stop confusing yourself, and do a simple game with the help of the documentation (Edit because ninja'd: ... to understand how Godot works ;-)).

                        Btw., before diving in such design patterns they need to learn and have some experience with C++. C++17 and on doesn't need many of these patterns any more, some of them being just crutches and others as trivial as a main loop. They were never set in stone, and they may be outdated by now.

                        Byl Is that supposed to help me get a good understanding of how Godot works?

                        This will give you a better understanding of programming in general and OOP in particular. Godot is a particular case.

                          Byl So you're saying that for simple games you don't need to learn OOP, whereas you do for more complex games. But another doubt arises for me that is : shouldn't the more complex games from the way you described it, have let's say the same "structure" as the simpler games? I mean, without using OOP?

                          Ideally, the same principles apply to all coding projects, big or small. But in a small project, you can get away with sloppiness, while in a large project you have to be very organized.

                          An analogy is building a dog house versus building a mansion. In the former case you can start nailing boards together without any planning and probably wind up with a reasonably acceptable result. In the latter case, you'd have a mess.