0 Favourites

How do I move slowly?

  • I am a newbie and so this might be a very obvious question.

    I want a sprite to move down 50 pixels when a certain condition is met. I have tried using "move at an angle" but it's too abrupt. I want to be able to see the movement. I have tried to use "8 movement" but didn't get anywhere. Using "8 movement", the sprite starts moving down and keeps moving. It doesn't stop after 50 px. So what do I do?

    Thanks.

  • Try Set y to self.y+50*dt

  • Thanks for your reply. So quick too.

    I tried your suggestion and made this capx.

    But it doesn't work properly. The sprite now moves slowly and smoothly but it doesn't always stop in the right place. I am sure I am missing something but can't figure out what.

    The file is below if you'd like to check it out. Thanks.

    https://www.dropbox.com/s/6z397fr1x4el0dd/Movement.capx

  • The coordinate of the layout starts with 0,0 in top left corner.

    All objects have an x,y value thats fits it.

    So if you want an object to move Down 50 pixel, you can just add X-amount to y. To move up you subtract X-amount from Y.

    So in your case to make it very simple, you can store store the current X,Y value of your object. And every 1 sec for instant, you move the object X-amount in the direction you want to. And then test:

    starting value - current value > 50

    If thats the case you stop the object from moving. This check you just put in the event/function that handles movement of the object. And modify it so it fits the different directions you want it to move.

    Then it will slowly move in that direction.

  • Construct 3

    Buy Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Buy Now Construct 3 users don't see these ads
  • The coordinate of the layout starts with 0,0 in top left corner.

    All objects have an x,y value thats fits it.

    So if you want an object to move Down 50 pixel, you can just add X-amount to y. To move up you subtract X-amount from Y.

    So in your case to make it very simple, you can store store the current X,Y value of your object. And every 1 sec for instant, you move the object X-amount in the direction you want to. And then test:

    starting value - current value > 50

    If thats the case you stop the object from moving. This check you just put in the event/function that handles movement of the object. And modify it so it fits the different directions you want it to move.

    Then it will slowly move in that direction.

    That will also work.OP, set your "Overlapping at Offset" condition's 100 to 25.It works,and will have a nice effect.

  • Would Lerp work in this case?

    lerp(a, b, x) (there is also unlerp)

    Source

    A = Starting Position (such as the X or Y of the object IE. object_name.Y)

    B = Position to Reach (such as object_name.Y + 50)

    X = Percentage or otherwise interpreted potentially as speed. (Ex. 0.3)

    LiteTween might also work -

    Thread

    I personally haven't used LightTween. It looks nice though and I'll likely download it to try it out.

  • I'm a firm believer in the use of bullet behaviour when you want things to move accurately.

    Apply bullet behaviour.

    Set bullet speed to 100

    Set angle to 90 deg

    Wait 0.5s

    set bullet speed to 0.

    This gives a nice smooth movement and is very, very customisable eg you can have a sprite accelerate to a certain speed then decelerate smoothly into position.

  • [quote:2kuyx7ua]That will also work.OP, set your "Overlapping at Offset" condition's 100 to 25.It works,and will have a nice effect.

    Changing to 25 from 100 does work beautifully. Could you explain how you came to that particular number and would it work if the distance of the sprites change?

    And thanks to everyone who has taken an interest. I am trying out all the methods mentioned, even though Doc Ai's solution is easier for a newbie like me.

  • Bertie Booster - I just tried the Bullet behavior and came up with a snag. The sprites don't always move down 100px exactly. They always end up a few of pixels up or down instead of the exact 100px. Oherwise, this seems to be a nice, easy method too. Thanks for pointing me in this direction. But for my particular problem, the positions of the pixels have to be exact. Not sure how to get there.

  • [quote:1uikfy7i]That will also work.OP, set your "Overlapping at Offset" condition's 100 to 25.It works,and will have a nice effect.

    Changing to 25 from 100 does work beautifully. Could you explain how you came to that particular number and would it work if the distance of the sprites change?

    I don't know,I am also a newbie. I don't know why 100 doesn't work .

    I think Bertie boosters method would be the best here.

    And for your problem.Do this(A little maths)

    Bulletspeed*x=distance between the two balls(In this case,100)

    So 100*x=100

    x=1.

    So set it to 1 sec.

  • The math works on paper but in the game, the sprite never end up exactly 100px down. It's usually something like 98px to 100px.

  • You can correct the slight inaccuracies in a number of ways, the way I would use myself (am using in the game I'm currently designing anyway) is to populate an array of the layout with the X and Y values then move up and down the array index read then apply the appropriate value. I've found this to be the best way where accuracy is important and the game is quite complicated.

    But you're new (welcome aboard) so I'll spare you that and show you an easier method which you can use to nail things into position via the bullet behaviour. It's basically the same method as in my earlier post but with a couple of extra steps.

    Firstly your object I'll call it "block" needs an instance variable so create one we'll call it OldY and make it a number.

    Then we need to give the variable a value so we do this at the start of the layout:

    System }

    On start of layout }

    For each "block" } (add the action) Set OldY to block.Y

    // this assigns the current Y value to all instances of the block in the level so you have a starting height.

    Then we skip to the movement.

    As before

    Apply bullet behaviour to block if you haven't already.

    Then:

    Set bullet speed to 100

    Set angle to 90 deg

    Wait 0.5s

    Set bullet speed to 0.

    //Now the extra steps.

    Set block Y to block.OldY+50

    // This sets the new position of the block Y value to an absolute value of its starting position plus the 50 pixels vertical offset that you want. ie nails it into place

    Add 50 to block.OldY

    // Sets the "starting value" of block.Y to its new starting point ie 50 ppx below it's original starting point so if the block needs to move down again it adds another 50 to the correct value.

    So what you're doing on your move is sending it downwards at 100px per second for half a second so it travels 50 pixels before it stops approximately in place then once stopped you shunt it into position the final 2-3 px so it finishes exactly 50 px below it's starting point.

    (If horizontal values are critical just do the same with different angles and another instance var called OldX).

    It's a bit more effort to set up but very easy to use once it is, you could further improve it by putting the movement part into a function and simply calling the function each time a block needs to make that movement.

  • Thank you so much, Bertie Booster! You're a lifesaver.

    I used your method and it worked. I had to tweak it a little and I think I found a working solution. The capx is below. I really can't thank you enough.

    https://www.dropbox.com/s/6z397fr1x4el0dd/Movement.capx

  • Hi, no you're welcome, I had a very quick look, it works but there are issues visible if you use the debugger primarily the block instance variables are wrong.

    First thought is to populate them asap either in a loop on creation or use: System/ on loader layout complete/ for each block/ set OldY to block.Y then do the sums from there......

    And a little tip while I'm here.

    You know you had to include one instance of the block and text boxes, then immediately destroy the block?

    Well you can create a new Layout, call it "Unused" and put anything you want the game to create on it. So long as there is an instance of the object in the game on any Layout used or not, C2 will create the object as expected.

    So technically you could throw a block and the text boxes on an "unused" layout and just use a blank layout linked to the correct event sheet to make this "game" as per your CapX.

    As your games become more complicated you'll find this saves a lot of clutter around the outside of your layouts, very useful with huds etc too as you can design the hud once then just use an include sheet to get it on any layout.

    PS

    Back to your CapX.

    Your block is 50X50 px 100px centres so there is a void of 50px between each stacked pair.

    Try adjusting the point of collision overlap from 100px to 80 or 60 and you'll see the upper block follows the dropping block more fluidly as the dropping block only has to move as few as 10 (instead of 50px) to trigger the secondary drop. Just makes it more visual imo.

    Conversely if you increase the overlap to 124 you can reverse the effect and make it more "blocky"

  • Thanks for the tip about using a new Layout, called "Unused". It's really helpful.

    As for my game, the blocks won't actually look like that or be separated by 100px. I just created a quick layout to get my idea across.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)