Construct 3 suggestions & ideas

Suggest and vote on ideas for Construct 3! Please note this is only one aspect of planning. We do not guarantee any features here will be implemented, even if they are top-voted ideas. The aim is just to collect feedback. Remember to search for existing submissions before adding an idea, describe your ideas as comprehensively as possible, and vote for plausible ideas that are well thought out. Please see our full guidelines on suggesting features.


Keep MoveTo and Tween as two separate behaviors

Tween works like an advanced Sine behavior. It's good for making nice visual effects, repetitive movements, animating scenery or UI elements. However, it's generally not good for use in actual game mechanics. For example, if you need to move an enemy sprite from point A to B, it will take a lot of efforts to make this work with Tween, you will need to experiment with different tweening functions, duration etc. And in the end the movement may still look unnatural and inconsistent. If multiple enemies started moving at different time/distance, they will all move at different speeds, unless you are using Linear function. Also, you have very little control of the object while it's moving, changing any of the Tween parameters will result in a very sudden change in movement, the object may even "teleport" to another location.

MoveTo behavior is more similar to Bullet, it provides an easy and predictable way to move an object from A to B. You can set acceleration, deceleration, current and maximum speed and the behavior will take care of the rest. You can change any of these values while the object is moving. Besides, it has a number of events and expressions, which don't exist in Tween.

Tween and MoveTo may look similar, and there are situations where they can be interchangeable, however they serve completely different purposes and can not be combined into one behavior.

  • dop2000
  • Sep 28 2018
  • No status
  • Attach files
  • Admin
    Ashley Gullen commented
    September 28, 2018 11:26

    What would this do differently to the Pathfinding behavior? It sounds like a limited version of that without the valuable capability to navigate around obstacles.

  • dop2000 commented
    September 28, 2018 12:00

    When you need to simply move an object from one position to another in a straight line, Pathfinding is a big overkill. You need to request to find the path first, wait for "path found" event and only then you can start moving. Not to mention that using Pathfinding with a large number of objects can be bad for performance.

    The reality is that Construct doesn't have an easy way of moving a sprite to a position and stop there. Yes, you can manage to do this with Bullet, Pathfinding, maybe even Custom Movement or some other behavior. But only MoveTo allows to do this with a single action.

  • dop2000 commented
    September 28, 2018 12:05

    Besides, it's odd to use Pathfinding in games where you don't have any obstacles - puzzle games, card games, quizes etc.

  • Admin
    Ashley Gullen commented
    September 28, 2018 14:39

    FWIW if there are no obstacles, the Pathfinding behavior skips the pathfinding algorithm, so there would be no performance overhead from that.

  • dop2000 commented
    September 28, 2018 14:59

    But even without obstacles you still need two events - "find path"  and "on path found -> move along path"? This is not a very convenient and easy way to move an object.

    If you could add another action to the Pathfinding, something like "Move to X,Y in a straight line ignoring obstacles", then there would be no need in MoveTo plugin.

  • tarek2 commented
    September 28, 2018 17:30

    Doop Thanks  for the description that's exactly what I was thinking and afraid off, that's why I said it would have been better to leave the MoveTo alone as is working pretty good doesn't need any extra overhead because of the twining and different staff, I use MoveTo a lot for in Game Play like Player, Enemies Etc.... and any extra overhead it can be catastrophic plus all the other staff that Doop mentioned which are all important to take into account.



    I'm having already a lot-lot of problems just to finish my Game mostly because the stutters I spend over 5 months or more just overdoing doing things all the Micro optimisation that I could think off just to gain few extra Cpu all of this just to reduce the stutters so that's why any extra overhead is gonna affect just Us especially if we build for Mobile like in my case it may for you it looks all the same but is not for us.


    Quote: What would this do differently to the Pathfinding behaviour?

    PathFinder Will have disadvantages like:

    1-More Events 

    2-No Accuracy  Example: overshoots the target 

    What I mean on here is that if I tell to find Path to an object it wouldn't go to the Exact (X,Y)  as opposite of MoveTo it goes always exactly to the (X,Y)  that's a big problem as if you need accuracy on the Game like in my case a wouldn't be able to use PathFinder unless I do extra Events which is more overkill


    3-big Delay on hit target to move to the next one

    Here definitely it brakes the whole Game if you need accuracy on Timing for the Events to happen one after the other without any delay

    The Pathfinder it takes 1 thick and this depends on how many enemies are looking for a path with  more enemies the more it can the take to find a path even if there are no obstacles, so in resume there is not accuracy for when the events are gonna happen either,  this just alone it will restrict the type of Games that you can do with the PathFinder as MoveTo.

    The MoveTo in the other hand the sooner it hits the target it goes straight away to the next target and this without ticking the option that it has for continuos Moving Mode


    4-The MoveMent is less Smoother than MoveTo


    all of this is just the first ones that came to my mind I'm sure they are a lot more I will post if I have Time

    in the meantime, I leave you some capx so you can see this 4 Points from above

    They are exactly the same thing is just one use MoveTo and the Other one uses PathFinder


    With PathFinder:

    Capx: Capx:

    Video: Video



    With MoveTo:

    You need MoveTo for this

    Capx: Capx

    Video:  Video


  • dop2000 commented
    September 29, 2018 07:35

    Oh, right, I forgot about the precision issue with Pathfinding - it almost never arrives at the exact position, which is really annoying. Sometimes it stops earlier, sometimes later. MoveTo is always pixel perfect.

  • tarek2 commented
    October 01, 2018 17:09

    Another problem I see that it hasn't been discussed yet is the compatibility to port existing Games made in c2 to c3 Run Time, changing the MoveTo or Merging it with another behaviour wouldn't lose the benefit to open c2 projects that already use the MoveTo Behaviour? that will force users to redo all the project to make it compatible with the new MoveTo behaviour

  • Guest commented
    October 08, 2018 08:56

    I also think, the platform behaviour should have sort of a MoveTo behaviour on it's own as well, that reckognizes all settings in the Behaviour itself and reacts to solids etc. This could be incorporated in the existing Platform Addon and just be an extra set of Conditions/Actions. I opened a separate Idea for it here:


    This is pretty much mandatory for coding any sort of Cutscenes in a game where the sprites use the Platform behaviour.