New extension: Curved Movement

[github-actions]

Description

Adds a behavior that allows objects to move smoothly on (bézier) curves.
Here is a short video of it in action
https://user-images.githubusercontent.com/66256867/184871120-5b4aa7b1-dc2f-46b0-9c94-c0d29b5d680b.mp4

The easings are still missing from all four non-behavior, the "AppendPath", and the "ChangeEasing" events. But Davy said that he/she will help with with them, hopefully with some text editing black magic. Doing this manually would be painful.

How to use the extension

Add the behavior to the object.
Use the action "Append a path" to add a new path to the object. The control points control the arc of the curve.
Use the above action multiple times to add multiple paths to the object. All of them will be played one by one.

Checklist

• I've followed all of the best practices.
• I confirm that this extension can be integrated to this GitHub repository, distributed and MIT licensed.
• I am aware that the extension may be updated by anyone, and do not need my explicit consent to do so.

What tier of review do you aim for your extension?

Reviewed

Example file

Version1.zip

Extension file

CurvedMovement.zip

[pampogokiraly]

Here is the updated example game. This time I think I did it correctly
Version2.zip

And here is the video. That I also hope I did correctly

Version1.mp4

[D8H]

Really nice extension!

I have some suggestions:

Good practices

• Function names should not be prefixed by a letter.
  • Any reason why you did this?
• Extension users won't need the DoPause do pause action as they can disactivate the behavior to do the same thing.
• Use an array of structure to store the path.
  • __CurvedMovement.PathElements[2].StartControlPoint is easier to read than __CurvedMovement.MovementLine.6.
• XposOnCurve and YposOnCurve are identical only one is needed.

Features

Separate the path definition from the movement

What do you think about separating the path definition from the movement?

I mean an action to append a path element and another one to start moving on the next path element with a given duration and easing.

It could allow to loop on the path either by repeating it or go backward.

It could also allow to:

• Go through the whole path in one step
• Go through X pixels
  but calculating Bézier curve length is fairly complicated, it can be done in an update.

Simplify path building

I guess that users only need to append a path element or clear the path completely to define another one. Actions to modify points one by one can probably be removed. It will be easier to understand for users.
What is your view about this?

[pampogokiraly]

Really nice extension!

Thank you.

Good practices

• Function names should not be prefixed by a letter.

  • Any reason why you did this?

Gdevelop orders all actions, conditions, and expressions alphabetically. If I don't use these letters, their order will be all over the place, which looks ugly and unreadable.
Sadly this is a problem with expressions since their names actually show up to the avarage extension user.
I still think ordering is more important than having a proper name, but let me know if I should remove them instead.

• Extension users won't need the DoPause do pause action as they can disactivate the behavior to do the same thing.

That looks a bit less intuitive than having a pause action, but alright. I will remove it.

• Use an array of structure to store the path.

  • __CurvedMovement.PathElements[2].StartControlPoint is easier to read than __CurvedMovement.MovementLine.6.

ok.

• XposOnCurve and YposOnCurve are identical only one is needed.

These are both expressions which return the X or the Y position of a made up curve. I can't have a single expression returning both numbers. I may be missing something, but I don't see a way to merge them into one.
(It is kind of weird to me that you didn't see that. Maybe there is a problem with it not being clear enough then.)

Features

Separate the path definition from the movement

What do you think about separating the path definition from the movement?

I mean an action to append a path element and another one to start moving on the next path element with a given duration and easing.

It could allow to loop on the path either by repeating it or go backward.

It could also allow to:

• Go through the whole path in one step
• Go through X pixels
  but calculating Bézier curve length is fairly complicated, it can be done in an update.

Sorry. I don't really understand what you mean by this... I read it multiple times but I don't understand.

Simplify path building

I guess that users only need to append a path element or clear the path completely to define another one. Actions to modify points one by one can probably be removed. It will be easier to understand for users. What is your view about this?

I could move them into an "Advanced" group so they don't get in the way, but I do think this is quite useful. One of the biggest missing features of tween for me was not being able to change it midway.
With this extension, you can do some cool moves like moving the destination point one pixel up every frame, which can turn your simple curve into some interesting looking stuff.
In my opinion it can be very useful, in quite a few cases. I admit, there are some somewhat useless actions like change the easing, but it would have felt weird to not include it when you can change literally everything else. And I do think someone is going to be grateful that it exists.

[D8H]

• Function names should not be prefixed by a letter.

  • Any reason why you did this?

Gdevelop orders all actions, conditions, and expressions alphabetically. If I don't use these letters, their order will be all over the place, which looks ugly and unreadable. Sadly this is a problem with expressions since their names actually show up to the average extension user. I still think ordering is more important than having a proper name, but let me know if I should remove them instead.

Function names must be chosen once an for all because it would break extension user events to change them. So, it needs to be carefully chosen from the beginning. The UI is not perfect but it will improve and, just a random example, it could be decided that the fullname should be used to sort them which would make the workaround useless.

• XposOnCurve and YposOnCurve are identical only one is needed.

These are both expressions which return the X or the Y position of a made up curve. I can't have a single expression returning both numbers. I may be missing something, but I don't see a way to merge them into one. (It is kind of weird to me that you didn't see that. Maybe there is a problem with it not being clear enough then.)

Let's say we want to create an action to put an object at the middle of 2 points. The formula is:
x = (x_a + x_b) /2
y = (y_a + y_b) /2

We could create an expression for x MeanX and for y MeanY but what we actually need is only an expression to evaluate a mean.

Separate the path definition from the movement

What do you think about separating the path definition from the movement?
I mean an action to append a path element and another one to start moving on the next path element with a given duration and easing.
It could allow to loop on the path either by repeating it or go backward.
It could also allow to:

• Go through the whole path in one step
• Go through X pixels
  but calculating Bézier curve length is fairly complicated, it can be done in an update.

Sorry. I don't really understand what you mean by this... I read it multiple times but I don't understand.

I'm suggesting to split this action:

_PARAM1_ Append a new path to _PARAM0_ to _PARAM2_;_PARAM3_ (first control point: _PARAM4_;_PARAM5_, second control point: _PARAM6_;_PARAM7_) with easing _PARAM10_ over _PARAM11_ms. Rotate object: _PARAM8_ with _PARAM9_ offset

into:

Append an element to the path of _PARAM0_ to _PARAM2_;_PARAM3_ (first control point: _PARAM4_;_PARAM5_, second control point: _PARAM6_;_PARAM7_)

and:

_PARAM0_ move to the next way-point in _PARAM11_s with easing _PARAM10_

"Rotate object" and "Angle offset" should be properties.

It could feel cumbersome to have 2 actions, but I guess that users will want to define a path at the beginning and move serval times along it. In the future, there could be an actions to move the whole path in one go or loop on it...

Simplify path building

I guess that users only need to append a path element or clear the path completely to define another one. Actions to modify points one by one can probably be removed. It will be easier to understand for users. What is your view about this?

I could move them into an "Advanced" group so they don't get in the way, but I do think this is quite useful. One of the biggest missing features of tween for me was not being able to change it midway. With this extension, you can do some cool moves like moving the destination point one pixel up every frame, which can turn your simple curve into some interesting looking stuff. In my opinion it can be very useful, in quite a few cases. I admit, there are some somewhat useless actions like change the easing, but it would have felt weird to not include it when you can change literally everything else. And I do think someone is going to be grateful that it exists.

If a user change the path during the movement, the object will jump. They will call it a bug.
If the object must choose another path I bet that 99% of the time a completely different path must be built from where the object currently is. It's easier to clear everything and rebuild by appending path elements.
Less actions is easier to understand for users and less work for you, me and future maintainers of the extension.

You can keep them for now. It will be easy to remove them later on if we need to, but it's more work for you.

[pampogokiraly]

Function names must be chosen once an for all because it would break extension user events to change them. So, it needs to be carefully chosen from the beginning. The UI is not perfect but it will improve and, just a random example, it could be decided that the fullname should be used to sort them which would make the workaround useless.

Okay. I guess I have to remove them then. I just really really really don't like how it looks when my functions are all over the place.
Maybe I will try using sub-groups a bit more so at least its somewhat clean...
Hopefully one day we will have the abality to properly order our functions.

These are both expressions which return the X or the Y position of a made up curve. I can't have a single expression returning both numbers. I may be missing something, but I don't see a way to merge them into one. (It is kind of weird to me that you didn't see that. Maybe there is a problem with it not being clear enough then.)

Let's say we want to create an action to put an object at the middle of 2 points. The formula is: x = (x_a + x_b) /2 y = (y_a + y_b) /2

We could create an expression for x MeanX and for y MeanY but what we actually need is only an expression to evaluate a mean.

I'm most likely being a smoothbrain right now but I still don't get it.
A multifunctional expression that can return X or Y depending on which one you pick...?
I have a feeling I don't understand because of my limited english knowledge here. Can you please try explaining it again? Maybe with an example from Gdevelop or something. I don't know... (maybe even hit me up on discord. I just really don't understand, I'm sorry)

I'm suggesting to split this action:

_PARAM1_ Append a new path to _PARAM0_ to _PARAM2_;_PARAM3_ (first control point: _PARAM4_;_PARAM5_, second control point: _PARAM6_;_PARAM7_) with easing _PARAM10_ over _PARAM11_ms. Rotate object: _PARAM8_ with _PARAM9_ offset

into:

Append an element to the path of _PARAM0_ to _PARAM2_;_PARAM3_ (first control point: _PARAM4_;_PARAM5_, second control point: _PARAM6_;_PARAM7_)

and:

_PARAM0_ move to the next way-point in _PARAM11_s with easing _PARAM10_

It could feel cumbersome to have 2 actions, but I guess that users will want to define a path at the beginning and move serval times along it. In the future, there could be an actions to move the whole path in one go or loop on it...

I see what you mean. I like the idea but it kind of feels the same just with an extra step to me. Maybe I'm just too used to what I created.
Though I have this idea instead:
You could create curves outside of the object behavior and name them.
Then, you could just use an event on the object that would look something like this:

Move _PARAM(object)_ through _PARAM(path-name)_ path in _PARAM(duration)_ms with easing _PARAM(easing)_

Its kind of like a mixture of your suggestion, and how timers work.
This would allow to make a loops way more easily, and would also remove the confusing "index" stuff that keeps bugging me.

"Rotate object" and "Angle offset" should be properties.

Yey! I can finally add something visible into the properties! Good idea btw, thank you.

If a user change the path during the movement, the object will jump. They will call it a bug. If the object must choose another path I bet that 99% of the time a completely different path must be built from where the object currently is. It's easier to clear everything and rebuild by appending path elements. Less actions is easier to understand for users and less work for you, me and future maintainers of the extension.

You can keep them for now. It will be easy to remove them later on if we need to, but it's more work for you.

I included a warning in the description of every action that could possibly make an object jump. I thought that was enough to not make people think its a bug. Either way, those descriptions could definitely be a bit more clear. They kind of suck right now, and I'm not very good at wording.
On a related note, I have two (I think good) reasons to keep these actions around:

• Changing the path keeps the progress of the object. If you had to remove and rebuild the path, you would first need to store the progress in a variable, and then change the progress to that variable once you got the new path. A few extra steps which personally I would like to skip.
• With the current system you can only append new paths. Which means to change the current one, you would have to remove every single path, and then add one. I can think of a few cases where changing the first path, wouldn't make you change the second path (This is also the main reason why I made the control points relative. As long you don't make any big changes, the arc would remain mostly the same).
  (Now that I think of it... If I implement the "naming" idea that I explained above, this problem would be gone. But at the same time, having these actions would make even more sense then in my opinion)

[D8H]

Let's say we want to create an action to put an object at the middle of 2 points. The formula is: x = (x_a + x_b) /2 y = (y_a + y_b) /2
We could create an expression for x MeanX and for y MeanY but what we actually need is only an expression to evaluate a mean.

I'm most likely being a smoothbrain right now but I still don't get it. A multifunctional expression that can return X or Y depending on which one you pick...? I have a feeling I don't understand because of my limited english knowledge here. Can you please try explaining it again? Maybe with an example from Gdevelop or something. I don't know... (maybe even hit me up on discord. I just really don't understand, I'm sorry)

What I mean is that using only one expression will work because the formula is the same for x or y. You could name it InterpolateCurve for instance.

I see what you mean. I like the idea but it kind of feels the same just with an extra step to me. Maybe I'm just too used to what I created. Though I have this idea instead: You could create curves outside of the object behavior and name them. Then, you could just use an event on the object that would look something like this:

Move _PARAM(object)_ through _PARAM(path-name)_ path in _PARAM(duration)_ms with easing _PARAM(easing)_

Its kind of like a mixture of your suggestion, and how timers work. This would allow to make a loops way more easily, and would also remove the confusing "index" stuff that keeps bugging me.

It's an interesting idea but moving on a full path must be left aside for the 1st version. Because, moving at a constant speed require to know the length of each path element and the formula is quite complex.

On a related note, I have two (I think good) reasons to keep these actions around:

* Changing the path keeps the progress of the object. If you had to remove and rebuild the path, you would first need to store the progress in a variable, and then change the progress to that variable once you got the new path. A few extra steps which personally I would like to skip.

To me, if the path must be changed, the new path will probably start where the object currently is.

* With the current system you can only _append_ new paths. Which means to change the current one, you would have to remove every single path, and then add one. I can think of a few cases where changing the first path, wouldn't make you change the second path (This is also the main reason why I made the control points relative. As long you don't make any big changes, the arc would remain mostly the same).

Could you give some examples?

I can see a use of removing the last path element to revert what was planned but I don't see why a user would want to modify it from the middle or the start as if it used again, it would be to loop so the same path would be kept.

[pampogokiraly]

What I mean is that using only one expression will work because the formula is the same for x or y. You could name it InterpolateCurve for instance.

Okay I finally understand it now. I have no idea what description, labels, etc... should I use, but I'll solve it when I get to it.

I see what you mean. I like the idea but it kind of feels the same just with an extra step to me. Maybe I'm just too used to what I created. Though I have this idea instead: You could create curves outside of the object behavior and name them. Then, you could just use an event on the object that would look something like this:

Move _PARAM(object)_ through _PARAM(path-name)_ path in _PARAM(duration)_ms with easing _PARAM(easing)_

Its kind of like a mixture of your suggestion, and how timers work. This would allow to make a loops way more easily, and would also remove the confusing "index" stuff that keeps bugging me.

It's an interesting idea but moving on a full path must be left aside for the 1st version. Because, moving at a constant speed require to know the length of each path element and the formula is quite complex.

You misunderstood what I said (though I admit I kind of rushed the explanation there).
What I mean is that you would have one action to create a path:

Create a path <positions and stuff> with the name _PARAM(path-name)_

And you can have an action like this which just plays one of the saved paths:

Move _PARAM(object)_ through _PARAM(path-name)_ path in _PARAM(duration)_ms with easing _PARAM(easing)_

So you could basically save paths, and call them in at any time. Similarly to how the previous method worked. No need to calculate curve lenght (kinda sad that its very hard to calculate. constant speed would be so much nicer).
If I explained it poorly again here is an example to somehow save myself:

1. Create a path named "Loop1" to <positions and stuff>
2. Create a path named "Loop2" to <positions and stuff>
3. Move object through the path "Loop1" <duration and easing>
4. If "Loop1" is finished, move object through the path "Loop2" <duration and easing>
5. If "Loop2" is finished, move object through the path "Loop1" <duration and easing>

To me, if the path must be changed, the new path will probably start where the object currently is.

Could you give some examples?

I can see a use of removing the last path element to revert what was planned but I don't see why a user would want to modify it from the middle or the start as if it used again, it would be to loop so the same path would be kept.

I am not sure how much this proves my point (if it does at all) but here is a very simple game where changing the movement midway can be very convenient:

example.mp4

(also I'm really proud of this extension. This tiny game ^^ took me less than a minute to make)

[D8H]

I find it difficult to see which features should be in the extension. What do you think about making a list of games that could be done with this extension?

For instance, in Galaga, a shoot'em up, there are waves of enemies that follow a curve.
The enemies also move left and right. In this game, it's on a straight line, but I could see modern games use a light wave.

I am not sure how much this proves my point (if it does at all) but here is a very simple game where changing the movement midway can be very convenient:
example.mp4

It looks nice. I don't see a use case either, but there may be something. I wonder if, for something dynamic, the expression would be easier to use because users can put variables for the point coordinates directly (a bit like the lerp expression but with a curve instead of a straight line).

You misunderstood what I said (though I admit I kind of rushed the explanation there). What I mean is that you would have one action to create a path:

Create a path <positions and stuff> with the name _PARAM(path-name)_

And you can have an action like this which just plays one of the saved paths:

Move _PARAM(object)_ through _PARAM(path-name)_ path in _PARAM(duration)_ms with easing _PARAM(easing)_

So you could basically save paths, and call them in at any time. Similarly to how the previous method worked. No need to calculate curve lenght (kinda sad that its very hard to calculate. constant speed would be so much nicer). If I explained it poorly again here is an example to somehow save myself:

1. Create a path named "Loop1" to `<positions and stuff>`

2. Create a path named "Loop2" to `<positions and stuff>`

3. Move _object_ through the path "Loop1" `<duration and easing>`

4. If "Loop1" is finished, move _object_ through the path "Loop2" `<duration and easing>`

5. If "Loop2" is finished, move _object_ through the path "Loop1" `<duration and easing>`

I have the impression that giving names to path elements is more complicated than necessary.

For instance, with this set of actions:

• append a path element
• remove last path element
• clear all path elements
• move on the next path element

users don't have to use neither index nor name.

[Wend1go]

Wow this looks really cool. :)
I wonder if it would be possible to add an import function for paths generated via the path finding behaviour.
Being able to copy precalculated paths from one object with the path finding behaviour to other objects with this path behaviour would likely lead to a nice performance improvement.

[pampogokiraly]

!update
CurvedMovement.zip

[github-actions]

✅ Successfully updated the extension.

[pampogokiraly]

I updated the thing finally. Well... more like reworked the thing, because I decided it would be easier to start from fresh, and just copy paste my knowledge into a blank extension.

Changes in a nutshell:

• Lots of actions, conditions, and expressions removed. Like all the things that change the current path, pausing, and some other stuff as well I think.
• Making a new path now takes two steps (or more depending on what you want).
  1. Append one or more paths to the object. I included duration and easing here, as you probably want to pre-set those as well first before sending the object on its way.
  2. Start the movement. You can specify how many paths should the object go through on, and also if those paths should be deleted, or should they stay (so you could just send it again on the same paths again).
• Merged XposOnCurve and YposOnCurve into InterpolateCurve. Now actually I don't entirely know what Interpolate means even after doing some googling, so all the descriptions and labels are just a "best guess". If anyone could, then please help me rephrase them.
• Rotation and rotation offset are behavior parameters now.

Some answers:

I find it difficult to see which features should be in the extension. What do you think about making a list of games that could be done with this extension?

This is actually a pretty big problem not for just you, but also for me. I made this extension with the mindset "hey this looks kinda cool! I bet some people would use such a versitale tool". And I bet that is true. But I personally can't really think of too many cases where this could be really that useful.
Its kind of like tween, made mainly for animations (at least I assume tween is mostly for animations), but just a bit less useful. Maybe I'm missing something big, but even after a lot of thinking, I just can't really come up with any specific examples other than those basic stuff that you already showed.

I wonder if it would be possible to add an import function for paths generated via the path finding behaviour.
Being able to copy precalculated paths from one object with the path finding behaviour to other objects with this path behaviour would likely lead to a nice performance improvement.

I have no experience with the pathfinding behavior at all, and it also looks like I don't have enough experience with english as well.
Can you please try explaining that again in a bit more detail? Sorry for that, but my native language isn't english.

New example game:

I also have a new example game. It is quite fun actually, even though it has horrible artwork (I might fix this eventually. I couldn't be bothered right now)
ExampleGame.zip

Multiple control points?

I also have the idea of making movement curves with multiple control points. I actually have no idea how to do this, so I either figure out the online formula, or just make some ugly mess with my own solution. Though I kind of don't like the idea of the latter one too much...

[D8H]

Great job! The events are looking good.

Some suggestions:

• In InterpolateCurve, the easing parameter can be removed. Users will put the easing function in the Progress parameter.
• In Start, the parameter to delete the used paths could be a property because the action will likely be called with the same value every time.
• In ChangeSpeed, I guess it will be hard to understand what the duration parameter will mean. What about a speed scale that multiply the base speed (a bit like the time scale action)?
• How do you see the Progress action being used?
• When moving from one path element to another, stopping at the destination won't look smooth. The extra time that's overflowing the duration can be used to start moving on the next path.

Good practice:

• Prefer 2 actions for IsFinished.
• IsFinished should stay true as long as no other path element is started.
• Seconds are now preferred over milliseconds.
• The Progress variable should be called ElapedTime because the Progress expression is not the same thing.
• The Progress expression can be used inside the behavior when it's needed.
• ChangeSpeed should be renamed as SetSpeed but keep "Change" in the sentence and description.

[pampogokiraly]

• In InterpolateCurve, the easing parameter can be removed. Users will put the easing function in the Progress parameter.

Yes they could. But I don't think it makes any sense. It is much easier to understand, and faster to use if I place the easing in there as a parameter. The movement already uses it as a parameter, so it just makes sense if the expressions used it as well.

I've been using Gdevelop for a good while, but I only came across the Ease expression recently. I don't think any newbies (who would probably love to use some funny looking curves) would find that option.

• How do you see the Progress action being used?

If you want to change the path destination but want to stay on the same progress.
Or if you wanted to start on a different point of a curve.
And probably many similar applications.

• When moving from one path element to another, stopping at the destination won't look smooth. The extra time that's overflowing the duration can be used to start moving on the next path.

Yeah I have no idea how to do that. I might give it a shot, but I kind of want to focus on fixing other stuff first, and maybe try my hands on advanced paths with multiple control points.

• IsFinished should stay true as long as no other path element is started.

I don't think it makes a difference, and also it doesn't really make any sense to me.
But since it doesn't make a difference, I can do it lol.

• Seconds are now preferred over milliseconds.

I know. I used miliseconds because tween used it as well (which you probably figured out already).
They are pretty similar in my opinion (or at least they were) and I want to keep it uniform as much as I can, so users don't have to remember "oh yeah I use miliseconds here, but seconds here, and then minutes there, etc..."

• The Progress expression can be used inside the behavior when it's needed.

?

[D8H]

• In InterpolateCurve, the easing parameter can be removed. Users will put the easing function in the Progress parameter.

Yes they could. But I don't think it makes any sense. It is much easier to understand, and faster to use if I place the easing in there as a parameter. The movement already uses it as a parameter, so it just makes sense if the expressions used it as well.

I've been using Gdevelop for a good while, but I only came across the Ease expression recently. I don't think any newbies (who would probably love to use some funny looking curves) would find that option.

I guess that beginners will use the behavior and the expression is for advance users. The lerp expression doesn't include easing and it's very similar to InterpolateCurve.

• Seconds are now preferred over milliseconds.

I know. I used miliseconds because tween used it as well (which you probably figured out already). They are pretty similar in my opinion (or at least they were) and I want to keep it uniform as much as I can, so users don't have to remember "oh yeah I use miliseconds here, but seconds here, and then minutes there, etc..."

We want to use seconds everywhere in the events at some point. So, no new extension will be added with milliseconds.

• The Progress expression can be used inside the behavior when it's needed.

?

You can use the Progress expression to give the right value to some Progress parameters instead of repeating the formula 3 times (for x, y and angle).

maybe try my hands on advanced paths with multiple control points.

What do you mean?

[pampogokiraly]

• In InterpolateCurve, the easing parameter can be removed. Users will put the easing function in the Progress parameter.

Yes they could. But I don't think it makes any sense. It is much easier to understand, and faster to use if I place the easing in there as a parameter. The movement already uses it as a parameter, so it just makes sense if the expressions used it as well.
I've been using Gdevelop for a good while, but I only came across the Ease expression recently. I don't think any newbies (who would probably love to use some funny looking curves) would find that option.

I guess that beginners will use the behavior and the expression is for advance users. The lerp expression doesn't include easing and it's very similar to InterpolateCurve.

But lerp isn't bundled together with movement functions that have builtin easing so it makes sense that it doesn't have easing.
But as I said before, my expression is bundled together with movement actions that do have easing in them, and so it just make more sense to have them.
And also I don't fully understand why would it be better to leave out the easing parameter. Its not like it makes things any more confusing, just simply much easier and probably more readable as well. Especially if we assume only advanced users will use it.

We want to use seconds everywhere in the events at some point. So, no new extension will be added with milliseconds.

Fine. Whatever.

You can use the Progress expression to give the right value to some Progress parameters instead of repeating the formula 3 times (for x, y and angle).

I'm not sure if I understand you still, but I'll figure it out.

maybe try my hands on advanced paths with multiple control points.

What do you mean?

This is mostly for fun, and I might not even include it in the extension even if I succeed. But I really want to try and make a more flexible curve.
Basically you could append a new movement curve to the object like normal, but this curve by default would have no control points.
Then you could use an action to add a control point to the latest curve. You could add up to an infinite amount of control points, making some lovely looking curves. Of course this can be very performance heavy, but I don't care.

[Hillihix]

@pampogokiraly: Will you be able to make an unlimited search range and add the ability to pass through obstacles to a certain object and its instances?

[D8H]

@pampogokiraly: Will you be able to make an unlimited search range and add the ability to pass through obstacles to a certain object and its instances?

It's not a path finding extension. Users of this extension must build the path by giving coordinates.

[Bubble-one]

Hi @pampogokiraly
I love this, very excited to use this. Hope you go through the full review process as what you've done is worth it. I read that there was some doubts about what this could be used for. I think that when people know that something exists they find uses for it. Maybe it could be used for ball games, like basketball? But here's a quick example of the kind of thing I would use it for.

[pampogokiraly]

Hi @pampogokiraly I love this, very excited to use this. Hope you go through the full review process as what you've done is worth it.

Good to hear someone is excited :)
If people make good use of the extension, then definitely worth it!

I read that there was some doubts about what this could be used for. I think that when people know that something exists they find uses for it. Maybe it could be used for ball games, like basketball?

What I imagine, is that people would use it for animations. But most of the time you can just use already existing tools (like physics) to do the same, which is basically my biggest worry.

But here's a quick example of the kind of thing I would use it for.

That looks nice. Exactly what I was hoping for. Using the extension for animations.

[pampogokiraly]

!update
CurvedMovement.zip

[github-actions]

✅ Successfully updated the extension.

[pampogokiraly]

Alright. New version up and running.

Changes:

• Progress has been split into Progress and ElapsedTime.
• Delete used paths is now a property.
• ChangeSpeed has been renamed to SetSpeedScale and now it functions like TimeScale
• Progress between two path elements should be carried over. It turns out this was really easy to do. Hopefully it works, and I didn't mess it up. (yes. I did test it. but you never know when does something break because you forgot to test xyz)
• IsFinished has been split into two actions. PathIsFinished and MoveIsFinished. They now also stay active as long no new movement/path is started.
• Seconds are now used instead of miliseconds.
• More and better comments and groups. It hopefully should be even easier to understand now.
  Let me know if the comment colors just made it worse.
• Other tiny changes which I don't really remember (I should have probably kept track of every change I made. Oh well...)

Other notes:

• Easing stays as a parameter in InterpolateCurve and CurveAngle. It just makes so much more sense to have them, than to not have them.
• Multiple control points ain't coming in the near future. I'll still attempt it one day, but I'm busy right now with an another extension, and irl as well.
• I wanted to make a new and better example game but I just couldn't come up with a good idea. So for now this is all you got.

Updated example game:

ExampleGame.zip

[D8H]

I added some features to the extension. I'm not done yet, but I wanted to keep you updated.

The project:
https://www.dropbox.com/s/wrlnh9g08xpgko8/BezierCurve_REVIEW.zip?dl=1

A build of the project:
https://liluo.io/instant-builds/a44a9c21-e21e-4cc5-9b08-dc4545434129

New features

• Constant speed on a full path
• Build paths from SVG
• Build paths dynamically with various actions
• Rotate and scale a path to move to a given position
• Repeat a path
• Go back and forth (can loop)

Missing features

• Move indefinitely (I'll write another behavior that will use acceleration, deceleration and max speed)

[D8H]

I added a 2nd behavior that uses speed and acceleration instead of a duration and easing.
https://www.dropbox.com/s/wrlnh9g08xpgko8/BezierCurve_REVIEW.zip?dl=1

a build of the example:
https://liluo.io/games/d712f23d-3b36-42e4-9d24-1b5062198b7e?dev=true

[D8H]

@pampogokiraly Thank you for your work on this extension, I've merged a version with additional features in the community list. Fell free to open a new PR if you want to do some changes.

• [Community] [Curved movement] New extension #705