Replacing GUI with GO

Questions
#1

More and more, I’m having trouble really understanding the paradigm of separating GUI and GO components in Defold. GUI has a few extra features like Slice-9, but for the most part they’re the same. You could simply use label components, sprites, etc and draw them using a secondary camera.

I’m thinking of replacing my GUI stuff with GO so that I don’t have to make two separate scripts that talk to each other by passing messages or using a module as a middleman. Is there any significant disadvantage I haven’t thought of here, or does anyone else do this in their projects?

1 Like
#2

Never used GUI. Also in my game https://www.youtube.com/watch?v=7c877KURdOg&t=10s released for Swicth and mobile, only GO.

1 Like
#3

How can you manage your GO (as GUI) stuff if your camera moves to follow character for example? I guess you need to customize your render script?

I think GUI has its own conveniences. For example you can create new nodes easily just by gui.new_box_node(), that helps expanding stuff dinamically much easy and flexible. For now with GO, we must define many things for spawning and we can not create a new sprite?
It also has stretching mode which can move your stuff to coners, make it a good option for responsive. It also has better parent-child management.
I remember for GO, when I enable/disable a game object, it actually enable/disable every its sprites. That’s quite inconvenient when I want to keep some sprites not enabled

In the future, GUI can be replaced by some new GO propertise or a new Layer object type but until now it’s still good enough for my such simple 2D game :slight_smile:

2 Likes
#4

Can simply use a second camera that doesn’t move and uses a projection that mimics the standard GUI projection. You’d likely want to customize your render script at some point, but from what I remember, I think multiple cameras are supported without an extension but I could be wrong.

#5

Yes, you can very easily add a screen space camera to the render script and draw all your gui-GO’s with a dedicated predicate. Of course you have to manage yourself all gui-GO’s as @Chung_Xa pointed out, but I prefer to write some more code for GO than to learn GUI api. Clearly this is just me and my choices :slight_smile:

#6

We want to move away from the GUI as it works now and have a unified solution in the future. It will take some time before we have this in place though.

But like you say a lot can be achieved using go already. I’ve played around with something like that myself, and I think you can do a basic UI using game objects.

2 Likes
#7

Funny, I started a message about that last day, and deleted it to try something else (failed).

I completely support an unified GO system. I’m just now sweating blood at trying to make my game understand when, for my 4X pet project, a click on a star open (enable) a GUI box on a fixed position, meaning not always on top of the clicked star, I don’t want the stars hidden by the GUI to react on click, but I still want the others to do it.

I can’t use collisions because Gui don’t use it apparently, “consume” blocks all next inputs for… reason, Gui script can’t tell GO script to not activate its on_input stuff because on_message is run after on_input…

There is probably a solution, but I’m more a dev that a coder, and it’s really difficult for me.
While it would be a breeze if Gui and Go could be unified : Just a list of “if then elseif…” in my central input script.

I’m going to see how that "zoomy moving camera for game and fixed 2nd camera for GO used as Gui works).
If people had links, it would be appreciated.

#8

I guess you are missing return true for GUI script on_input to prevent passing clicks to under it if you don’t want.

#9

I don’t have to make two separate scripts that talk to each other by passing messages

script shared state exists and largely makes this not needed. why is this not possible here?

Is there any significant disadvantage I haven’t thought of here, or does anyone else do this in their projects?

the biggest benefit gui has right now is that you can do it all in code with next to no setup, which makes it realistically the only option for some applications (eg, dynamic code which generates dynamic UI). Currently, you cannot attach components to GOs which have already been created*, nor can you create prototypes at runtime*, nor make copies of a GO without a factory either*. In order to replicate the behavior of new_box_node or new_text_node, you have to separately create GOs with relevant properties (eg, a sprite or label) before compilation and make.

there’s also render convenience, GUIs are always drawn on top of everything else and will always remain locked to the screenspace and you won’t have to mess with render scripts to get the same behavior

i guess there’s also gui.pick_node, too, which is a very nice function to have to use for interactions that i don’t think there’s an equivelent for that with GOs without making your own function

other miscellaneous reasons for using GUI:

  • pivots, which are useful for laying out components.
  • gui has clipping modes, which can only be done with shaders in sprites*
  • setting textures during runtime is far easier in gui than go (niche applications).

*to my knowlege, this may not be true,

#10

What is the use for pivots since you can’t add Collisions Boxes for Gui elements, even with a Sprite present ?

Or can we ?
I don’t understand why the manual use the character sprites from the example collision boxes (you know, the bean with his shield that fight a trash bin) in the Gui pivots examples.
If we can put Collisions on some elements of a Gui (like, the simple standard Box), it will resolve my problem completely, since my cursor has collision box : I could just make the Gui element collisioned by the cursor send a message to the Cursor script, saying “hey, you collisioned me, you stupid moron ! Here’s my ID. Will you assume your actions, now ?”.

P.S. Shared states ? Will look at that.

#11

Very interesting that people don’t use GUI that much. I do the other way around, all of the released games/apps I have made (as a hobbyist) use 100% GUI. And 90% of all my tests and prototype are also only in GUI.

4 Likes
#12

I too make heavy use of GUI, @CrazyAmphibian 's post summarises the benefits well. Core gameplay is all in game object space, but for menu and UI and dynamic stuff like cut scenes I love working with GUI.

1 Like
#13

I make use of both of them, the amount of GO or GUI depends on the project. But I’m looking forward for an unified solution with the best capabilities combined.