I'm pretty lost with the documentation about managing the overall scene structure and the example's I've looked at are either too specific or to general (ie the official documentation) so I'm hoping to get a starting point. Also, I'm not great with OOP and my programming skills are based on pre-OOP days (like scripting Matlab or low-level firmware for electronics kind of programming) but my game is simple enough that I didn't think I would have to embrace it at an overwhelming level.
My game structure is very simple: other than a 3D camera and a backdrop sphere to display the background there are no 3D objects.
What I would like to do is have a Main node to handle the game as it plays out. The game's visual are either a 2D node such as used to view the main menu or specific visual scene, or a 3D scene/node to display a panoramic view that only turns the camera. Game operations will mostly just switch between a 3D camera or 2D camera with little else going on except inputs and internal game-state changes. SUPER simple compared to the mechanics of the games see around I since there are no sprites or 3D objects.
(I should add that there will be a stack of 2D nodes for overlays that will always stay in the scenetree)
So something like: Main node always running. When switching between two 3D scenes, that will be handled by changing the attached script. Same with going between 2D nodes. When switching from a 3D to 2D or vice-versa, I imagine removing one from the scenetree and inserting the other and letting the attached scripts do all the work.
This is where it get's sticky: removing a subtree of nodes (I assume as a subscene if such a thing exists) from Main and replacing with another. I don't know how to do this. The scene changing documentation seems to change everything on the scenetree, not just a child scene (not even sure that made sense!)
Should I leave both the 2D node tree and 3D node tree in place and forget swapping anything except scripts and using scripts to disable one or the other child sub-scene? That seems memory intensive and more code present to manage.
Bolitho There are no subscenes in the scene tree at runtime. The concept of subscene actually does not exits except in the editor to help with manual arrangement of the tree. At runtime it's just one big "unrolled" tree. Once you instantiate some scene you get a "free-floating" branch of nodes. You can "plug" it anywhere into main scene tree by parenting it to any node, wherever you need it. In similar fashion you can remove any branch from the main tree by deleting the root node of that branch.
Leakage
Ah, thanks, that helps. I will mark this as answered even though I still have more to learn about making choices about my game structure for my particular project.
Bolitho Feel free to ask away if you have more questions 🙂
Bolitho like scripting Matlab or low-level firmware for electronics kind of programming
Oh nice! I studied a similar field (for CNCs), but I ended up doing web apps because I was scared I'd physicaly breaking something with my trial-and-error style of programming 😆 Good luck with your game!
*Edit: oops, I meant PLCs not CNCs
Hi! I come from a similar background as well (Matlab scripting and very-old-PLC programming) and I had to go through the same journey about learning to approach designs with an OOP mindset. My advice: Don't fight it. I lost a lot of time and effort with other game engines by trying to make things my way and reinventing the wheel instead of embracing the design philosophy intended by the engine. With Godot I decided to just surrender myself and it's been smooth sailing so far (though I'm not going to lie, it's taken me some time to be able to think in both ways in a comfortable way). I still rely a bit too much in inheritance, but I'm getting better 🙂
Anyway, good luck with your game, hope to see a demo soon!
© 2022 - 2024 — McMap. All rights reserved.