How should I focus on making func calls effiecent? (are func calls like "ticks per second"?)

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By Kalmier

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:

# in User_Interface script
func update_stats_display() -> void:

# in Stats_Display script
func update_display() -> void:

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


func update_UI() -> void:

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

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.

Mitcha47 | 2020-02-06 01:00

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 _item_type and _item_amount 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 Item_Amount_Label.text directly.

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

Kalmier | 2020-02-06 02:21

:bust_in_silhouette: Reply From: MitchReidNZ

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.