Need help with grabbing/bounce physics issue

hmgwyhmgwy Member Posts: 4

Hi there,

So I'm trying to tweak the physics in my game and there's a bit of an issue that I haven't cracked. The current controls work in a way that you grab a ball with the mouse button and have the linear velocity of the ball follow the mouse position (to keep collisions intact). The issue is: when I grab the ball and drag it into a collidable landscape, and keep dragging in the direction of the landscape, it starts to bounce rapidly and glitch out. I've tried setting some rules such as change attribute 'bounciness' to 0 when actor collides with a landscape or setting the 'grabbed' attribute to false when colliding with a landscape (which doesn't quite work because the ball starts on the ground touching a landscape). I'm just wondering what the best way to go about this is.

You can try it out for yourself and see what I mean - just click and hold the mouse button to drag the ball:
mediafire.com/download/jjm9psmp45xh8mo/BallTouchSystem.gameproj.zip

Any pointers would be hugely appreciated!

Thanks!

Comments

  • IceboxIcebox Member Posts: 1,485

    @hmgwy the problem is with this rule

    when grabbed is true

    self.motion.linear velocity x to 20(game.mouse.position.x -self.position.x)
    self.motion.linear velocity y to 20
    (game.mouse.position.y -self.position.y)

    the speed is high so it causes a glitch , not sure why really. I think you can create another rule when grabbed is true & overlaps or collides with walls change the speed to a low number , it will work but it will be much slower.

    when grabbed is true
    overlaps or collides with wall

    self.motion.linear velocity x to 0.9(game.mouse.position.x -self.position.x)
    self.motion.linear velocity y to 0.9
    (game.mouse.position.y -self.position.y)

    this isnt much of a solution cause it will slow it down, but maybe you like the result.

    goodluck

  • hmgwyhmgwy Member Posts: 4

    Thanks Icebox1910,

    I tried your suggestion but it doesn't quite slow the ball down enough and still glitches out at the edges of the playing field.

    Really appreciate you taking the time to help though!

    I've tried an alternative that is kind of working.. I made an invisible actor that follows the mouse position (essentially a cursor) and when it collides with a wall I have it set "grabbed" to false.. this way I can still control the ball on the ground, but once the mouse position overlaps with the wall it sets the ball free.. granted, the ball still glitches out a tiny bit and will occasionally follow the mouse position when the button isn't even down.. so still trying to find the best workaround!

    That said, I'm still open to suggestions.

  • tintrantintran Member Posts: 453

    if you don't want your ball to glitch out at the boundaries...
    in your constrains use min() and max() functions applied to your mouse.x and mouse.y...
    so instead of game.Mouse.position.x
    use something like min(490,max(80,game.Mouse.position.x))
    I just tried it with the x... you can come up with the one for the y..
    have fun
    I hope that helps.

  • hmgwyhmgwy Member Posts: 4

    Thanks for the suggestion tintran! The problem with the mouse constraint method is that I have collidable landscapes in the middle of levels as well, and the same glitching issue occurs when the ball is up against them... so constraining the actual mouse boundaries would only work on the outer periphery of levels with the max and min method. I'm just wondering if there would be a dynamic way to constrain the mouse position relative to the direction of the ball when it is touching land.. it usually starts glitching when the mouse moves past the centre of the ball towards land.. so maybe I need a rule/algorithm to constrain the mouse position to go no further than the radius of the ball in that direction.. any ideas of the best way to accomplish this?

    I'm going to fiddle around with it a bit...

  • tintrantintran Member Posts: 453
    edited July 2015

    If you're okay with letting go of the ball if it collides with landscape.
    You can try this.
    mediafire.com/download/dl3lr2lbl9dhm1b/BallTouchSystem.gameproj.zip

    I just added a rule at the very bottom to set grabbed to false when it overlaps with landscape.
    And it seems to work like how you described in your 2nd comment.

    PS:
    Now in my head, it shouldn't work because if that's true then how can grabbed be set to true if it's sitting still on (or colliding with) landscape, but i am guessing here we're lucky in that the order of the code as is works...not sure if the order matters didn't try to switch them around or anything.

    PS: I noticed that it doesn't work if the ball is sitting still on land and you grab the lower half of the ball it drops it right away so that's no good, if you grab the upper half or even outside of the ball, the ball is grabbed and travel upward toward the mouse cursor.... this is an interesting problem for sure.

  • tintrantintran Member Posts: 453

    I don't know if it's a bug or not but when i try to change the bounciness on the fly it writes the name ".restitution" instead of ".bounciness" and changing this ".restitution" value doesn't change how the actor acts.

  • The_Gamesalad_GuruThe_Gamesalad_Guru Member Posts: 9,922

    Physics like bounce can not be changed at runtime. Try setting a max speed. The max speed is adjustable at runtime.

  • tintrantintran Member Posts: 453

    tried changing max speed and clicked apply max speed but that didn't seem to work.
    So I set a variable called release to true when mouse is down and mouse is over landscape.
    It works, but it still glitches when the ball is above the platform and you try to grab the ball by clicking on empty space below the platform, because there's no land there it doesn't release the ball. I guess this bug wouldn't be there if you only allow user grab the ball if mouse is actually over the ball by changing "touch distance" to actual radius of the ball.

    mediafire.com/download/h49g76punu64srk/ReleaseIfMouseOverLandscape.zip

  • tintrantintran Member Posts: 453
    edited July 2015

    Okay I think i got it.
    Since GS doesn't allow physics attributes to be changed during run time.

    The idea here is we have two balls that act the same, except they have different bounciness, when it's being grabbed show the not bouncy copy, but when it's not being grabbed, show the bouncy ball instance.

    I made an exact copy of the ball instance

    -Set that copy to have bounciness of 0.
    -added two game variables ballx, bally (reals)
    -added a game variable grabbed (boolean)

    inside the ball instance (not the prototype)

    constrain game.ballx to be self.position.x
    constrain game.bally to be self.position.y
    constrain game.grabbed to be self.grabbed
    if game.grabbed
    -set color.alpha to 0
    else
    -set color.alpha to 1

    inside the ball COPY instance (not the prototype)

    if game.grabbed
    -set self.position.x to game.ballx
    -set self.position.y to game.bally
    if game.grabbed
    -set color.alpha 1
    else
    -set color.alpha 0

    Here's the project with the above changes (well and a piece of landscape in the middle for testing).

    http://www.mediafire.com/download/dcscrkub3ou4el3/BallTouchSystemUsingTwoBalls.zip

  • hmgwyhmgwy Member Posts: 4

    Amazing job @tintran! I can't thank you enough. I was thinking about swapping out the ball image with that of a static ball to cover up the glitchiness and you totally beat me to the chase but in a much more efficient manner!

    Seriously, this has been bogging me down for quite some time. Thanks a million!

  • tintrantintran Member Posts: 453

    @hmgwy said:
    Amazing job tintran! I can't thank you enough. I was thinking about swapping out the ball image with that of a static ball to cover up the glitchiness and you totally beat me to the chase but in a much more efficient manner!

    Seriously, this has been bogging me down for quite some time. Thanks a million!

    I am not familiar with GS and didn't know you couldn't change physics attributes at run time, I can't think of the reason why that is so this is hack

Sign In or Register to comment.