Does godot discourage oop ?

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By bob333

From the scene documentation Scene organization — Godot Engine (stable) documentation in English the following quote seems to discourage oop

One of the biggest things to consider in OOP is maintaining focused,
singular-purpose classes with loose coupling to other parts of the
codebase. This keeps the size of objects small (for maintainability)
and improves their reusability so that re-writing completed logic is

These OOP best practices have several ramifications for the best
practices in scene structure and script usage.

Later in the documentation the following quote encourages oop

Scripts and scenes, as extensions of engine classes should abide by
all OOP principles. Examples include…


I have watched interviews of game programmers interviews who are against oop for game development. What is the godot’s philosophy on oop for game development ?

I don’t see how you come to the conclusion that the first quote discourages OOP; in fact I think the quote encourages OOP best practices. The text surrounding the one you quoted talks about how scenes shouldn’t have dependencies if possible - e.g. avoid strong coupling and be self-sufficient, which is also an important aspect of OOP (encapsulation etc).

archeron | 2020-06-04 21:48

I think the confusion stems from the word “ramification” which is similar in meaning to “consequence” but usually implies unwanted or annoying consequences. That’s just a poor choice of words though: I fully agree that the overall sentiment of the quoted paragraph (and that part of the documentation as a whole) is pro-OOP.

njamster | 2020-06-06 10:47

:bust_in_silhouette: Reply From: Kanor

I am not one of the engine maintainers, so my answer may not reflect the opinions of Godot’s creators, but Godot’s node hierarchy is based on Unity’s object hierarchy, which is object-oriented by design. Instead of thinking of objects as lines of scripts, you should think of objects in terms of each Node, which has an array of “children” nodes and other goodies.

Godot, like Unity, thrives on object composition rather than inheritance, and it’s best to adhere to that as much as possible. For example, I use a script for simple Node2Ds that I add to enemies to give them boss-functionality (such as opening music and a life bar). I usually just add a Node2D child to the enemy and attach the script. By using node composition, I have a decoupled the functionality for a moving body and its boss-status. This is the goal of OOP, and Godot makes doing this extremely easy.

I found a nice forum post on this about Unity, and I think it applies to Godot as well:

There’s a lot to be said for functional programming, or even data-driven models. This is just my two cents on how Godot lends itself most for an OOP approach.

Plus: GDscript doesn’t lend itself to the functional programming paradigm at all. Functions are not first-class-citizens in GDScript, for example. You can pass around function names as strings, but you can’t pass around actual function objects, which is a requirement for serious functional programming; and you don’t have important functional tools such as map, filter, apply etc. You could implement cumbersome variants, but it’s clearly not something that GDscript is good at.

archeron | 2020-06-04 21:55