# How do I move slowly?

Get help using Construct 2

### » Fri Feb 21, 2014 7:14 pm

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.
B
4
S
1
Posts: 28
Reputation: 430

### » Fri Feb 21, 2014 8:47 pm

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.

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
// 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.
B
7
S
2
Posts: 93
Reputation: 797

### » Fri Feb 21, 2014 9:47 pm

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
B
4
S
1
Posts: 28
Reputation: 430

### » Sat Feb 22, 2014 1:01 am

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

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"
B
7
S
2
Posts: 93
Reputation: 797

### » Sat Feb 22, 2014 12:03 pm

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.
B
4
S
1
Posts: 28
Reputation: 430

### » Sat Feb 22, 2014 2:37 pm

Okay, I came upon another snag. I was doing a few test to see what happens when more than one ball in one column is destroyed simultaneously. It turns out the ball above do not fall into place as it should. So what to do?
https://www.dropbox.com/s/6z397fr1x4el0dd/Movement.capx

p
B
4
S
1
Posts: 28
Reputation: 430

### » Thu May 08, 2014 10:59 pm

Index wrote: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.

@Index: Simple and straightforward explanation. I had great difficulty understanding Lerp. Many thanks.
B
74
S
14
G
4
Posts: 1,045
Reputation: 8,193

Previous