(If the fiddle disappears, the previous solution proposed using a variable incremented slowly with path.getPointAt(position) to move objects along the path.)
The Curve.getPointAt function accepts a value that represents a percentage along the curve. As a result of this calculation, the spacing between points (for example, 0 and 0.1) will vary depending on the length of the curve.
For instance, if curve1 is 10 units in length, and curve2 is 100 units long, then:
curve1.getPointAt(0.1) // vector 1 unit from the start of curve1
curve2.getPointAt(0.1) // vector 10 units from the start of curve2
If you base your motion on this system, then an object traveling along curve2 will move 10x faster than an object on curve1.
Instead, it is advisable to determine the number of steps an object should take along a path based on a certain "steps/second" or "steps/frame" measure. This aligns more closely to the concept of genuine physical velocity rather than being reliant on the path's length.
For example, let's suppose you intend to travel at a rate of 2 units per frame along both curve1 and curve2. With a fixed rate of movement, all you need to do is divide the rate by the total length to obtain the number of required "steps" (in this case, frames) to reach the path's end.
2 / 10 = 0.2 // point polling percentage for curve 1
2 / 100 = 0.02 // point polling percentage for curve 2
Subsequently, when moving an object along curve1, you would utilize path.getPointAt(0.2), and for curve2, you would employ path.getPointAt(0.02).
In foreseeing potential scenarios where the calculations may not align perfectly, resulting in partial steps towards reaching the end of the curve, the decision on how to handle such cases lies with you. You could opt to dedicate an additional frame to complete the motion, or anticipate a step ahead during the movement computation and decide whether to advance straight to the endpoint.