Collision With Large 2D Terrain
by Paul Drust · in Torque Game Builder · 06/05/2008 (12:32 am) · 9 replies
I'm recreating a "Lunar Lander" game in TGB as a training tool to familiarize myself with TGB and I'd like to know what might be the best way to manage collisions between my lander (a small sprite) and my 2D profile landscape (a very wide, irregularly shaped sprite)?
I'm using the "platformer" camera so the camera will follow the lander and the 2D terrain will scroll sideways as the lander moves left and right.
The terrain sprite is too large to allow setting collision points through the UI with any accuracy. I guess I could breakup the terrain into smaller chunks and give each of those a tight collision polygon.
Anyway, I'm a noob with TGB so any ideas are welcome.
Thanks.
I'm using the "platformer" camera so the camera will follow the lander and the 2D terrain will scroll sideways as the lander moves left and right.
The terrain sprite is too large to allow setting collision points through the UI with any accuracy. I guess I could breakup the terrain into smaller chunks and give each of those a tight collision polygon.
Anyway, I'm a noob with TGB so any ideas are welcome.
Thanks.
About the author
#2
I want my terrain profile to be "rugged" which means I will have to create a LOT of individual sprites to represent rocks/mountains and give them each their own collision polygon because the collision polys must be convex.
Dang! Unless someone has a better plan.
06/05/2008 (12:15 pm)
Actually, my idea has a flaw.I want my terrain profile to be "rugged" which means I will have to create a LOT of individual sprites to represent rocks/mountains and give them each their own collision polygon because the collision polys must be convex.
Dang! Unless someone has a better plan.
#3
By giving it a little perspective, you can have the lander hit the deck with some of the graphic behind it, giving the illusion of depth.
06/05/2008 (1:00 pm)
I would be a background layer of some distant hills/mountains and a foreground layer with a little perspective so that you can create a flat collision boundary on it to actually do the landing. By giving it a little perspective, you can have the lander hit the deck with some of the graphic behind it, giving the illusion of depth.
#4
I had a similar issue regarding doing mouse picking using a color keyed image for 2D board games.
i.e. I wanted a way to detect mouse clicks on a sprite without defining a collision poly.
The only way to make collisions work is to define a collision polygon, unfortunately there is no way to make it concave, for sharp hills, and valleys this will not work because it will not be convex and the collision poly tool will not allow you to save a non-convex collision poly.
The only way to make this work, AFAIK, is to modify the engine source code to add in either the ability to have concave collision poly's or a way to have pixel perfect collisions, and I'm sure there is other methods that I don't know of.
Most of these sound like fairly significant modifications to the engine.
But maybe someone else has a solution that hasn't been explored yet.
06/05/2008 (1:15 pm)
I think Paul is looking for pixel perfect collisions... ala old school 2D games.I had a similar issue regarding doing mouse picking using a color keyed image for 2D board games.
i.e. I wanted a way to detect mouse clicks on a sprite without defining a collision poly.
The only way to make collisions work is to define a collision polygon, unfortunately there is no way to make it concave, for sharp hills, and valleys this will not work because it will not be convex and the collision poly tool will not allow you to save a non-convex collision poly.
The only way to make this work, AFAIK, is to modify the engine source code to add in either the ability to have concave collision poly's or a way to have pixel perfect collisions, and I'm sure there is other methods that I don't know of.
Most of these sound like fairly significant modifications to the engine.
But maybe someone else has a solution that hasn't been explored yet.
#5
If the user collides with a pad, the pads collision code checks that the lander doesn't stick over the edge of the pad. If the lander is over the edge that is a crash. That part is working fine.
However, I also want to trigger a crash when the lander misses the pad entirely and collides with the terrain, but that is the tough part.
I thought of checking the colors of certain pixels around the bottom and edges of the lander and if they are the color of the terrain then that triggers a crash.
However, I would prefer to use TGBs collision detection, but I don't see how to do it without creating a lot of rock/mountain sprites that guarantee everyone has convex collision polys.
06/05/2008 (1:28 pm)
Just for clarity, I have discrete landing pads that the user must land on to be successful.If the user collides with a pad, the pads collision code checks that the lander doesn't stick over the edge of the pad. If the lander is over the edge that is a crash. That part is working fine.
However, I also want to trigger a crash when the lander misses the pad entirely and collides with the terrain, but that is the tough part.
I thought of checking the colors of certain pixels around the bottom and edges of the lander and if they are the color of the terrain then that triggers a crash.
However, I would prefer to use TGBs collision detection, but I don't see how to do it without creating a lot of rock/mountain sprites that guarantee everyone has convex collision polys.
#6
Might have already realized this, but you can use a bunch of sceneobjects without images to define your collision bounds - that way they don't have to all be convex images with convex collision polys. You could even go so far as to group them and only activate the group's collision settings when the ship is above them - or when it reaches a certain area nearby them (not sure if that would help since the engine is already doing that sort of thing, but giving it some hints for your specific gameplay might work well). This method (hidden objects that actually do the collision) is how I would do it.
Also, remember that most players won't notice (or will even be happy) if their ship goes into the land a little bit in some parts without killing them.
Anyway, it would be nice for us if you posted an image of the terrain - I don't know how many collision bounds you're talking about. If there's just a ship sending collisions and the terrain is receiving, you shouldn't have any slowdown from the collision detection, so the bottleneck is just drawing lots of collision bounds, no? Unless you're talking about ten screens of high frequency terrain, that shouldn't take more than ten minutes or so.
Hope that helps a little.
06/05/2008 (5:57 pm)
Not sure how helpful what I say will be, but here are some things to consider.Might have already realized this, but you can use a bunch of sceneobjects without images to define your collision bounds - that way they don't have to all be convex images with convex collision polys. You could even go so far as to group them and only activate the group's collision settings when the ship is above them - or when it reaches a certain area nearby them (not sure if that would help since the engine is already doing that sort of thing, but giving it some hints for your specific gameplay might work well). This method (hidden objects that actually do the collision) is how I would do it.
Also, remember that most players won't notice (or will even be happy) if their ship goes into the land a little bit in some parts without killing them.
Anyway, it would be nice for us if you posted an image of the terrain - I don't know how many collision bounds you're talking about. If there's just a ship sending collisions and the terrain is receiving, you shouldn't have any slowdown from the collision detection, so the bottleneck is just drawing lots of collision bounds, no? Unless you're talking about ten screens of high frequency terrain, that shouldn't take more than ten minutes or so.
Hope that helps a little.
#7
I hadn't thought of using invisible sprites for this. The terrain is not overly complex because this is really just a test-bed for me to see what TGB is all about. However, I do want it to be playable and fun for my young sons when I'm done.
FYI: I can't seem to get the [image] tag to display the terrain profile. Anyone know the reason?
[image]C:/Program Files/TorqueGameBuilder-1.7.3/games/BehaviorPlayground/game/data/images/PD_LandScape_Wide2.png[/image]
06/06/2008 (7:08 am)
Tom,I hadn't thought of using invisible sprites for this. The terrain is not overly complex because this is really just a test-bed for me to see what TGB is all about. However, I do want it to be playable and fun for my young sons when I'm done.
FYI: I can't seem to get the [image] tag to display the terrain profile. Anyone know the reason?
[image]C:/Program Files/TorqueGameBuilder-1.7.3/games/BehaviorPlayground/game/data/images/PD_LandScape_Wide2.png[/image]
#8
You'll have to upload it to an image hosting site.
06/06/2008 (7:52 am)
That's a filepath to the image on your own computer :)You'll have to upload it to an image hosting site.
Associate James Ford
Sickhead Games
You could also try a tilemap for the terrain. You would have less control over the collision polygon shape of an individual "tile" though, than if you represent each as its own, say, t2dStaticSprite or t2dSceneObject.