# Create a search a click / drag and move game GUI or GO? **URL:** \ **Category:** Questions\ **Created:** [September 6, 2026, 11:32am UTC](https://forum.defold.com/t/create-a-search-a-click-drag-and-move-game-gui-or-go/83204 "2026-09-06T11:32:29Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![PendragonNL](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/pendragonnl/32/37658_2.png) [@PendragonNL](https://forum.defold.com/u/PendragonNL)\ **Post date:** [September 6, 2026, 11:32am UTC](https://forum.defold.com/t/create-a-search-a-click-drag-and-move-game-gui-or-go/83204/1 "2026-09-06T11:32:29Z")
Hello all, I finaly want to remake this gamejam game in Defold. This game i amde in Gdevelope where my wife dith all the art. (onboarding is a bid rough needed to scees it all in ) > **[Chronicles of the Alchemist | Play on gd.games](https://gd.games/pendragonnl/chroniclesofthealchemist)** > > This is a little click-and-create game made for the GDevelop game jam #7 with the theme: Overpowered. > We wanted to take a different route and hope to overcome/overpower your feelings when seeing these weird but amazing animals. > > We want you to feel... But i want to think how i want to create the game in defold. And at somepoint i keep thinking i need to put everying in GUI, to make it clickable , or draggable, or scrollable . but then how about animations? (like the grinder) If you would need to make a game like this in Defold, how would you do it? all in GUI? or all in GO, (and how to make it clickable) (tip play a bid of the game to understand what i want to create) Thanks all responces are welkom 😃 ---
**Author:** ![Vallo](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/vallo/32/39171_2.png) [@Vallo](https://forum.defold.com/u/Vallo)\ **Post date:** [September 6, 2026, 11:58am UTC](https://forum.defold.com/t/create-a-search-a-click-drag-and-move-game-gui-or-go/83204/2 "2026-09-06T11:58:15Z")
I should start by saying that I still have a lot to learn about Defold, so I’m not sure whether my approaches to solving these issues are actually the best or recommended ones. As for putting the entire game inside the GUI, I would personally avoid it. You can manage everything without using GUI nodes, and once this new feature leaves the alpha stage and is released as stable, you will also be able to completely disable the GUI system from the build if you don’t use it, saving some space in the final game size. Personally, to handle clicks on objects and similar interactions without using the specific GUI functionality, I use a dedicated module where I store the data of all the clickable objects (position, size, z, etc.). Whenever the player clicks on the screen, I loop through all the active objects in the list (to improve performance, I keep them sorted by their z value), and if the click falls within an object’s area, I know that the player clicked on that object. As for the animations, since they don’t seem to be particularly complex based on what I’ve tried, you could probably handle everything using Defold’s [property animations](https://defold.com/manuals/property-animation/). ---
**Author:** ![JuLongZhiLu](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/julongzhilu/32/42720_2.png) [@JuLongZhiLu](https://forum.defold.com/u/JuLongZhiLu)\ **Post date:** [September 6, 2026, 12:11pm UTC](https://forum.defold.com/t/create-a-search-a-click-drag-and-move-game-gui-or-go/83204/3 "2026-09-06T12:11:07Z")
About making GO clickable or draggable, there is a extension can help you > **[GitHub - britzl/defold-input: Simplify input related operations such as gesture...](https://github.com/britzl/defold-input)** > > Simplify input related operations such as gesture detection, input mapping and clicking/dragging game objects * * * Besides this, there are other ways to make GO clickable or draggable. I’ll talk about them when I have time. Actually, making a GO clickable or draggable is a very common need. In Construct3 game engine, there is also dedicated built-in support for this. ---
**Author:** ![PendragonNL](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/pendragonnl/32/37658_2.png) [@PendragonNL](https://forum.defold.com/u/PendragonNL)\ **Post date:** [September 6, 2026, 3:02pm UTC](https://forum.defold.com/t/create-a-search-a-click-drag-and-move-game-gui-or-go/83204/4 "2026-09-06T15:02:34Z")
Thanks you both. @JuLongZhiLu I am looking forward to read more about what other options are. Thanks for sharing that extention. @Vallo I think it’s a very interesting idea you have with the list thanks for sharing. ---
**Author:** ![Mathias](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/mathias/32/44015_2.png) [@Mathias](https://forum.defold.com/u/Mathias)\ **Post date:** [September 6, 2026, 7:09pm UTC](https://forum.defold.com/t/create-a-search-a-click-drag-and-move-game-gui-or-go/83204/5 "2026-09-06T19:09:05Z")
For clickable / draggable object in gameworld, you basically have 2 big ways: 1. You store all positions and size of clickable objects, and at each frame/click you search the object your cursor is in. If you have many objects, an AABB Tree can help for performance (there is an extension for this). But for small screen like this game, it is overkill. 2. You rely on physics colision objects to detect cursor or objects interaction. So each interactive gameobject has a colisionobject. Then you have 2 possibilities: a. You rely on colision events: you attach a colision objet following the cursor, this will create colisions with other objects. b. You use the new box2d scripting API, and then cast rays or collision shapes at each frame at the cursor position. Then you can get back the colision body (or bodies) and do things. But you will still need to store id of all interactive gameobjects to link them with b2d bodies. The defold-input extension implements solution 2.a, and also draggable objects, it might be the easier for a start. But I think solution 2.b might be the more powerfull in the end, but it can be mixes with 2.a. You can also mix all of this! I like the physics way, because if interactive objects have collisionobjects, you can also use that for really physics effects, like throwing a thing on a wall, or just wall detection. I would use GUI only for menus or maybe score informations etc. ---
**Author:** ![selimanac](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/selimanac/32/6397_2.png) [@selimanac](https://forum.defold.com/u/selimanac)\ **Post date:** [September 6, 2026, 7:27pm UTC](https://forum.defold.com/t/create-a-search-a-click-drag-and-move-game-gui-or-go/83204/6 "2026-09-06T19:27:54Z")
> [@Mathias](#): > > 1. (there is an extension for this). > But for small screen like this game, it is overkill. I believe you mean [daabbcc](https://github.com/selimanac/defold-daabbcc). If using daabbcc is overkill for performance reasons, then using Box2D with raycasts and collision objects for this is 2x overkill 🙂 ---
**Author:** ![Mathias](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/mathias/32/44015_2.png) [@Mathias](https://forum.defold.com/u/Mathias)\ **Post date:** [September 6, 2026, 9:52pm UTC](https://forum.defold.com/t/create-a-search-a-click-drag-and-move-game-gui-or-go/83204/7 "2026-09-06T21:52:24Z")
Haha yes I was talking about that! My overkill point wasn’t on performance issues, it was on code complexity reason: if you have just small scenes with like 10-20 of interactive objects, you can just put them in a table and loop over it again and again, it will just work. You wont need to add another dependency with another API to learn and library to use. THIS was the overkill point. Yes as performance is concerned, one AABB tree will work faster than full box2d with raycast for sure 😅 But you still dont have any physics… so if you also need some physics, just use box2d with raycast. Box2d use its own aabb tree, so better not having another one besides of it 😉 If I had to make a game without the defold GUI module, I would use an AABB tree for all menus and “true GUI” things, but use box2d in gameworld for world interactivity. So I would have both systems still separated ---
**Author:** ![Mathias](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/mathias/32/44015_2.png) [@Mathias](https://forum.defold.com/u/Mathias)\ **Post date:** [September 6, 2026, 9:57pm UTC](https://forum.defold.com/t/create-a-search-a-click-drag-and-move-game-gui-or-go/83204/8 "2026-09-06T21:57:13Z")
makes me think that if they one day remove GUI API (I’ve seen a request about that on github), it would be cool to have a core builtin aabb tree by default and a pick\_gameobject() API to handle theses things, even if the game object doesnt have a collisionobject on it. So we could easily do GUI without GUI module, and non-physic games (like card games or point-and-click games) out of the box. ---
**Author:** ![Vallo](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/vallo/32/39171_2.png) [@Vallo](https://forum.defold.com/u/Vallo)\ **Post date:** [September 7, 2026, 3:52am UTC](https://forum.defold.com/t/create-a-search-a-click-drag-and-move-game-gui-or-go/83204/9 "2026-09-07T03:52:05Z")
I don’t remember reading that the GUI system is going to be completely removed, but they are working on the possibility of excluding the entire subsystem from the build through the usual App Manifest: > > > Projects can now exclude the built-in GUI, Particle FX, and Tilemap subsystems f…rom custom engines using new App Manifest settings. Each option removes the associated resources, components, and Lua module while preserving existing behavior for projects that do not enable the exclusions. Default engine configurations remain unchanged. > > Release engine sizes with each option enabled independently: > > | Platform | Configuration | Size (bytes) | Saved (bytes) | Reduction | > |---|---|---:|---:|---:| > | arm64-macos | Regular | 6,673,480 | — | — | > | arm64-macos | Without GUI | 6,523,528 | 149,952 | 2.247% | > | arm64-macos | Without Particle FX | 6,623,544 | 49,936 | 0.748% | > | arm64-macos | Without Tilemaps | 6,656,856 | 16,624 | 0.249% | > | wasm-web | Regular | 2,397,812 | — | — | > | wasm-web | Without GUI | 2,223,893 | 173,919 | 7.253% | > | wasm-web | Without Particle FX | 2,325,652 | 72,160 | 3.009% | > | wasm-web | Without Tilemaps | 2,380,879 | 16,933 | 0.706% | > > The macOS measurements use an arm64 release engine stripped with \`strip -x\`. The web measurements use the optimized, uncompressed release \`.wasm\` output before gzip or Brotli compression. > > Fix https://github.com/defold/defold/issues/12870 > Fix https://github.com/defold/defold/issues/12869 > Fix https://github.com/defold/defold/issues/10721 > > \### Technical changes > > \- Added \`exclude-gui\`, \`exclude-particle-fx\`, and \`exclude-tilemap\` App Manifest properties with localized labels and tooltips. > \- Registered Particle FX and Tilemap resources and components through the existing link-time resource and component descriptors. > \- Registered the \`particlefx\` and \`tilemap\` Lua modules through the existing script-extension lifecycle, allowing their registration roots to be excluded by symbol. > \- Moved Particle FX and Tilemap configuration and context creation into their component descriptors, with matching descriptor-owned cleanup. > \- Supplied the 2D physics context to the Tilemap resource descriptor through the resource-type context map. > \- Split GUI implementation objects into \`gamesys\_gui\` and Particle FX implementation objects into \`gamesys\_particle\`, keeping them outside the core \`gamesys\` archive dependency graph. > \- Removed GUI callback registration and Particle FX/Tilemap context setup from the core engine. The GUI component descriptor now installs and clears its GUI context callbacks during component-type creation and destruction. > \- Added \`dmGui::SetContextCallbacks()\` to the real and null GUI backends so GUI integration remains owned by \`gamesys\_gui\` instead of the core engine. > \- Added GUI script support for the existing \`META\_TABLE\_GET\_USER\_DATA\` mechanism, allowing a GUI script to expose its component’s owning game object without a global resolver or a direct GUI dependency in core gamesys. > \- Preserved the original fast path for ordinary GO scripts. Added a typed internal \`dmGameObject::GetInstanceFromLua()\` overload that is used only after the normal GO lookup fails, such as for GUI script instances. > \- Reused the existing \`gui\_null\` backend when GUI is excluded. No separate \`gamesys\_gui\_null\` library is required. > \- Added \`particle\_null\` for builds that retain GUI while excluding Particle FX. It contains the Particle DDF descriptors needed by GUI and safe stubs for the particle functions referenced by GUI. > \- Kept the GUI particle resource callback in \`comp\_particlefx.cpp\`; \`particle\_null\` supplies its corresponding null implementation when the real Particle FX library is excluded. > \- Updated CMake installation and link definitions, default exported roots, Extender allowed libraries and symbols, and editor platform library handling. Waf files remain unchanged. > \- Added App Manifest compatibility coverage for defaults, editing, round-tripping, setting combinations, platform manifests, and Windows library spellings. > \- Added tests for the typed GO instance lookup, GUI instance user-data lookup, Particle FX null backend, and GUI linked against \`particle\_null\`. > \- Built release engines for arm64-macos and wasm-web in regular, individual-exclusion, and combined-exclusion configurations. > \- Verified the exclusion variants link without the removed implementation libraries and that core \`gamesys\` has no GUI symbol dependency. > \- Verified the Particle FX null backend with 1 test and 12 assertions, the GUI/Particle FX null combination with 1 test and 5 assertions, and focused GO and GUI script-instance lookup tests. > \- No Lua, DMSDK, resource-format, Bob command-line, or Waf API changes are introduced. This can save up to around 173,919 bytes in the final build, which is fantastic! I agree that it would be nice to have built-in functions such as pick\_go() to make it possible to handle clicks on game objects. For those of us who already have our own custom input-handling module, it wouldn’t make much difference, the end result would essentially be the same. However, it would be extremely useful for new users, who wouldn’t have to deal with the difficulty of manually handling clicks on game objects, especially those who are less experienced. They wouldn’t have to come up with their own solution or search for and install third-party extensions just to achieve something that could potentially be built into Defold. ---
**Author:** ![PendragonNL](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/pendragonnl/32/37658_2.png) [@PendragonNL](https://forum.defold.com/u/PendragonNL)\ **Post date:** [September 7, 2026, 6:28pm UTC](https://forum.defold.com/t/create-a-search-a-click-drag-and-move-game-gui-or-go/83204/10 "2026-09-07T18:28:35Z")
So withough being bussy in enging for this at the moment. But when i read going over a table, how do you have this in mind? on every click you have a X and Y of the mouse, How do you check this on a table where the sprite is bigger then just that x and y possition. * * * So what i had in mind is a bid of the same way i had to do some things in rive, So lets say i attack a collision to the mouse, then every clickable object have a trigger collision. only when the mouse enter or leave. when a mouse enters it sets a valule in the main script. (with the ID and name of the objective) when a mouse leave it make the value blank. on mouse press i only have to check the vaule if its not blank. then its a object. Is this a way to do this aswell? ---
**Author:** ![Vallo](https://forum-defold.b-cdn.net/user_avatar/forum.defold.com/vallo/32/39171_2.png) [@Vallo](https://forum.defold.com/u/Vallo)\ **Post date:** [September 7, 2026, 8:04pm UTC](https://forum.defold.com/t/create-a-search-a-click-drag-and-move-game-gui-or-go/83204/11 "2026-09-07T20:04:29Z")
> [@PendragonNL](#): > > But when i read going over a table, how do you have this in mind? on every click you have a X and Y of the mouse, > > How do you check this on a table where the sprite is bigger then just that x and y possition. If you’re referring to what I wrote, the system is actually quite simple. When you want to make an object clickable, you store its data (such as its position and size) in a table. Every time you click, which as you said gives you the X and Y coordinates of the click, you loop through the entire table and check whether the click coordinates fall within the object’s bounding box. You can do this with a simple function like: ```lua function point_in_box(px, py, pos, size) local hw, hh = size.x / 2, size.y / 2 return px >= pos.x - hw and px <= pos.x + hw and py >= pos.y - hh and py <= pos.y + hh end ``` Here, px and py are the coordinates of the click, while pos and size are the data of the object you want to check. If the function returns true, the click was inside the object’s bounding box; if it returns false, the click was outside. Of course, you can add other data to each object to improve how clicks are handled, such as a z value (so, for example, you can only click the object that is visually on top) or specific flags to filter the search.