I’ve got a scene with a number of platforms that originate from the same object (platformObject). I want to move the platforms in different directions - one to only move horizontally, one only vertically and a third one to stand still.
As it stands, I can’t do it by looping through all platformObjects in the scene - whatever I code for one will be applied to all. And I can’t explicitly reference a single scene object either.
So I’ve come up with a couple of solutions, but I’m interested to know if there is any better or more efficient way of doing it:
Solution 1: Create a platform object for each movement type.
So in this case it’s be horizontalPlatform, verticalPlatform and staticPlatform. The former two are duplicates of staticPlatform. This way I can iterate through all vertical platforms and move them vertically, and likewise for horizontal platforms.
Solution 2: Add object variables to platformObject to control movement
For example xDirection, yDirection (to specify the x and y modification to make to the object’s position). I can then iterate through all platfornObjects, updating their x and y positions by the object variable values.
I like the second solution, as makes for more flexibility in the object movements. By setting both x and y variables to non-zero values, I can make a platform move in any direction, and at whatever speed I like. By setting it to 0, it doesn’t move.
Are these reasonable solutions? Are there any pitfalls? Are there any better ways of achieving this?
Just assign variable ID’s to the instances of the objects you wish to move horizontal and vertical.
Then the events can be something like…
Condition
platformObject variable id is = 1 Action
I would use the Tween behavior to set x and y positions; you’ll need at least 2 sets per object. One set to check where the object starts and should go, and the other do the same in reverse. I’m sorry, this is kind of a bad explanation. I’ll get you a screenshot example.
Here you go, I hope that helps and makes my explanation above clearer.
Of course, you can do the same for Y positions.
It can get to be a bit “bulky” code-wise though, to be honest, but putting the events into groups helped in addition to careful organization and doing this sparingly. I only do this on certain levels and use the event sheets for those specific scenes (most of my other events and more complex logic are either in external sheets or functions).
Excellent. I assume the lone condition at the top of the image is supposed to be a parent/container of the ones that follow, and not just sit there without any actions.
I haven’t explored tween before, and I like that it has easing functions built in
Do you mean the “Tween on “move” exists” condition? It may not be needed at all. You can try without it if you want. I never make it as a parent/container - seems to work fine either way.
Yes, that condition. It’s a condition with no actions attached, and no sub-events, so it appears redundant. Correct me if I’m wrong - I’ve just started playing round with GDevelop, and there may be some nuances, like this one, that do something that I’m not aware of.
However, if the events following it were childed (childrened/sub-evented???), then it would make sense, and would appear to prevent unnecessary conditions from being checked.
Ok, you can ignore that line - I disabled it in a test and found that it’s definitely not needed.
Unfortunately, there are no examples available in the wiki to show the correct usage for that particular event, which meant I had to learn from trial and error myself. These events were put into my project a few months ago when Tweens were new to GD, thus I was experimenting with the behavior. Since it didn’t seem to cause a problem in performance, I forgot about it in favor of focusing on other updates and bug fixes.
