non-physics collision detection major problem

Getting Started Newbie Questions
#1

I’m having a major problem with non-physics collision detection and really hope someone can help.  I’m going crazy here.

I have a scene in a game that mimics an unblock-style puzzle.  Slide objects around to make a path, that sort of thing.  I’m using code from the tutorials, and collision detection works - up to a point.  If the object you’re sliding gives another object a tiny “love tap” then everything is good.  But if you put any oomph behind it at all, basically flick the object, it either gets stuck on the second object or nearly sails over it.  It looks horrible.

It seems like a simple solution would be to eliminate the ability for a player to flick.  I have no idea how to do this, or even if it’s possible.  Another thought was to greatly slow down the speed of the objects being slid around, but, again, I have no clue how.  I also thought I could implement a more aggresive detector on movement, something that detects the position of the object being moved and holds it back.  But, once more, I don’t know how to do this, despite hours of trying.

The code, as you can see, is very basic, straight from the tutorial on non-physics collisions.

&nbsp; local function metObstacle( obj1, obj2 ) &nbsp; &nbsp; &nbsp; &nbsp; local left = obj1.contentBounds.xMin \<= obj2.contentBounds.xMin and obj1.contentBounds.xMax \>= obj2.contentBounds.xMin &nbsp; &nbsp; &nbsp; &nbsp; local right = obj1.contentBounds.xMin \>= obj2.contentBounds.xMin and obj1.contentBounds.xMin \<= obj2.contentBounds.xMax &nbsp; &nbsp; &nbsp; &nbsp; local up = obj1.contentBounds.yMin \< obj2.contentBounds.yMin and obj1.contentBounds.yMax \> obj2.contentBounds.yMin &nbsp; &nbsp; &nbsp; &nbsp; local down = obj1.contentBounds.yMin \> obj2.contentBounds.yMin and obj1.contentBounds.yMin \< obj2.contentBounds.yMax &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return (left or right) and (up or down) &nbsp; &nbsp; end &nbsp; &nbsp; &nbsp; local function pinSlide( item ) &nbsp; &nbsp; &nbsp; &nbsp; local target = item.target &nbsp; &nbsp; &nbsp; &nbsp; local phase = item.phase &nbsp; &nbsp; &nbsp; &nbsp; if item.phase == "began" then &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; local parent = target.parent &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; display.getCurrentStage():setFocus( target )&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; target.isFocus = true &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; target.y0 = item.y - target.y &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; target.yStart = target.y &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; target:toFront() &nbsp; &nbsp; &nbsp; &nbsp; elseif ( target.isFocus ) then &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if ( phase == "moved" ) then &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if metObstacle( target, obstacle1 ) then &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; target.y = target.y + 25 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; display.getCurrentStage():setFocus( nil ) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; target.isFocus = false &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; else &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; target.y = item.y - target.y0 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; end &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; elseif ( phase == "ended" or phase == "cancelled" ) then &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; display.getCurrentStage():setFocus( nil ) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; target.isFocus = false &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; end &nbsp; &nbsp; &nbsp; &nbsp; end &nbsp; &nbsp; &nbsp; &nbsp; return true &nbsp; &nbsp; end &nbsp; &nbsp; &nbsp; pin1:addEventListener( "touch", pinSlide ) &nbsp;

For simplicity’s sake, this code just represents one object being dragged - slid along the y - and one obstacle.  Also, for what it’s worth, I tried physics collisions, and the player can still fling an object over an obstacle.

I’m sure there’s something really simple I’m missing here.

#2

As an update, I did manage to find a workaround.  I incorporated a runtime listener, making the same checks for collision, and that helped a lot.  It no longer breaks or gets stuck.  However, if anyone knows how or if you can limit the flick gesture, that would still be good to know.  Thanks!

#3

If your game is similar to this one. I think you could use swipe (like in this post on Corona Blog) and move touched object accordingly with constant velocity as far as it doesn’t collide with another object or screen edge.  

#4

Thanks, Idurniat.  I like that solution.  I had looked briefly at that post on the blog, but I didn’t read it carefully enough.  What I like about it is it uses transition.to, rather than a general drag, and that should keep the slide under control.  Thanks again.

#5

Thanks again for the help, but I have a new question.  Using the technique described in the above referenced post, how would you detect a collision during a transition.to event?  You can pause a transition, but I can’t seem to figure out how to detect it before it collides.  The transition completes no matter what.  Any thoughts on how you would get it to recognize an obstacle ahead of time?

#6

If anyone else has any thoughts, I could really appreciate the help.  I feel like with each passing hour, I’m slowly losing my mind.

As discussed, I’m trying to create a puzzle of the unblock variety.  My original approach (code above) used a dragging technique, and although it worked to a point, it caused problems, objects getting stuck on each other, jumping obstacles, etc.  I managed a workaround, with a runtime event listener to detect collisions, and that helped a lot, but it stills breaks every once and a while, and it feels inelegant.

I liked Idurniat’s suggestion, managing the objects’ movement using transition.to.  It’s much more elegant, but I can’t for the life of me figure out how to detect collisions now.  The non-physics collision tutorial everyone references doesn’t seem to apply.  (Unless I’m missing something, which I very likely am.)

I’ve tried combining physics principles, or going the physics route entirely, but that brings up a whole new slew of fun problems.  With physics, everything works great until items collide.  Then no matter what I do the objects float off or bounce off or just break.  I’m sure the physics engine is an amazing piece of programming.  And it’s very possible that I shouldn’t even be applying it to my situation.  But why - WHY can’t you simply have physical objects that stay still after they collide?  That’s all I want - to move items around, some on the x, some on the y, and for those moving items to stop when they hit another object.

Does anyone have any suggestions?

#7

I would find destination position of block (element you could move by swipe gesture)  before call transition. So during transition I don’t need worry about collision. You can archieve this by using grid and putting everthing in it (picture below). Next step is collision dectection but it is easy. If you know in which direction (left, right, up, down) block needs be moved you move block one cell in this direction  and check if it collide with other blocks if no you move it again. I think get idea. :slight_smile: On picture below I move green block in right. Blue and purple blocks are used  to find destination position for green block. Sorry for my english :slight_smile:

Ac7mt3p.png

#8

Idurniat, thanks for the reply.  I was thinking along the same lines, but I’m still having trouble making it work.  You would have an invisible block go out ahead and check for obstacles, in other words?  I like the idea of a grid.  That may be what I was missing.

What do you think of using the physics engine?  Probably overkill?  When I couldn’t get non-physics to work, I tried physics and have been having some success with it.

#9

As an update, I did manage to find a workaround.  I incorporated a runtime listener, making the same checks for collision, and that helped a lot.  It no longer breaks or gets stuck.  However, if anyone knows how or if you can limit the flick gesture, that would still be good to know.  Thanks!

#10

If your game is similar to this one. I think you could use swipe (like in this post on Corona Blog) and move touched object accordingly with constant velocity as far as it doesn’t collide with another object or screen edge.  

#11

Thanks, Idurniat.  I like that solution.  I had looked briefly at that post on the blog, but I didn’t read it carefully enough.  What I like about it is it uses transition.to, rather than a general drag, and that should keep the slide under control.  Thanks again.

#12

Thanks again for the help, but I have a new question.  Using the technique described in the above referenced post, how would you detect a collision during a transition.to event?  You can pause a transition, but I can’t seem to figure out how to detect it before it collides.  The transition completes no matter what.  Any thoughts on how you would get it to recognize an obstacle ahead of time?

#13

If anyone else has any thoughts, I could really appreciate the help.  I feel like with each passing hour, I’m slowly losing my mind.

As discussed, I’m trying to create a puzzle of the unblock variety.  My original approach (code above) used a dragging technique, and although it worked to a point, it caused problems, objects getting stuck on each other, jumping obstacles, etc.  I managed a workaround, with a runtime event listener to detect collisions, and that helped a lot, but it stills breaks every once and a while, and it feels inelegant.

I liked Idurniat’s suggestion, managing the objects’ movement using transition.to.  It’s much more elegant, but I can’t for the life of me figure out how to detect collisions now.  The non-physics collision tutorial everyone references doesn’t seem to apply.  (Unless I’m missing something, which I very likely am.)

I’ve tried combining physics principles, or going the physics route entirely, but that brings up a whole new slew of fun problems.  With physics, everything works great until items collide.  Then no matter what I do the objects float off or bounce off or just break.  I’m sure the physics engine is an amazing piece of programming.  And it’s very possible that I shouldn’t even be applying it to my situation.  But why - WHY can’t you simply have physical objects that stay still after they collide?  That’s all I want - to move items around, some on the x, some on the y, and for those moving items to stop when they hit another object.

Does anyone have any suggestions?

#14

I would find destination position of block (element you could move by swipe gesture)  before call transition. So during transition I don’t need worry about collision. You can archieve this by using grid and putting everthing in it (picture below). Next step is collision dectection but it is easy. If you know in which direction (left, right, up, down) block needs be moved you move block one cell in this direction  and check if it collide with other blocks if no you move it again. I think get idea. :slight_smile: On picture below I move green block in right. Blue and purple blocks are used  to find destination position for green block. Sorry for my english :slight_smile:

Ac7mt3p.png

#15

Idurniat, thanks for the reply.  I was thinking along the same lines, but I’m still having trouble making it work.  You would have an invisible block go out ahead and check for obstacles, in other words?  I like the idea of a grid.  That may be what I was missing.

What do you think of using the physics engine?  Probably overkill?  When I couldn’t get non-physics to work, I tried physics and have been having some success with it.