Hello, I understand this might be a broad-ish question so I’m looking for some pointers.
I’ve got a collision object following my cursor, with the cursor sprite changing if it’s colliding (aka mouse is above a ‘clickable’ object), and I’ve created a simple menu with the options as GO with collision objects: ‘Start Game’ and ‘Quit Game’. I’ve got that working.
Now I’m trying to add a popup menu that appears when I click 'Quit Game’, just a simple ‘Confirm you want to quit game.’ with ‘Yes’ and ‘No’ options. I’ve created the popup menu as a separate collection and I’m using collection factory to create it when I click ‘Quit Game’. The problem I’m encountering is that I can still click things behind the popup menu. I understand if I have multiple clickable objects I can compare z position, but in this case the popup menu doesn’t have a collision object, so the cursor is only colliding with the button behind the menu.
Is there a function to check for the sprites at the mouse position? Should I add a collision object to the whole popup menu just to block the buttons behind? Any advice for how to tackle this? Thanks in advance!
If you want to make this work with game objects in 2D, including objects colliding with other game objects in the collection below, I think the easiest solution is to assign different collision groups to the in-game objects and different ones to your GUI popup, for example. That said, this is only one possible direction - a lot will depend on your implementation, such as what is handling the collisions, and so on.
Different collision groups is a good idea! Creating an additional collision group and hardcoding to give it priority seems like a quick easy way to solve one of my current problems.
The reason I’m not using GUI is (1) My game is a menu-heavy, point and click game so I don’t want to handle two different sets of logic and game components, and (2) most tutorials focused on how to use GO and only simple GUI as HUD so I decided to go with pure GO for my game.
I’ve not heard of consuming an input before so thanks for the link! I’ve had a read but I only have the one cursor script that handles input so I don’t think its applicable in my case?
Now I’m thinking if I should spawn in another cursor that only interacts with the popup menu… I have a feeling its going to cause problems but it’s something worth trying
So I’ve tried to create a new ‘gui’ cursor when I create the popup menu collection, and it seems to work, but theres another problem: I’ve re-use the same cursor.script for both normal cursor and gui cursor, and I thought I could just add an if statement for the gui cursor, except I can’t figure out a way to check if the GO it is attached to is the gui cursor or not.
Using get_id I can see this:
hash: [/core/cursor] –normal cursor
hash: [/collection0/confirm_cursor] –gui cursor
However, I don’t think there is a go.get_name() function and I can’t use substring comparison on hash, so is there someway to get the ‘collectionX’ part? Or am I over-complicating things and theres a simpler way to do it?
I think you are overcomplicating things not using real GUI…but anyway, you can add a script property like “cursor_type” and set it a different value in the outline panel for each instance, then check the value in code with
If self.cursor_type==1 then
…
elseif self.cursor_type==2 then
…
End
So the reason I’m not keen on using GUI is because I made a simple noughts and cross game with pure GO vs pure GUI, and pure GO seemed more flexible. It was some time ago so I made a quick new project to test out GUI. Admittedly I didn’t spend too much time, but even in the new GUI only project I was encountering the same problem with overlapping buttons and clicking buttons underneath the popup menu.
I think what I needed to do was to have the GUI script consume input but again, I don’t really see any compelling reason to switch from pure GO to pure GUI?
Thanks for the go.property suggestion! I was under the impression that since I’m using the same script in two GO, the go.property will be the same, but apparently not!
I duplicated the cursor GO because I thought it might be easier to differentiate them, and because I’ve given them different sprites (so I can tell what’s what), but if there’s no benefit I’ll happily stick to just one.
I was hoping I could check for gui_cursor but I guess the other way round works too.
I also just found out I can change the collision group during runtime, so that’s something I’m going to try as well.
I see multiple compelling reasons in the discussions above… but it is of course possible to do with game objects, it’s just that it’s a bit more complicated as you’ve already discovered.
Take the time to learn how the GUI functions, it’s worth it. Experiment with the info given in the manual and API, and look up some other tutorials if you want. You’ll have another fundamental game dev tool at your disposal.
That’s just the intro page, if you look along the side it’s got a page under the GUI heading for each type of element (text nodes etc) literally you will be using Box nodes and Text nodes for 90% of your work because boxes can become images, 9 slice backgrounds for encapsulating menus and text in a flexibly sized bordered background.
I would say the biggest thing to get your head around is that all GUI’s are one single script file, combined with one GUI collection made of manually placed GUI nodes and re-usable GUI templates, for repeatable things like buttons etc. which you can duplicate in script. All of the above will help with your menus.
So to get re-usable behaviour, you can make lua modules or re-usable functions (however you want to do it) and give them an absolute path to an element to use as a reference node to duplicate, that’s how you make a list of menu buttons based on data you supply. Or you could build each menu manually if you prefer, and pass the code the individual urls to the manually placed buttons.
It’s funny because it seems restrictive at first compared to other engines but it’s because it’s very optimal. Once you get down to it you still have a lot of ways you can go about it once you understand what you have to work with.
Maybe you could roll the dice with ChatGPT or Gemini and see how far they get you
@britzl
I’ve re-read the posts above but I don’t think anyone actually mentioned why I should use GUI instead? Just suggestions that I should use it. Maybe I’ll see why when I spend more time on GUI, but one thing at a time for now.
@PendragonNL
A simple game made with pure GUI would be great! Maybe a remade of the tutorial colorslide game with pure GUI?
@Domarius
I’m not saying I’m never ever using GUI, and I have gone through the manuals and APIs before (see "previously made tic-tac-toe with pure GUI), its just that I don’t see the benefits of using GUI right now for my current project. (You’re welcome to change my mind though haha)
Only one single script file sounds like a nightmare tbh, and the fact that GUI Scripts and functions are a separate thing from GO Scripts and functions. And no thanks to AI, in my experience they are not worth the time and effort.
@scandalousowl
I think all of us want to suggest you using GUI for a popup, because that’s what GUI is for, and would solve your problems you have with implementing similar things in the GO world. No worries, if you feel like doing it in the GO is a better option for you, it is still possible, but what other mentions and I agree, it will be a little bit more difficult. On the contrary, I once made a whole puzzle game in GUI only and was very proud of it, it now turned into something completely different, but I still work on it as a hobby project and my dream game, so I can kinda relate
If you’d decide to go with GUI, I recommend using Monarch and Druid for all those pure “GUI” related things like menus, popups, etc. It’s just very easy and convenient with those libraries.
For the GO, I don’t know if you’re using already the Defold Input Cursor library, but even if not - it’s worth looking at the implementation - it has filters and possibility to block certain inputs, so I guess, it could help to solve your problems
Btw, I am just finishing updating the colorslide tutorial, not in the way to put everything in the GUI, it will still be as it is, but it will be updated and hopefully better explained
Oh hey I recognized that game Your vids are great! I didn’t know Witchcrafter was made entirely in GUI, and I’ll be interested to know how you went about it.
Back to to topic. On one hand I get why people suggested using GUI for anything menus. On the other hand, no one’s provided a reason why except GUIs should be made with GUIs. Maybe I shouldn’t use popup menu as an example, but at its core the problem I have is this: I want to have a temporary layer appear on top of the game, and while the layer is active, I shouldn’t be able to interact with anything outside of the layer. It could be an inventory, or a treasure chest, or a card-swiping mini-game.
Now I did have another go with GUIs yesterday, went through the manuals and tutorials again, but I encountered the same problem–overlapping buttons means I can still click the button underneath–and I would need to handle that with some custom scripting logic–same as with GOs. I’m sure I missed something, but I don’t know what I missed. I’ll be ecstatic if someone can let me know the super duper easy way for GUIs to handle this situation. (Unless its by consuming input, which I don’t think is unique to GUIs?)
I’m avoiding libraries right now so I can learn how things actually work (and also libraries are globals? which I’m about), but thanks for the suggestions. (Using DefOS only because I can’t solve the hide-cursor-problem but its already making my project take longer to open so that’s annoying…)
For the colorslide tutorial, I picked it just ‘cause I thought it’s feasible to re-create in pure GUIs. It explained the menus and buttons and level loading fine.
It isn’t, but at first I wanted to make a simple mobile game with match-3 mechanics about elements, set in my imaginary slavic inspired fatnasy world, and I did the very first prototype of the match-3 board using only GUI, because I learned the gui.pick_node and it was easy to use it
I then changed the idea totally, and at some point the match-3 mechanics were still-in:
But rest of the game is normally in GO. And nowadays it’s more of a metroidvania RPG
Hmm I tend to only use Lua modules if it’s something that would be used by different scripts, and have one script do one thing. I guess in this case my scripts would be Lua modules instead and the GUI script is only used to load the Lua modules and use their functions?
Regardless, GO doesn’t have the hard limit of only one script so feels weird for GUI to have it. But just a personal preference at the end of the day.
Ah that makes more sense. I was looking at the game and thinking ‘Wow I can’t believe you can make all this with GUI’. A match-3 in GUI only sounds impressive too, so if you feel like teaching the class…
Gui.pick_node is such a handy function, if only GO has a similar thing
Metroidvania is not really my thing but good luck with your game!
It’s not, because you can still break up the code any way you want, like I said (modules etc). It’s just important to acknowledge the way the system sees itself - one GUI collection, one script to run it. It’s very efficient.
Nothing inherently wrong with that. It’s a different system, different function calls. It’s the same where it needs to be (eg. getting and setting properties).
Your vids are great! I didn’t know Witchcrafter was made entirely in GUI, and I’ll be interested to know how you went about it.
about), but thanks for the suggestions. (Using DefOS only because I can’t solve the hide-cursor-problem but its already making my project take longer to open so that’s annoying…)
