So I'm an old school Vanilla C / C# coder that has been developing engine upgrades for the Quake/IdTech engines. I'm looking at developing my first proper project on a new engine/platform. At the moment I'm evaluating Godot as well as Unreal Engine (not related to the recent Unity debacle). I'm slightly leaning towards Unreal, because I'm a bit biased towards my existing Quake knowledge. I'm not sure if I put this correctly.. English is not my native tongue.

Basically what I want to achieve with my test project on Godot is to be able to do all the basic Id Software mechanics as typical in Classic Doom & Quake. My biggest starting hurdle is understanding how I can setup and design the player object and a test monster object, if I can put it like that. I haven't yet delved that deeply into Unreal, but from the tutorials I've watched what I'm looking to achieve is what you can refer in Unreal terms where you create a "blueprint" of the player and a "blueprint" of a monster and use that in the game world where it references the blueprint (not copying it) to allow one during the development phase to update the player or monster blueprint which will then since its referenced, update across all worlds referencing the player/monster "blueprint". Similarly in Quake the monsters are coded in QuakeC or Vanilla C and tweaking the monster code and recompiling will affect all instances of that monster on any existing already compiled levels without having to rebuild the levels again.

Can a similar thing be achived with Godot?
What I want to achieve is creating a player object (scene?) and monster object and then able to reference thos and use them in a game scene with their setup being referenced and not copied to allow me to independantly update a monster without affecting any existing game scenes/levels thats already completed. Basically, I dont want to have to go back and do edits to completed game scenes.

  • xyz and Toxe replied to this.

  • 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.

      Korax Each game entity is best set up as a Godot scene. You can instantiate a scene at runtime (or in editor) as many times an needed.

        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 😛