Also wanted to say thanks, I very much appreciate text over video
1 Like
It’s my pleasure!
hi and thank you for your work. ive been following your website for years, because of your work with the unity engine. ive followed all the godot tutorials so far and have been really enjoying it.
if i may make a few comments.
-
you seem to use _process() for handling input. there are dedicated methods specifically for handling input. this is much better for performance. in my case i use _unhandled_key_input() in place of _process(). there are few other variations as well.
-
in your latest tutorial, the pause menu one, you use add_child() and remove_child() to bring up and close the pause menu. i don’t entirely agree with this choice.
for a UI element that you’re going to constantly be using, it seems like rebuilding your front door every time you want to leave the house
these methods are fairly “heavy” in terms of performance.
for small things like a pause menu, removing it from the tree i think makes the potential for bugs huge. i’ve hit upon a few errors myself here (something to do with main.gd being an autoload), because i don’t follow your tutorials exactly line by line or 1 to 1, but definitely about 95% or so.i think it is safer to handle menus like this by using visibility:
- you get state persistence - if your menu has animations or sub-menus, removing it from the tree i believe would reset everything. simply toggling visibility on/off keeps the state intact.
- other scripts won’t break because they’re looking for a node that was orphaned. by working with visibility you avoid avoid referencing bugs
- just sheer simplicity. visible = true/false is just one line and very predictable
in my case i don’t check for input in pause_menu.gd at all. i just have a toggle() function that calls close_pause_menu() if the tree is paused, else activate(). then in main.gd i just call PauseMenu.toggle() from _unhandled_key_input(). i think it is maybe a bit messy to check for input in two different places here, when just one place will suffice
thank you again for your work and i’m eager for the next tutorial
You’re right that event-based input checking is more efficient for one-off actions like summoning the pause menu. I just stuck to polling for simplicity.
Add/remove doesn’t destroy it and doesn’t require rebuilding it. This just detaches the subtree from the root so it is fully inert. Stuff breaking suggests that there are undesirable dependencies and things aren’t modular. And yes, if you deviate then stuff is going to break because assumptions made will be invalidated when you switch approaches.
Also, this is a just minimal pause menu. It is introduction-level material.
Cheers!