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.

47 VOTE

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
  • Shipped
  • Sep 16, 2019

    Admin Response

    A new 'Move To' behavior is now available in r166. Not only does it include moving to a position with acceleration and deceleration (including landing exactly on the target position), but it also supports waypoints, rotation, and following paths set out by a timeline, allowing for visual design of paths to follow.

  • 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.

     

    Ashley

    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: https://construct3.ideas.aha.io/ideas/C3-I-573

     

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

  • Adam Summerton commented
    24 Jun 15:59

    Is this officially not going to happen?  Having ported a lot of my stuff over to C3 now, I'd say this is the only Plugin that I really miss or can't recreate easily with events.  The ability to just "say go here at this speed" is so incredibly useful, the applications I have used it for recently are:

    • Camera: A hidden object that smoothly moves to various parts of the layout and then triggers an event when it gets there (fly-by of the level, a mini in-game cutscene, for RTS games). MoveTo is great as a smooth camera controller
    • Adventure Games: It's potentially easy to dismiss this plugin when viewed through the lens of a platformer or action game, but when doing something that is closer to an adventure game or point&click, then this is very useful feature.  A single event to move somewhere on the screen at a set speed, then a trigger to advance the story when you get there
    • Background / Scenery: Continuation of the reasons above, but this is very useful when you want to very easily move background characters to varying positions, without any effect on the gameplay. My example was to move bees to a flower, start a timer, pick a different flower, move there, repeat. This was incredibly easy with MoveTo
    • Prototyping: when doing game jams or prototyping, you just want something to move to a place with the minimum of effort.  The MoveTo plugin is very quick to deploy (seconds) and then you can potentially replace it later if you need something more complex

     

    The reasons why I don't like the Tween behaviour from trying to use it:

    • Not speed input - this has to be calculated or the item will move at differing speeds depending on the distance
    • Not smooth - no matter what I do it stutters like mad and looks pretty bad
    • Seems overly complex when using this for movement, you are not directly affecting the sprite so need a number of events to calculate speed, run the tween, set the position of the sprite etc
    • Not easy to change speed, direction, deceleration and acceleration mid-movement
       

    The reasons why I don't like pathfinding behaviour as an alternative to MoveTo

    • Doesn't seem to be pixel perfect
    • Requires an extra 'On Path Found' event, which is unnecessary when trying to replicate MoveTo
    • Doesn't seem to be as smooth when changing directions mid-path

    If anyone can point me to an example or method to do this in C3 then I would be grateful.  To recreate how this works in C2 then I'd want 2 events, first one says "Move Sprite to Position XY at Speed 100", and the second says "Trigger something when Sprite Arrives".

  • Chris Crawford commented
    27 Jun 18:32

    I assume if  that Ashley would say they're not doing it and give a reason why if this is not even being considered. Since this is still marked as "No Status", I'm guessing they're still open to it, but don't consider it a priority. It's a shame - it would be a much more intuitive and simple way to do A to B movements (tween was certainly not equivalent from a usability perspective, the last time I checked). It really seems like the kind of behavior that belongs in the base engine, but as they often remind us, they're a small team and have to pick their battles carefully. I am a little surprised there was no response here to the demonstrations of Pathfinding's imprecision, though.

  • Guest commented
    08 Sep 11:09

    This suggestion has been marked as 'In Development' !!!! :O

  • dop2000 commented
    16 Sep 12:54

    > A new 'Move To' behavior is now available in r166. Not only does it include moving to a position with acceleration and deceleration (including landing exactly on the target position), but it also supports waypoints, rotation, and following paths set out by a timeline, allowing for visual design of paths to follow.

     

    This is so cool, thank you!

  • Guest commented
    16 Sep 16:01

    Thanks a lot ! Construct, Ashley and his team are still at the top !
    Thanks again.

    Le lun. 16 sept. 2019 �� 14:27, Scirra <
    ba9859e75187b00badb8d63c-scirra@iad-prod1.mailer.aha.io> a ��crit :

    >