Thanks guys.
So basically if I create a scene ( not sure how to create a PackedScene ) for the player and another scene for a monster containing their setup and it accompanying script code. This would then be the equivilant of creating a similar blueprint of these in Unreal? I can then instance in a game/main scene 1 player "scene" and, say, 5 monsters from the monster "scene".

Should I then in future want to for example tweak the monster scene/script it will immediately be affective over all other completed game/level scenes without having to fiddle with those game scenes to affect the tweaks?

    Korax Yes. You can also add a weapon scene, powerup scene, elevator scene, explosion scene, hud scene etc... Everything is a scene in Godot 🙂 It's a collection of reusable nodes and scripts.

    PackedScene is a resource object returned by the engine when you load a scene resource from a script. You can call instantiate() method on such an object to instantiate the scene at runtime, for example when spawning enemies or explosions.

      Korax yes, you're describing Scene Inheritance. A developer can create a scene with common elements that is then used as a base scene (via Scene->New Inherited Scene) to create another, derived scene. Base scene nodes (etc) are present in derived scenes, while changes to the inherited (base) scene are then changed in a derived scene (unless overridden).

      For example, in this scene, I have a common 'Unit' that has a simple state machine that all (players and non-players) share. This scene is composed of other scenes too, as @xyz mentions. These are also inherited by a derived scene.

      Here's a derived scene, a skeleton!

      In the scene tree, elements that are inherited are greyed out, while this scene has its own elements (e.g. Move and Attack). Over in the Inspector, common elements have been tweaked and/or populated with derived-specific elements.

        I'm starting to get this. Many thanks guys!
        I think I need to practise creating these scenes even if they contain no actual logic, just to practise the idea how to slot these in together.

        My first try I was trying to create a scene I called "Entity", which seems to be similar to what you described as a "Unit". My thinking was to put everything common to any "Entity" into that scene object.. then from it derive/inherit player scenes, monster scenes etc.

        This "Entity" would then contain all common items like movement, gravity, lava kills it, acid kills it, can swim in water, but you can drown (unless overridden if you have aquatic monsters etc)

        Then once having these player & monster scenes derived off the base "Entity", pull those into the game scene.
        That was the thinking I used when trying to setup something very simple known near 0% of Godot.

        • xyz replied to this.

          Korax Be careful not to confuse script class inheritance with scene inheritance. You can have both in Godot and they are different things. While with script classes it may be practical to delegate a lot of shared functionality into very general base classes, with scene inheritance it's not quite that straightforward. Scenes are not just code and you can create a lot of bloat (and other kinds of mess) using deep hierarchies derived from too generalized bases. So starting with a general "Entity" scene may not be the best idea, unless all entities are very similar.

            Do you guys have a good link to documentation or a tutorial on scene inheritance? My searches both on Google and in the docs were failing badly. It seems like scene inheritance is a relatively new feature.

              award It was present in v 3. There's nothing to it really. Inherited scene, instead of starting blank, starts with node structure inherited from the parent. You can extend this structure by adding new nodes but inherited nodes are "locked". It's similar to putting a scene instance into another scene.

                award I think the first practical use of it that I read about was in this book:

                https://www.amazon.com/gp/aw/d/B0BVZVV67H/

                Where, IIRC, the tile project uses some common elements and scene inheritance. Although I think generally I agree that it can get overwhelming and best limited to a few common elements (that is, don’t try to be too clever). In the example I posted, the common Unit class knows how to navigate through various states and read a stats resource, while composition in the derived scenes adds instances of states. Another example is an asteroids clone (src) where all the moving objects can screen wrap so all the moving things (player, enemies, ‘roids) start from this base.

                Good book though, practical engine use even if it is a little outdated. edit: linked to new edition.

                tl;dr book has practical examples, keep it simple.

                  I agree with not trying to try create a hyper complicated hierarchy. Maybe just do a player scene and then the monster scene, even if they share common traits. Maybe I should not do a base "Entity" with all the common stuff for everything under there. Maybe rather a "EntityWalker", "EntityFloater" and "EntitySwimmer"... with these there will still be common traits, but at least those duplications are only present in these 3 (four if you count the player scene, which will be similar to "EntityWalker"). So the EntityWalker can have fixed settings/code for having fall damage set to true, where-as an EntityFloater wont have fall damage set to true and an EntitySwimmer cant drown.

                  Then one can use these 3 bases to create enemy types from, like an Ogre using the EntityWalker base, Dragon using EntityFloater and Piranha using "EntitySwimmer" and in the details (inspector?) one can then change the enemy-specific stuff like model to use, amount of health, collision box size etc. In you main scene you then create not the base scenes, but add the Ogre(s), Dragon(s) and Piranha(s) scenes.

                  Am I on the right path here?

                  Maybe thank to everybody helping here grasping the basics. 🙂
                  I was able to create multiple world scenes and was able to re-use the same player scene. This then enables me to just being able to design and code the player logic in a single place.

                  I'm still getting to grips with the whole interface, but I'm getting there. There is a ton of stuff I obviously don't know, but this answered my most worried question as I've seen a lot of tutorials just doing all the player/monster nodes straight into the main scene that had me worried that one has to do this from scratch for each scene.

                  I will post some screenshot results once I'm making some real headway.

                  It feels like out of the starting blocks... thanks for the patience... you guys are awesome. 😃

                  Its pretty dirty still, but its starting to work. 🙂

                  main scene:

                  player scene:

                  player code: (partial)

                  I was able to re-use the player across multiple scenes... exactly what I was hoping I can get working. 😃

                  ...small wins 😛