Every.
Single.
Time I get to the point where I need to start with a user interface in a game, it’s the beginning of the end for the project.

UI in game engines has always been a headache for me. I get why they are such a pain, and I know that every engine out there has done everything it can to alleviate the agony of having to provide interaction and feedback, but there still seems to be certain core truths that no engine has been able to get away from. It’s the nature of the beast, and I’m carrying two armloads of groceries through an unpopulated and undeveloped woodland.

My initial goal, now that I have my ship “colliding” with a planet, is to present the player with a message telling them to “Press ‘F’ to land”.

I have a scene called “F_HUD” which contains the label. Not a big deal, really, especially once I understood that all UI must be placed within the viewport rectangle. I had been trying to attach it to the planet, so mea culpa. It’s all good now.

This is really not a surprise because UI elements are designed to “float” above all else. They are usually not to be obscured by the game itself. In this case, I just wanted the label at the bottom of the screen, so I had to adjust it using the Layout button at the top toolbar, selecting the “Bottom Wide” option.

Now comes the fun part, and by fun, I mean not fun. I need to structure the HUD en toto so it can be responsive as needed, and reusable as needed. Right now, the “F_HUD” scene is a linked node within the Planet scene.

Reason being is because the enter and exit collision listeners are defined on the Planet script.

As this project is just for testing, I’m OK with this to get it started, but going forward, I need to decide, learn, or know some things about Godot’s “best practices”. The goal is to have the player enter a “sphere of action” like a planet or station and see the “Press ‘F’ to [Do whatever]”. They press “F”, so someone needs to answer that call; the “F_HUD”? The Planet? The player? In response to the “F” input, the HUD then shows a menu of services at that location. Who will “own” this HUD? Finally, because I’d really love to have everything about this be data-driven — something I haven’t even looked at yet, which is first for me on this project — I’d need to be able to access the data source and get the data where it needs to be. Ideally, I’d create one planet scene, one station scene, one asteroid field scene, and each one would have the particulars set by the data — is it a desert planet or an ice planet? Data. Do we sell Garuvian Wheat Husks? Data. What’s the price on a Starworx HL-9000 Overdrive Engine? Data. Who saw who whispering with the Ambassador from Suruk? You guessed it…data.

In the end there may not be a Godot best practice, and it might come down to personal preference. If I could get the planet to be the Mother of All Presentations then I would work with the planet, linking the “F_HUD” scene to raise signals to control the visibility of the “FACILITY_UI” scene which has links for the visibility of individual sub-scenes like “MARKET_UI” and “SHIPYARD_UI” and “BANKING_UI”. I could have of this contained within the Planet scene so that when I drop a planet scene into a Sector scene and define the PlanetID in the inspector, BAM! all of the data will fill the UI elements however and from wherever the data ends up being generated and stored.

I am stupidly optimistic right now because I have been able to do things in Godot which have taken me a hell of a lot longer to figure out in other engines in the past. I chalk it up in part to the fact that I have done this in other engines, so I kind of know what I’m looking at and looking for, but I can’t ignore the fact that Godot is pretty easy to understand. What I’m looking for now, however, is not a technical thing; it’s a practical thing, a best practice thing, so I don’t end up designing myself into a dead-end — as I have in the past — and get discouraged enough to abandon this current attempt — as I have in the past.