Java-Gaming.org Hi !
 Featured games (84) games approved by the League of Dukes Games in Showcase (603) Games in Android Showcase (171) games submitted by our members Games in WIP (650) games currently in development
 News: Read the Java Gaming Resources, or peek at the official Java tutorials
Pages: [1]
 ignore  |  Print
 [SOLVED]Collision Detection Types and which is the best  (Read 3227 times) 0 Members and 1 Guest are viewing this topic.
wreed12345

JGO Knight

Medals: 25
Projects: 2
Exp: 2 years

http://linebylinecoding.blogspot.com/

 « Posted 2013-04-15 21:35:40 »

Hey Guys! Just a question about collision detection here: I know about the simple AABB method but unfortunately that will not be sufficient for my most recent game. And I also know a little about pixel perfect collision although that seems like overkill for a simple game like mine. So I came up with two things: Separating axis theorem or detecting if the polygons overlap. Both would require me to make a polygon out of them otherwise it would just be like AABB. So my question is do you have any recommendations for which one? (It seems like i might use both or they are interchangeable) and any articles or tutorials for these. I have been trying to get some help online but it just makes me more confused than when I started So I could use some help from the awesome community! I figured I need help creating polygons (defining vertices? or create triangles (essentially the same)) and then a little with overlapping testing. I have read up on articles about these although the code examples or other help I have found is not to helpful....

EDIT:
Currently I just have images created (different shapes that the full rectangle) and no polygons for a close surrounding area of the thing in the image

EDIT 2:
A thought of how it would work with polygons drawn

UprightPath
 « Reply #1 - Posted 2013-04-15 22:05:48 »

Yay, my cents!

AABB vs Polygon: Depends on how close to 'realistic' physics you want. Typically, your player will always be an AABB object with limited physics applied to them. That is: If they're standing on the ground then they're standing on the ground and gravity doesn't matter to them. At most, you'll do some basic 'friction' computations for slopes, differing ground types, etc.

The world: AABB can be good for doing a broad-phase resolution (There are MANY strategies). The only way an AABB agent can collide with something is when their AABBs intersect. After you find out that there MIGHT be a collision, then you go to the narrow-phase where you check the geometries. :3

wreed12345

JGO Knight

Medals: 25
Projects: 2
Exp: 2 years

http://linebylinecoding.blogspot.com/

 « Reply #2 - Posted 2013-04-15 22:08:42 »

In my game (which you can check out in my WIP section) is an rpg based so you are not moving at one level. AABB seems good for a broad phase but the polygon / other type of collision detection is the part where im confused.
EDIT:
the reason im thinking aabb is not suffiecent is that it creates a rectangle and creates possible collision areas which are not exactly close to the player or the object in the image. This is shown in the image of the first post.

Jimmt
« League of Dukes »

JGO Kernel

Medals: 162
Projects: 5
Exp: 3 years

 « Reply #3 - Posted 2013-04-15 22:17:47 »

Your polygon strategy isn't going to work for a 2d rpg style game, because then the player will collide with the tree even when the player should be going behind the tree. You should be thinking (red lines)

Like with tiles. Remember, with this type of game, you're faking the height, because the player moves in x/y but you still have the height of the player and the tree.
wreed12345

JGO Knight

Medals: 25
Projects: 2
Exp: 2 years

http://linebylinecoding.blogspot.com/

 « Reply #4 - Posted 2013-04-15 22:20:38 »

Hey that actually makes a lot of sense! It also simplifies a lot of things. My only question now would be how could I change the order that these things are drawn so that it appears behind the tree...? Also I think there are still some objects that you can not pass around like an oddly shaped lake which I would need some type of polygon detection on

Jimmt
« League of Dukes »

JGO Kernel

Medals: 162
Projects: 5
Exp: 3 years

 « Reply #5 - Posted 2013-04-15 22:33:01 »

Hey that actually makes a lot of sense! It also simplifies a lot of things. My only question now would be how could I change the order that these things are drawn so that it appears behind the tree...? Also I think there are still some objects that you can not pass around like an oddly shaped lake which I would need some type of polygon detection on
I'd have to agree on the lake, AABB would probably not work. For drawing order, maybe just compare y coordinates, if player y > entity y draw entity in front, and if player y < entity y draw player in front (seems pretty primitive)
wreed12345

JGO Knight

Medals: 25
Projects: 2
Exp: 2 years

http://linebylinecoding.blogspot.com/

 « Reply #6 - Posted 2013-04-15 22:34:45 »

Yeah I think the lake must turn in to polygons or something (But i still don't know how ... ) and also I guess I will have to figure out some system to change drawing order that seems a little challenging to figure out

Agro
 « Reply #7 - Posted 2013-04-15 22:35:06 »

Use the bottom of the object as their collision mask. For humans it would be feet. For tree, it would be the trunk. And then assign radiuses to those positions and you can use circle circle detection to find it. You can also use AABB for this obviously.

wreed12345

JGO Knight

Medals: 25
Projects: 2
Exp: 2 years

http://linebylinecoding.blogspot.com/

 « Reply #8 - Posted 2013-04-15 22:35:51 »

Thanks Agro thats like what Jimmt just said but i would have a problem with using AABB with something weirdly shaped like a lake

Jimmt
« League of Dukes »

JGO Kernel

Medals: 162
Projects: 5
Exp: 3 years

 « Reply #9 - Posted 2013-04-15 22:37:38 »

Yeah I think the lake must turn in to polygons or something (But i still don't know how ... ) and also I guess I will have to figure out some system to change drawing order that seems a little challenging to figure out
For drawing order, I guess just have an ArrayList of entities (or whatever storage format you prefer) and shuffle things around. For the lake, a simple hack-ish solution would to have a list of bounding boxes (i. e. make cut the lake up into big and small rectangles) and then check against all if you want to stick to AABB (which i recommend).
wreed12345

JGO Knight

Medals: 25
Projects: 2
Exp: 2 years

http://linebylinecoding.blogspot.com/

 « Reply #10 - Posted 2013-04-15 22:39:18 »

I guess cutting it into smaller squares would be the simplest way... Hmmm

wreed12345

JGO Knight

Medals: 25
Projects: 2
Exp: 2 years

http://linebylinecoding.blogspot.com/

 « Reply #11 - Posted 2013-04-15 23:31:20 »

Would that be considered the right way to do this? I feel like I have never seen this in other peoples code / examples. Any suggestions on how / what to look into for polygon collision?

ctomni231

JGO Wizard

Medals: 99
Projects: 1
Exp: 7 years

Not a glitch. Just have a lil' pixelexia...

 « Reply #12 - Posted 2013-04-16 00:35:13 »

I think using the AABB method would be your best solution. To be honest, it'll be the fastest and since your game is kind of tile-based, you'll probably benefit the most by doing your logic in that way. If you complicate your logic with polygons and splitting it up, you'll slow down your game for a feature that most people will not care about. The only way I'd recommend it is if you are doing it as a learning exercise, and in that case... go crazy!

As for your drawing idea, If you want your 2D textures to have depth and appear above and below certain items. If your game is based off of tiles, you want to draw your images ordered from the top to bottom listed from the bottom of each sprite. That way, combined with collision detection, you'd be able to 100% fake the 3-D effect in a 2-D plane.

I hope this makes some sense.

Agro
 « Reply #13 - Posted 2013-04-16 00:40:50 »

Also, a lake would be best as having a square. Tile games don't generally make lakes go all random this way and that. So yes, AABB would be your best bet.

wreed12345

JGO Knight

Medals: 25
Projects: 2
Exp: 2 years

http://linebylinecoding.blogspot.com/

 « Reply #14 - Posted 2013-04-16 00:44:19 »

I think using the AABB method would be your best solution. To be honest, it'll be the fastest and since your game is kind of tile-based, you'll probably benefit the most by doing your logic in that way. If you complicate your logic with polygons and splitting it up, you'll slow down your game for a feature that most people will not care about. The only way I'd recommend it is if you are doing it as a learning exercise, and in that case... go crazy!

As for your drawing idea, If you want your 2D textures to have depth and appear above and below certain items. If your game is based off of tiles, you want to draw your images ordered from the top to bottom listed from the bottom of each sprite. That way, combined with collision detection, you'd be able to 100% fake the 3-D effect in a 2-D plane.

I hope this makes some sense.

So your saying you think splitting up complex shapes into rectangles would be the best rather than polygons?

By your drawing suggestion would you recommend changing what is drawn based off of the y coordinate as Jimmt did?

Also, a lake would be best as having a square. Tile games don't generally make lakes go all random this way and that. So yes, AABB would be your best bet.

I'm not too sure if this is tile based, I don't exactly have a tile set created I am just creating images as I go but I suppose you could still call it a tile set> Also a square lake would look very awkward and I don't think I will use that approach

Jimmt
« League of Dukes »

JGO Kernel

Medals: 162
Projects: 5
Exp: 3 years

 « Reply #15 - Posted 2013-04-16 01:02:21 »

I think Agro is talking about something like this:

See how it's not the entire lake that's made up of a rectangle, but it is in rectangular tiles. That's why it's important to make your tiles the right size.
(The rounded corners in my example are purely graphical, I'm pretty sure collision detection is still handled AABB style).
Agro
 « Reply #16 - Posted 2013-04-16 01:08:13 »

Yeah, things also like pokemon. The rounded edges are graphical enhancements, they don't affect its bounding box.

wreed12345

JGO Knight

Medals: 25
Projects: 2
Exp: 2 years

http://linebylinecoding.blogspot.com/

 « Reply #17 - Posted 2013-04-16 01:09:01 »

I like work around. THey make things much easier. I suppose this will have to be the approach I use. Thank you guys for these suggestions

quew8

JGO Knight

Medals: 46

 « Reply #18 - Posted 2013-04-16 11:15:49 »

Sorry I'm late. I know you've kind of already decided but if you ever do want to try complex (and convex) polygon vs aabb detection then sax (Separation Axis Theorem) is a good way to go. It works polygon vs polygon but can be optimized if you know one shape is a aabb.
wreed12345

JGO Knight

Medals: 25
Projects: 2
Exp: 2 years

http://linebylinecoding.blogspot.com/

 « Reply #19 - Posted 2013-04-16 14:54:42 »

Any suggestions for polygon tutorials or something?

Jimmt
« League of Dukes »

JGO Kernel

Medals: 162
Projects: 5
Exp: 3 years

 « Reply #20 - Posted 2013-04-16 16:08:44 »

Any suggestions for polygon tutorials or something?
I thought you were sticking with AABB? Well if that isn't the case then a quick way would be to use (libgdx port of) box2d and Aurelien Ribon's physics body editor (and also here) which can auto-trace shapes and saves to a .json. Box2D is mainly for platformers but you can adapt it to a rpg style game by setting gravity to 0.

If you're going to go this path, also read this on how to separate your collision logic and your rendering.
wreed12345

JGO Knight

Medals: 25
Projects: 2
Exp: 2 years

http://linebylinecoding.blogspot.com/

 « Reply #21 - Posted 2013-04-16 20:16:30 »

I'm pretty sure I'll go with aabb for this but I sure would like to learn about polygon collision. Thanks jimmt

relminator
 « Reply #22 - Posted 2013-04-17 08:15:52 »

wreed12345

JGO Knight

Medals: 25
Projects: 2
Exp: 2 years

http://linebylinecoding.blogspot.com/

 « Reply #23 - Posted 2013-04-18 01:20:24 »

its articles like that, that confuse me

relminator
 « Reply #24 - Posted 2013-04-18 02:03:39 »

its articles like that, that confuse me

What's confusing about the article?  I mean that sat uses a very simple vector projection (2 muls and 1 add).  You might want to read on vectors first before trying to implement collisions more complex than AABBs.
Pages: [1]
 ignore  |  Print

You cannot reply to this message, because it is very, very old.

 Jesse (16 views) 2015-07-29 04:35:27 Riven (37 views) 2015-07-27 16:38:00 Riven (19 views) 2015-07-27 15:35:20 Riven (22 views) 2015-07-27 12:26:13 Riven (12 views) 2015-07-27 12:23:39 BurntPizza (32 views) 2015-07-25 00:14:37 BurntPizza (42 views) 2015-07-24 22:06:39 BurntPizza (24 views) 2015-07-24 06:06:53 NoxInc (31 views) 2015-07-22 22:16:53 NoxInc (21 views) 2015-07-22 22:13:39
 theagentd 51x wessles 45x basil_ 35x orangepascal 28x KaiHH 26x ags1 21x Riven 19x mooman219 17x bornander 14x KudoDEV 13x Jesse 11x princec 11x CelestialCreator 11x klaus 11x Zaneris 9x philfrei 8x
 List of Learning Resourcesby gouessej2015-07-09 11:29:36How Do I Expand My Game?by bashfrog2015-06-14 11:34:43List of Learning Resources2015-05-31 05:37:30Intersection Methodsby Roquen2015-05-29 08:19:33List of Learning Resources2015-05-05 10:20:32How to: JGO Wikiby Mac702015-02-17 20:56:162D Dynamic Lighting2015-01-01 20:25:42How do I start Java Game Development?by gouessej2014-12-27 19:41:21
 java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org