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.

                              DaveTheCoder An analogy is building a dog house versus building a mansion.

                              Not to even mention civil engineering/city planning. As in coming up with a village plan/layout is probably way more forgiving than a city. But done right even a small village can benefit from a well thought through layout/plan.

                                I would recommend reading this book. That should give you the basics.

                                Thanks. It is C. Bradfield "Godot Engine Game Development Projects: Build five cross-platform 2D and 3D games with Godot 3.0", 1st Edition, Packtpub 2018.

                                For the people with tracking protection :-)