• 2D

  • Change UI of game from light mode to dark mode

So I have a concept for a word game I am working on. And for the general feel I would like to have dark or light UI elements. I know for my buttons etc I can create texture buttons so they can have particular images at hover, pressed etc but how do I have 2 hover images for example one for light mode and one for dark mode? Is that possible or do I have to have 2 different nodes, one light and one dark which get changed at load?

What I've done is just swap the texture on _ready based on whether light mode or dark mode is being used. This doesn't allow for dynamically changing between the two at run-time, but with a quick restart it changes the color scheme. Not sure if its the best way to handle it though, but it seems to work okay in the project's I've implemented it in.

@Megalomaniak would themes work properly if you are using images? I am not using internal styling but prefabricated images for the buttons

Haven't explored that. Either ways I think you'd need to implement some sort of minimal state machine that changes the UI/theme related nodes out. If you design it right it should probably be able to change it without needing a restart too. Basically a Autoloaded UI manager that loads a relevant UI node set according to the UI setting/state.

@Megalomaniak I was thinking of this but it would be swapping the icons/textures/sprites out rather than nodes since I don't want to have duplicate nodes that do the same thing. Considering settings can be changed mid game I would need whatever method I come up with would need to change simultaneously. How intensive is the process method? Particularly when you have a lot of nodes running it on one scene? Because one way of doing it I think would be to have an autoloaded script with a boolean for dark and light and then within the process method of each UI/theme related node it simply checks what state is running and change if need be. It simply passes if there are no changes to be made. My worry is that for what I have in mind there are times when the scene is full of theme related nodes and the _process might be intensive enough to slow things down. (Not sure about Godot's performance. I am new here and I used to use an engine whose performance for something could be a disaster if you didn't do things in a particular way)

and just using a animation player???

@fmakawa said: @Megalomaniak I was thinking of this but it would be swapping the icons/textures/sprites out rather than nodes since I don't want to have duplicate nodes that do the same thing. Considering settings can be changed mid game I would need whatever method I come up with would need to change simultaneously. How intensive is the process method? Particularly when you have a lot of nodes running it on one scene? Because one way of doing it I think would be to have an autoloaded script with a boolean for dark and light and then within the process method of each UI/theme related node it simply checks what state is running and change if need be. It simply passes if there are no changes to be made. My worry is that for what I have in mind there are times when the scene is full of theme related nodes and the _process might be intensive enough to slow things down. (Not sure about Godot's performance. I am new here and I used to use an engine whose performance for something could be a disaster if you didn't do things in a particular way)

I think that should work, swapping out the textures/icons/sprites. If you are using an autoload script, what you could look at doing instead of checking in _process to tell whether to swap the visuals is using a custom signal on the autoload. Then you could have each node connect to the signal and whenever you change the theme from dark to light or vice versa, you could emit the signal to tell all of the nodes that the theme has changed and that they need to update. Then it shouldn't be too performance heavy, as the nodes will only change their visuals when the signal is emitted.

You could also do a condition in _process like you were saying. As long as there's not too many conditions per node, the performance cost probably won't be enough to be noticeable. Especially if the code checks to see if a change is needed and passes if there is no change, it should probably be performant.

6 days later