Hi guys!
I’m struggling with a simple concept: detect if a og has been clicked.
Now I’m using on_input, but the event is dispatched even if I click outside the om itself…
Any idea to solve this?
2 Likes
That topic is covered in this discussion:
2 Likes
I’m interpreting this also as a question of when a game object receives input. It seems from your question that you expect to get calls to on_input only when touch events end up “inside” the game object. If this is what you expect then I’m afraid that’s not how it works. on_input will be called for every go that has acquired input, unless a previous go has consumed the input event. Read more on how input works here: http://www.defold.com/doc/input
2 Likes
I too need to be able to click a game object. Its essential for my game.
In the GUI you can do this:
` if action_id == input_touch and action.pressed then
local circle = go.get_id()
if go.pick_node(btn, action.x, action.y) then
print("I'm clicked")
end
end`
How can it not exist a similar function for game objects or sprites?
I have same problem here. So there’s no direct way to detect if go is clicked/touched?
No, you have to translate the click position to your world space, which is actually a 3D space as opposed to the GUI that is 2D.
Right now I’m doing like this:
`function on_input(self, action_id, action)
if action_id == input_mouse and action.pressed then
local spritePos = go.get_world_position("myGo") -- getting my go position
local mouseX = action.x -- getting mouse position
local mouseY = action.y
local rightBoundary = spritePos.x - 200 --200 is half the width of my go
local leftBoundary = spritePos.x + 200
local upperBoundary = spritePos.y + 200
local downBoundary = spritePos.y - 200
if mouseX >= rightBoundary and mouseX <= leftBoundary and mouseY >= downBoundary and mouseY <= upperBoundary then
print("clicked")
else
print("outside")
end
end
end `
This works for right now since I don’t have a moving camera and don’t need to worry about worldspace coordinates. Just wish that there would be something like in action script:
mySprite.addEventListener(MouseEvent.CLICK, myFunction);
That would not be possible since you are free to render your world as you wish in your render script. However, we might be able to provide some helper functions that makes it easier to do these operations.
1 Like
Hi,
well this is really bad - imagine you have bunch of sprites on the pile on the same coordinations, and you want to drag them away. That would not be possible without some serious workarounds.
This should be fairly trivial to implement yourself, especially if you don’t do anything special in the render script right? The thing is that as @sicher said, you can render your world as you wish since you have full control of the render script, and this makes it impossible to provide a solution that works out of the box for all kinds of render scripts. BUT we should probably provide some helper scripts at least.
3 Likes
could you provide us any helper scripts to detect a mouse click on the particular game object?
1 Like
I created a small example of how you could handle input on game objects containing one or more sprite components. It’s based around a lua module to which you can add sprites and callback functions when a sprite receives input. It takes into account game object position and scale and sprite scale and size. You need to manually provide the sprite position (offset) since that value can’t be accessed at run-time. I uploaded the example here:
11 Likes
Very useful codes. I should to do some refactor my current game in the next version and apply it to other games as well.
1 Like
thank you for your quick response, buddie
2 Likes
97% of game developers don’t want to mess with a render script, they just want to be able to work on a game. (Actual number made up, but it wouldn’t surprise me if it’s that high or higher.) Not being able to easily know when a sprite/go is tapped/clicked is a horrible misstep, I think.
Defold is reminding me of Moai – very powerful, but more useful for programmers and not run-of-the-mill game developers. I’m not saying you should have made another GameSalad, but there’s a “foundation” that people expect with a game engine and Defold only has scaffolding in some places.
Jay
PS - Moai is, for the most part, dead. Defold does have more muscle behind it than Moai did, but I’d hate to see Defold being just a niche player.
4 Likes
IMO this example is a very good foundation for general 2D render script setups. It can maintain aspect ratio at any size, constrain the game area within the window, draw outside of the game window, and be able to translate screen input to game input. Examples like this just need more awareness so they can be adopted and devs can get on with the game making.
4 Likes
; TL/DR My suggestion of general input control is found in the bottom.
Two of the key aspects of Defold are flexibility and usability. The former requires an architecture which assumes very little of what you intend to do. The latter is often the opposite, too much genericness (a word?) confuses things and you see no clear path forward. In other words, we aim to provide you with something that helps you along fast, but does not impose a limit on what you can make. Our approach to solving this is to provide the flexibility through engine architecture, and usability through editor UX in combination with bootstrap data, which consists of the special case “builtin” content found in every project, as well as the template projects you can use to start things of. The grander vision is that when the library system has been more publically packaged, the users will contribute to this bootstrap data as well by providing sharable content. @britzl and others has already kicked this off by using github and other services, and of course this forum.
You can compare this to a general purpose programming language, where the syntax/grammar/compilers corresponds to “engine architecture”, and system libraries, user libraries, and online stackoverflow snippets corresponds to the “bootstrap data”. (You could even argue that the compilers belong to the bootstrap data, but let’s not go there)
The priority is always engine architecture first and bootstrap data second, as the architecture dictates what can follow. When it comes to bootstrap data, utility functions and the like, there is no “physical” boundary on what we can provide. But it suffers under the noise-factor, too much would also be confusing and annoying.
We are now very well aware of that a lot of users want something that helps with the problem of input and screen/world space conversions. We have a few ideas around how to solve this in a good way, but it’s not yet clear which one outperforms the others, or if there is an even better way. What I’m trying to say is that we do intend to solve the “conveniences” for people too, but not until we have an idea that provides us with a cozy gut feeling, to minimise the noise-factor. And since this is something that can be achieved right now without too much work, it will naturally have lower priority than things that can’t be done at all. There is a bandwidth problem to deal with too. In reply to @JAWhye, it is not yet a horrible misstep, it just hasn’t been fixed yet.
This is my suggestion how to do it now, a sufficiently general solution to touch input you can use until Defold supports it out of the box:
- Everything you want to touch has a collision object with a specific mask, e.g “touch” or “interact”
- One script deals with the input.
- Using the view/projection matrices of the camera (which can be queried by this script every frame from the @render: message socket, which corresponds to the render script) it transforms the screen space coordinates into world space. I bet a lot of people have already done the screen/world conversion, if someone could provide a snippet for it it would be much appreciated. Until then, there is plenty of info online
- It then spawns a new game object with a collision object at this point (e.g. a sphere, which will account for touch radius).
- The new touch-gameobject will collect collisions and dispatch them back to the input-handling script.
- If it’s important to distinguish type on the object you touch, you could by convention also add a script property that defines this for them. Another approach could be to send messages to them about the interaction and they would, by convention, have means to deal with these messages.
11 Likes
I feel bad that I made you take so much time to generate that reply, but I do thank you for it – it helps calm my soul. 
And I hope you didn’t take my previous post as a flame – it would be awesome for Defold to become a leading game engine and while digging into it I kept coming up with (what I saw as) dead-ends.
Thanks for that suggestion on how to handle the problem for now. That looks like an interesting solution.
Jay
1 Like
Absolutely fine, I just wanted to clarify where we are heading and why. 
Keep posting the dead-ends in the forum and we can all pitch in with explanations, or suggestions for workarounds if the features are missing.
2 Likes
I did this for the Link and Slide example I posted a while back and it works really great. It’s a very nice use of collision objects.
3 Likes