Arguably, more fun than writing code is removing code. I was assembling a split-screen multiplayer UI.
The goal behavior is to show/hide the appropriate displays for the players, depending on how many players there are.
Initially, the code to update the UI was very simple, because I started with two players. In that case, you can get away with just toggling the visibility of the second player’s display.
Once I added more scenarios, the code got lengthier. In order to support 0 – 4 players correctly, it ended up looking like this:
## Show the correct viewports based on player countfunc_update_player_viewports():match num_players:0:%HBTop.visible=false%HBBottom.visible=false1:%HBTop.visible=true%HBTop/VPC1.visible=true%HBTop/VPC2.visible=false%HBBottom.visible=false2:%HBTop.visible=true%HBTop/VPC1.visible=true%HBTop/VPC2.visible=true%HBBottom.visible=false3:%HBTop.visible=true%HBTop/VPC1.visible=true%HBTop/VPC2.visible=true%HBBottom.visible=true%HBBottom/VPC1.visible=true%HBBottom/VPC2.visible=false4:%HBTop.visible=true%HBTop/VPC1.visible=true%HBTop/VPC2.visible=true%HBBottom.visible=true%HBBottom/VPC1.visible=true%HBBottom/VPC2.visible=true
If you’re familiar with the match statement syntax, this code is really quite straightforward. It’s a bit naïve verbose, but it is easy to follow and structured enough to be readable. But could it be shorter? The cases for three and four players look nearly identical.
Sometimes it can be risky to refactor something verbose for a bit more brevity. Some solutions might end up being “too clever”. I try to aim for clarity first unless there are specific performance demands.
Usually, it’s a matter of how to approach the problem. The code above very clearly divides up the use cases. If I’m dealing with three players, I know I need to look at the
3:
block and that I can ignore the other blocks of code. It’s very light in terms of cognitive load.
This code snippet achieves that same behavior, but in only 8 lines of code instead of 30:
## Show the correct viewports based on player countfunc_update_player_viewports():%HBTop.visible= num_players >0%HBTop/VPC1.visible= num_players >0%HBTop/VPC2.visible= num_players >1%HBBottom.visible= num_players >2%HBBottom/VPC1.visible= num_players >2%HBBottom/VPC2.visible= num_players >3
But is it as intuitive?
The match statement is entirely gone.
Each node is updated exactly once (but with a boolean expression instead of a boolean constant; arguably less declarative and needs computation by the reader).
The order of nodes is specified so that the visibility is
true
until it’s
false
. Example for 2 players:
## Update the viewports to reflect the configured playersfunc_update_player_viewports():%HBTop.visible= num_players >0%HBTop/VPC1.visible= num_players >0%HBTop/VPC2.visible= num_players >1%HBBottom.visible= num_players >2%HBBottom/VPC1.visible= num_players >2%HBBottom/VPC2.visible= num_players >3
Well, it’s shorter anyway.
One final touch: I want to always show the first viewport, even when there are no players:
## Show the correct viewports based on player countfunc_update_player_viewports():%HBTop.visible= num_players >=0%HBTop/VPC1.visible= num_players >=0%HBTop/VPC2.visible= num_players >1%HBBottom.visible= num_players >2%HBBottom/VPC1.visible= num_players >2%HBBottom/VPC2.visible= num_players >3
I use an app called barrier. It allows you to share your mouse and keyboard with multiple devices. I use it, because I tend to have my laptop and Macbook sitting next to my PC, and it makes working across all devices very convenient. It’s a mix of a multi-monitor and multi-computer setup. Concept Your …
Godot Engine 4 has a bug (#50824) that causes particle jitter when the game is paused. It does look quite distracting. The Bug in Action This is a proof-of-concept wave shooter running in Godot Engine 4.0.2. Pausing the game was initially just a simple process_mode toggle. But as shown in the video clip above, there …
Right after I got my Steam Deck, I wanted to know how hard it is to get a Godot game running on it. What’s the developer experience for someone who’s stepping through this for the first time? It was really easy to do, so I’m sharing this here, whether you’re following along or like to …
Are you using @onready to reference nodes? There’s a better way! Here’s a simple example of how many tutorials use @onready to reference nodes: That script is attached to a CanvasLayer node with a ProgressBar called HealthBar. And yet, when running the scene, it will throw an error: This is because there’s actually a spelling …
A GDScript refactoring exercise
Arguably, more fun than writing code is removing code. I was assembling a split-screen multiplayer UI.
The goal behavior is to show/hide the appropriate displays for the players, depending on how many players there are.
Initially, the code to update the UI was very simple, because I started with two players. In that case, you can get away with just toggling the visibility of the second player’s display.
Once I added more scenarios, the code got lengthier. In order to support 0 – 4 players correctly, it ended up looking like this:
If you’re familiar with the match statement syntax, this code is really quite straightforward. It’s a bit naïve verbose, but it is easy to follow and structured enough to be readable. But could it be shorter? The cases for three and four players look nearly identical.
Sometimes it can be risky to refactor something verbose for a bit more brevity. Some solutions might end up being “too clever”. I try to aim for clarity first unless there are specific performance demands.
Usually, it’s a matter of how to approach the problem. The code above very clearly divides up the use cases. If I’m dealing with three players, I know I need to look at the
3:
block and that I can ignore the other blocks of code. It’s very light in terms of cognitive load.This code snippet achieves that same behavior, but in only 8 lines of code instead of 30:
But is it as intuitive?
true
until it’sfalse
. Example for 2 players:Well, it’s shorter anyway.
One final touch: I want to always show the first viewport, even when there are no players:
Related Posts
Share your Computer’s Mouse and Keyboard with your Steam Deck
I use an app called barrier. It allows you to share your mouse and keyboard with multiple devices. I use it, because I tend to have my laptop and Macbook sitting next to my PC, and it makes working across all devices very convenient. It’s a mix of a multi-monitor and multi-computer setup. Concept Your …
The Pause Handler: Working around Godot 4’s particle jitter bug
Godot Engine 4 has a bug (#50824) that causes particle jitter when the game is paused. It does look quite distracting. The Bug in Action This is a proof-of-concept wave shooter running in Godot Engine 4.0.2. Pausing the game was initially just a simple process_mode toggle. But as shown in the video clip above, there …
Running Godot Games on Steam Deck
Right after I got my Steam Deck, I wanted to know how hard it is to get a Godot game running on it. What’s the developer experience for someone who’s stepping through this for the first time? It was really easy to do, so I’m sharing this here, whether you’re following along or like to …
Ditch @onready, use @export instead
Are you using @onready to reference nodes? There’s a better way! Here’s a simple example of how many tutorials use @onready to reference nodes: That script is attached to a CanvasLayer node with a ProgressBar called HealthBar. And yet, when running the scene, it will throw an error: This is because there’s actually a spelling …