Hey all, I’m making my first GDevelop game, really enjoying the experience so far! It was really easy to set up basic things to work, however I got stuck when trying to generalize. In particular, I’ve implemented basic “interactable objects”: when player moves near to such object, a label describing possible action appears and pressing space activates it. I’ve done this by putting all the labels into Action group and adding the following to event sheet:
(escape_button is just an example of how each individual interactable is hooked to an action)
This works fine, however has obvious drawbacks: groups & distance-reacting events have to be repeated for each scene; several interactable objects cannot be placed too close to each other as then each would trigger on space; the whole thing seems a bit too unstable and hard to improve on in the long run.
So I’m trying to replace this with custom behavior that would have an isActivated condition and the rest would be handled by behavior. However the issue I’m running into is that I can’t find a way to reference player object (to measure distance) in any way (objects cannot be properties of behaviors apparently). I wanted to use groups, but the selector for distance condition doesn’t let me using expressions so that I could reference group by string or some such.
Looking forward for any help and especially advice on what is idiomatic way to this, or perhaps pointers as to how the behavior I want is called so I can look it up (I’ve done search through forum with keywords I could come up with, though)
There’s no easy way for behaviors to interact with a other objects. The easiest way is to add a function to the behavior that uses a parameter for the other object and then trigger the action from the scene either on every frame or when needed.
Behaviors like Platforms and pathfinder work by using managers to register the other objects. I don’t understand the manager part. They use 2 behaviors.
As far as 2 objects opening or being triggered, you need to filter the object list first by using something like pick nearest object.
To use another object for the distance, you could use the compare 2 numbers condition. Then use the expression to compare the 2 objects. Although, pick nearest object might be enough depending on your need.
If you use compare 2 numbers, you might need to use it within a for each object event.
Thanks for your suggestions. I ended up using adding parameter to my condition instead of an additional function (which means that object behavior won’t kick in unless its condition is used, but that’s fine). I’ll post my current solution in a bit. Meanwhile I think I discovered a weird bug in OR so I’ll check if I’m using the latest version and go report it if I can confirm it
Like Keith said, you can use the “nearest” condition.
What would be the difference with using the visibility like in your current events?
Maybe, you didn’t show everything but your events are very short, I don’t see what you want to simplify.
Like Keith said, you can use the “nearest” condition.
That doesn’t really make a difference here because there can be many objects with this Interactable behavior (or Action group as in initial example, which I might’ve not clarify in my original post) and there is usually only one instance of each
What would be the difference with using the visibility like in your current events?
Maybe, you didn’t show everything but your events are very short, I don’t see what you want to simplify.
I’d have to create a group Action and then copy-paste first two events on each scene. If I were to change any logic later, it would have to again be manually updated on each scene (e.g. if I need to add more checks like lockActions which itself was added along the way). I’m really not into such code.
With the solution I’ve arrived at I only need to use one condition per object and no additional setup for each scene. And if I need to make any changes I’ll be able to apply them across all scenes.
So here’s my solution for now, utilizing one behavior on any number of objects (w/o lockActions behaviour for now, but it can be easily implemented back)
