# Proper Programming Methodology

0 favourites
• 27 posts
• Cipriux - thanks for taking the time to look at it. Would using the timer behavior be easier and have the same result?

• ## Try Construct 3

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

Construct 3 users don't see these ads
• Never used, so I don't know.

• It doesn't work with timer either. It must be an issue with the "move at 1500*dt" event. I'll try doing what you suggested with setting the end location to snap, but since the camera keeps to the player position, it might look strange. Still no indication as to why yields random results...

• I've never used (or seen a need to use) the "else" condition. In that picture what is the point of having the "else" there, would it function the same without it?

• - I actually haven't tried without else; it's really just habit.

• I had some problems with not using the else condition in my game. I tried checking if the condition is NOT true but did not get the expected results as with ELSE.

I was using timer and sine behavior to make a sequence of characters behave like a wave, but after 2-3 minutes of waving , some randomness begin to appear. I did not investigate if the problem was the timer or the sine .

• A super simplified example to show why you dash further at lower framerate:

Say dt = 10 and dash = 30 and you move 100*dt every tick,

``````move 100*dt = 1000 px
dash = 30 - 10 = 20
move 100*dt = 1000 px
dash = 20 - 10 = 10
move 100*dt = 1000 px
dash = 10 - 10 = 0
move 100*dt = 1000 px
dashing = false
``````

total distance: 4000 px

at half the framerate, dt = 20:

``````move 100*dt = 2000 px
dash = 30 - 20 = 10
move 100*dt = 2000 px
dash = 10 - 20 = -10
move 100*dt = 2000 px
dashing = false
``````

total distance: 6000 px

-------------

In your capx (if I've calculated it right):

at 60 fps you move 1250*1/60 = 20.83px per tick

22 times

total distance: 458px

at 30 fps you move 1250*1/30 = 41.67px per tick

12 times

total distance: 500px

-------------

So you want to move a fixed distance, say 450px. At the start of the dash set dashDistance = 450. Every tick, move 1250*dt OR dashDistance, whichever is smaller and then subtract the distance moved from dashDistance. So you'll be moving 1250*dt until the last tick and the you just move the remaining distance to make it 450 and don't overshoot.

``````if dashing == true
if dashDistance < 1250*dt
move forward dashDistance
set dashing = false
else
move forward 1250*dt
subtract 1250*dt from dashDistance
``````
• ramones just to point out....dt is always lower than 0.1 sec (minimum forced FPS is 10)

for 60 FPS dt is sec

for 20 FPS dt is sec

• Cipriux yes dt could never be 10 or 20, I was just using simple numbers for the sake of example.

• problem, actualy your solution is a great one

ome6a1717   I made a test using ramones solution...and works very well

It works like this:

1.Before dashing calculate the target position target_x

2. if distance from player to target position is greater than dt*speed, than its ok to move using dt*speed

3. else just move the player to target position

preview

capx

[EDIT]: use < > keys to "dash", I think the same concept works for dashing at an angle and up, but I not sure.

The red lines represent the player position every tick...

• ramones - Interesting. I'll have to try this when I get home.

If this does work, how would I get a less "abrupt" stop and more of a fake "physics push" at the end of the dash?

• ome6a1717 maybe use this behaviour to slow down the movement at the end ease transition

• 27 posts