I’d recommend create a bigger scene called
Game or something containing your level scenes and your timer.
Trust me, the timer is not the only thing you need between scenes (e.g. UI, music).
You probably want to test run a single scene with F6 at some point, that’s when singletons come bite back at you.
This is my scene tree for my games, been working pretty well, keeping singletons to a minimum:
┃ ┠╴LevelTimer # here's your timer
┃ ┠╴Walls # swap this out for another and you got a new level
┠╴TimeLabel # display your Timer.time_left
This looks incredible; but is not it a bad way to consume the memory of the PC?
Do a lot of scenes put together in the same file do not work too much in execution?
lucasfazzi | 2019-07-04 18:30
Could you please print your scene scheme, I’m having a bit of trouble figuring it out in Godot itself; I’ve always worked with separate nodes interacting via call them by code or singleton
lucasfazzi | 2019-07-04 18:46
Scene files are just text files so it doesn’t really add up to their sizes.
scene scheme, you mean how the nodes interact with each other (accessing data, sending signals)?
Dlean Jeans | 2019-07-05 04:19
By scene scheme I was referring to what nodes you use to make this unified mount. for example, by the “Game” scene I imagine you do with a Node; for “World” scene I imagine it to be a Node2D or 3D, depending on the game. Now for “Mechanics” scene I can not imagine which Node would be used; The same goes for UI … a Control Node?
I do not know if I’m being clear, but when I think of my separate scenes they have an end in them. For example, a “Player” scene would start with a KninematiBody, which would then go to a Node2D of the Level in question.
Now, if I had to subordinate these two to a superior “World” or “Game” scene, or even a “Player Control”, what would be the possibilities? Work with a lot of generic Nodes or is there a more specific way?
lucasfazzi | 2019-07-05 06:06
In fact, your method seems to be much better than mine. But is that as I never did, I was left with these doubts
lucasfazzi | 2019-07-05 06:09
World can be a
Spatial depending the type of game (2D or 3D),
World can be a
YSort in a 2D game.
Mechanics are the same (
UI is a
CanvasLayer so they’re locked in place.
World children nodes’ types depend on what you need:
Player can be a
Level can be many things from
Mechanics children nodes are invisible.
World children nodes are visible game entities.
Dlean Jeans | 2019-07-05 07:15
Thanks Dlean Jeans, now make much more sense to me; I’ll try your method.
Looks like much better than make a lot of singletons and loads.
lucasfazzi | 2019-07-05 16:56