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 )
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)
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.
For clickable / draggable object in gameworld, you basically have 2 big ways:
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.
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.
I believe you mean daabbcc. If using daabbcc is overkill for performance reasons, then using Box2D with raycasts and collision objects for this is 2x overkill
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
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.
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:
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.
