0 votes

so, I keep running into having to choose between doing multiple func calls and doing one LONG func call. For example:

# main script (called when item collected)
func update_UI() -> void:
    $User_Interface.update_stats_display()
    ...

# in User_Interface script
func update_stats_display() -> void:
    $Stats_Display.update_display()

# in Stats_Display script
func update_display() -> void:
    $Animal_Stats.update_animal_stats()
    $Human_Stats.update_human_stats()
    $Robot_Stats.update_robot_stats()

# in Animal_Stats script
func update_animal_stats() -> void:
    # do stuff here...
    ...

vs

func update_UI() -> void:
    $User_Interface/Stats_Display/Animal_Stats.update_animal_stats()

3 func calls vs 1 in this example. So... does it matter? Do each of those func calls take a "tick"? I prefer the multiple calls method because 1) it's easier to follow, and 2) it keeps things more "controlled". I have a dialogue box, menu screen, and stats display so far on my UI and they all control themselves, sometimes passing arguments, and are never controlled directly from anything outside of themselves.

I think of it as "I press a button on the clock, I don't change the time display with my fingers directly".

thank you in advance

in Engine by (35 points)
edited by

Tangential, but what do you mean by "my UI controls itself"? Its easier to maintain a UI when it is only a visual representation of the data contained in a separate model object/script.

I think I meant what you said.

My UI_Control has a small script to direct traffic, but it is the main hub for the UI b/c it's where I pause my game for the menu screen, dialogue box, etc. The UI is set to process when paused() = true.

as for the UI controlling itself, I mean that I will pass an argument (filepath) to my dialogue box, and it does the rest itself. it open, reads, and updates the display from the filepath passed to it. When done, it just sends a "dialogue done" kinda signal and shuts itself off. the UI_Control receives the signal and un-pauses the game.

same for the display. I just send the itemtype and itemamount arguments to an update function call, and the display updates itself with that information. for example, I never have the script for a world/level reach down through the UI and update the ItemAmountLabel.text directly.

so again, I think I meant what you were saying about separate module objects and scripts.

1 Answer

0 votes
Best answer

Definitely break things up into smaller functions.

Calling a function has an absolutely tiny overhead at run time. The sort of thing that's almost guaranteed to be unnoticeable.

Trying to develop / bugfix / maintain code that's all jammed into one incredibly long method is definitely going to be a pain in the butt. By breaking things into smaller logical chunks you're going to make things much easier on yourself.

by (182 points)
selected by
Welcome to Godot Engine Q&A, where you can ask questions and receive answers from other members of the community.

Please make sure to read How to use this Q&A? before posting your first questions.
Social login is currently unavailable. If you've previously logged in with a Facebook or GitHub account, use the I forgot my password link in the login box to set a password for your account. If you still can't access your account, send an email to webmaster@godotengine.org with your username.