Unrealistic, predictable ball movement?

Post reply
0 favourites
  • 6 posts
From the Asset Store
3D Platform Movement Template
$5 USD
Run and Jump in 3 Dimensions! Take your platformer to the next level!
larrynachos's avatar
larrynachos

  • I'm trying to emulate the older, unrealistic bounce behaviour of older games: gfycat.com/FlakyHighlevelInchworm

    I've been trying with bullet, and forcing gravity and bounce speeds upon bounce, but even that is a little too physics-y. Is there an example of a really rock-solid bounce ball movement I can use that really does just refract off angles perfectly without any change in speed or wild direction changes?

  • There are a couple of plugins that you can probably use:

    construct.net/forum/extending-construct-2/work-in-progress-addons-30/plugin-jcw-trace-raycast-112436

    construct.net/forum/extending-construct-2/addons-29/behavior-rex-light-78888

    But I would stick to Bullet. If you make the collision polygon shape close to circle, it should bounce off corners pretty well. Add a rough, low-fps animation to it and you'll get what you want.

  • There are a couple of plugins that you can probably use:

    https://www.construct.net/forum/extending-construct-2/work-in-progress-addons-30/plugin-jcw-trace-raycast-112436

    https://www.construct.net/forum/extending-construct-2/addons-29/behavior-rex-light-78888

    But I would stick to Bullet. If you make the collision polygon shape close to circle, it should bounce off corners pretty well. Add a rough, low-fps animation to it and you'll get what you want.

    Ahh, so the shape determines the bounce? That might explain the weird bouncing issues. Are there any examples of using these plugins to create a ball effect like this?

  • You can do it without behaviors. Just give the object an x and y velocity and do the bouncing by checking if walls are going to be hit horizontally or vertically. If they are, then reverse the velocity. 

    Globals:
G=100

Instance variables:
Vx=0
Vy=0

Every tick
— sprite: add g*dt to vy

Sprite: overlaps wall at offset (self.vx*dt, 0)
— sprite: set vx to -self.vx

Sprite: overlaps wall at offset (0, self.vy*dt)
— sprite: set vy to -self.vy

Every tick
— sprite: set x to self.x+self.vx*dt
— sprite: set y to self.y+self.vy*dt

    Just set vx and vy when the player throws it. You can adjust g to taste.

    Should be pretty close. At the very least you’ll get the perfect bounces. There are improvements that could be had. Here are a few of them that may be of interest:

    Possible improvements:

    The sprite needs to be outside of walls when it starts and throughout the motion. If it’s in a tight area, or it’s started inside a wall, then you need to move it out of the wall first.

    Usually not an issue if created inside the players collision area, and it’s given enough room to move around.

    There can be energy loss with vertical bouncing at times. The sprite will bounce lower after a few bounces.

    One reason for this is variable dt. You can help correct this by replacing self.vy*dt in all expressions with self.vy*dt+0.5*g*dt*dt.

    Bouncing is done by checking where the ball will be a frame later. You can get more precise bounces by calculating when the wall is hit exactly before bouncing then moving again with the remaining time. Not really necessary but has advantages for very fast sprites.

    A final idea is to only use integers for position and speed, and always use a fixed dt. This complicates it a bit but it removes energy loss from rounding caused by floating point numbers.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You can do it without behaviors. Just give the object an x and y velocity and do the bouncing by checking if walls are going to be hit horizontally or vertically. If they are, then reverse the velocity. 

    > Globals:
G=100

Instance variables:
Vx=0
Vy=0

Every tick
— sprite: add g*dt to vy

Sprite: overlaps wall at offset (self.vx*dt, 0)
— sprite: set vx to -self.vx

Sprite: overlaps wall at offset (0, self.vy*dt)
— sprite: set vy to -self.vy

Every tick
— sprite: set x to self.x+self.vx*dt
— sprite: set y to self.y+self.vy*dt

    Just set vx and vy when the player throws it. You can adjust g to taste.

    Should be pretty close. At the very least you’ll get the perfect bounces. There are improvements that could be had. Here are a few of them that may be of interest:

    Possible improvements:

    The sprite needs to be outside of walls when it starts and throughout the motion. If it’s in a tight area, or it’s started inside a wall, then you need to move it out of the wall first.

    Usually not an issue if created inside the players collision area, and it’s given enough room to move around.

    There can be energy loss with vertical bouncing at times. The sprite will bounce lower after a few bounces.

    One reason for this is variable dt. You can help correct this by replacing self.vy*dt in all expressions with self.vy*dt+0.5*g*dt*dt.

    Bouncing is done by checking where the ball will be a frame later. You can get more precise bounces by calculating when the wall is hit exactly before bouncing then moving again with the remaining time. Not really necessary but has advantages for very fast sprites.

    A final idea is to only use integers for position and speed, and always use a fixed dt. This complicates it a bit but it removes energy loss from rounding caused by floating point numbers.

    Thanks so much R0J0hound I really appreciate it, looks awesome! So G is speed, and setting Vx and Vy at spawn time sort of controls how high and far they are thrown?

    Bouncing is done by checking where the ball will be a frame later. You can get more precise bounces by calculating when the wall is hit exactly before bouncing then moving again with the remaining time. Not really necessary but has advantages for very fast sprites.

    I'm not exactly sure how this could be done, although Jill's blade moves fairly slowly, I'm interested in what method could be used.

    A final idea is to only use integers for position and speed, and always use a fixed dt. This complicates it a bit but it removes energy loss from rounding caused by floating point numbers.

    Should I encapsulate all variables in int() to achieve this? And how is dt made to be fixed (presumably so it's not machine independent?

  • G is the gravity amount

    Vx is the horizontal velocity

    Vy is the vertical velocity.

    For low speeds I wouldn’t worry about more precise bounces. It will look very precise.

    For a fixed timestep you’d do just that use 1/60 instead of dt in the equations. If the frame rate varies a lot that could be an issue. Sometimes a solution for that is to keep track if the next position and the current one and interpolate between them depending on the time. It’s simpler to just use dt though since that’s how constructs game loop works. It’s easier to make it look better anyways.

    There’s a property to draw sprites at integer positions. Just use that to avoid subpixel positions. You don’t want to round the position directly unless you keep the unrounded values in some variables. The motion would be messed up otherwise.

    Anyways just making events like the code above should be fine. If you want integer poisons use the position rounding property in the editor. (I forget what it’s called exactly)

Post reply
  • 6 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)