• Godot Help

  • Meaning of "Scenes as a Complement" Pattern?

So in an earlier doc-version, Scripting, I ran across this:

When designing games using the scene system, the whole project is fragmented into complementary scenes (not individual ones). Scenes complement each other, instead of being separate. There will be plenty of examples about this later on, but it’s very important to remember it.

For those with a good amount of programming expertise, this means a different design pattern to MVC. Godot promises efficiency at the expense of dropping the MVC habits, which are replaced by the scenes as a complement pattern.

So what exactly does that mean that scenes "complement" each other? I feel like it means that they are closely coupled - originally I was searching on MVC, which the docs basically say, "don't do that". And of course MVC is about decoupling functionality into different modules.

  • xyz replied to this.

    Sounds like a bit of meaningless fluff to me. Also, I am using MVC with great success in Godot.

      Zini
      That wouldn't surprise me, as I don't see anything like it the docs from version 3, onwards. But it's been a bit tricky sometimes, at building a "feel" for how nodes/scenes/scripts, really work together. I conceptualize Nodes as basically sort of mangled Objects, that you can add extension-methods with a Script, or compose from other Objects. And Scenes as Classes that get instantiated as objects. But then I read that - "scenes complement each other, instead of being separate" - and feel like I'm missing something. I mean, they are separate, that's the point, otherwise you'd have one long chain of nodes.

      Any comments on how you've applied MVC? Possibly posts/articles? So far, Godot just seems like the Model and View, are just very tightly integrated - how do you separate them out?

      • Zini replied to this.

          Crawfish The game I am currently working on is a RPG with full procedural generation and somewhat old style elements. It has separate scenes/maps for things like overworld exploration, area maps, towns, dungeons, battles (think games like Ultima up to 5). As such at any time only a small part of the world is in the scene tree. But the world state is still persistent across scene changes and the game sometimes needs access to objects that are currently not in the scene.

          I solved this by implementing the model with classes derived from RefCounted (or rather the Godot 3 equivalent of RefCounted). Every dungeon, town, creature, item, character and so on is an object of such a class. There is an autoload (WorldState) that holds all these objects.

          The actual scenes function as the VC part and do not contain any state (other than references to the object that they represent). The model objects communicate state changes to the scenes via signals (call down, signal up).

              Zini is there an advantage to derive from RefCounted rather than some other type?

              Its the bottom type for any object/class in godot, But for like resources, shouldnt resource type suit better than RefCounted ?

                  kuligs2 I used the simplest type that does the job. There are a lot of these objects after all and being efficient here is important. I even considered using Object instead as a base but decided that it wasn't worth the additional effort.

                  Resource on the other hand is bulkier than RefCounted and brings nothing to the table that I need.

                    Crawfish That paragraph just sounds like an attempt to defend coupling of data and its visual representation. Godot's scripted scene tree strongly nudges project architecture into that direction. MVC is kinda opposite of that. They just wanted to say that this coupling is by design/intent and it's as valid as MVC. Which I'd actually agree with. Imho each paradigm has its own problems/limitations.

                    Forcing full blown MVC organization onto Godot's scene tree may be disadvantageous on multiple accounts. However, Godot can be used without nodes and the scene tree, through a custom game loop and communication with engine's servers. In that case you have full freedom to organize the relation between data and visual representation any way you want. It's just not too wise to do this via GDScript as custom data management would require a lot of per-frame iteration that may end up being slow if not done in native code.

                      kuligs2 Use Resource only if you need to serialize objects to files. Otherwise RefCounted should suffice if you want your objects to be automatically memory managed, which in most cases you do. Otherwise use Object.