• Godot HelpGUI

  • Entirely menu/GUI based game: one scene and hidden nodes? Multiple scenes? What is the smartest way?

I'm in the starting process of making a menu style game in the vein of Kantai Collection or Touken Ranbu. Almost affectionately called a non-game. Everything is done via time gates, currency collection, crafting, and character collection.

I have no issues with how to make the systems of the game, but reading up on how to handle scenes has been very difficult! There aren't a lot of examples of games like this in Godot and I'm terrified of picking a way of menu swapping and sorting everything that ends up being super inefficient.

Things to know: each submenu would have considerable information/things to do in them. the main mechanic of the game are missions you send characters off on for x amount of time, there needs to be a global way to know when a mission timer is done. (a singleton could be used, but its something to consider)

Here are two layout use cases I'm considering, to give you an idea of how the game interface would function.

I'm unsure if it would be smart to make each menu a scene and deal with passing the information back and forth, but then I need to come up with a way of implementing the main menu through all the scenes.

Or having several control nodes, hiding and pausing them and having the main menu call them up?

There might also be a more efficient way than either of those?

10 days later

In Scenario 2, when player clicks on an object, a dialog box appears on top of all the objects. Maybe try instancing all the dialog box scenes as sub node to the parent scene?

3 months later

Maybe, the thread is outdated and your question is already obsolete, but my prefer is always work with subscenes instead of hiding/unhiding objects. So for scenario 1: Main Scene = Button List on the right side Subscenes = Options to open when clicking on the specific button

And for scenario 2: Main Scene = pretty empty frame maybe with placeholder containers for future objects Subscenes = Every Object with its option set in an own scene, you can then instate the object scene as a child of the placeholder container

2 months later

In short, I would go so far as to say that the benefit of Godot is entirely the ease of making multiple scenes, so to try and avoid that method of working is counter productive

Nice conceptual drawings. I don't know how far along you are, but I think the key to your answer is in understanding which Godot prebuilt classes are going to make your illustrations become game pieces fast, rather than thinking about how they fit together or developing based on efficiency. @kryzmak posted above me basically what I'm going to say.

We can break down your drawings and say very specifically what prebilt godot classes you should use.

! Image 1: ! ScrollContainer containing VBoxContainer shifted to right side of screen ! ! Image 2: ! A Control that contains TextureButtons or even Sprites that are used as buttons. ! ! Image 3: ! A PopUp scene. ! This being said, you should start by making 3 scenes, each based on the above prebuilt classes. Once you have these, godot's Scene Tree will let you switch between scenes entirely using change_scene_to, or in the case of the pop up window, it does what popup windows are expected to do and change_scene_to is not needed.

Efficiency of One Scene:

! To be frank it seems that when you suggest trying to fit everything into 'one scene', it suggests you are trying to be overly efficient from the beginning. Don't let this, (or anything else, for that matter), terrify you! LPT This is a mistake which can, and has cost me, years of development time, so its best avoided.

It is best that you build out and build out fast, making many many scenes, so that you can interchange them like puzzle pieces. Make copies using Save-As is your friend with Godot. Just build all your scenes and don't worry about whether it is 'in once scene' or not. UNTIL YOU HAVE ROUGHED ALL THE SCENES OUT (yes, more than one scene), do not pay attention to how they 'fit together'; it will work itself out. Once all the pieces are made available for you to use, you can figure out how to pack them and transition between them like fitting puzzle pieces together. Otherwise you very likely risk wasting time trying to fit things together that don't exist yet.

Globals:

! As for global ways, you can use Globals(variable_name). You could also use set_meta or set, and just use get_node() to find the node that has the script that contains your variable or meta variable that you can then reference from anywhere. ! You will have a main scene which will be get_tree().get_root().child(0), potentially, but using indices in this case can be meh not a good idea, so if you dont want to use Globals(), you can have your main scene set itself as get_tree().get_root().set_meta('main_scene',self) ! then refer to that

The timer:

! If you have a timer, it is most convenient to have a scene with its own script processing that timer individually. Of course it is most 'efficient' to only have one processor at a time, but it is easiest not to do this, and is fine as long as you're paying attention to how much each one is processing. ! ! So, when a mission starts, it can just add a scene that has a generic node saying, ! ready() ! set_process(true) ! ! process(delta) ! timerr+=1 ! ! If you find that there is another processor that isn't being used very much, just throw it in that script instead.

Anyway I can imagine some really cool character, card art appearing with your conceptual ability per your drawings.

5 years later