; 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.