PlatformJumping: CastCollision Vs. Pick[Line/Rect] Vs. Triggers
by Eric Robinson · in Torque Game Builder · 10/03/2006 (11:35 pm) · 69 replies
Okay, I've looked around through the forums, looked into the script functions, [in some cases] skimmed the source, and spent considerable time pondering the issue of jumping/falling for platformer style games.
Here's what I understand as drawbacks for the three different jumping styles:
1) The CastCollision route. This is the route taken in the TGB MiniPlatformerTutorial. The issue I have with this algorithm [at least as implemented in the tutorial] is that it requires you to call "onUpdateScene()" for movement resulting in at least two calls to castCollision() per frame update (the second call was to fix the bug described and fixed here). I feel like this is very inefficient. I believe that movement should not necessarily require a call to "onUpdateScene()".
2) The Pick[Line/Rect] route. I will admit that I don't fully understand this method. From what I understand, however, it would require the same constant updating as the castCollision route.
3) The Triggers route. I don't remember where I saw it (can't find the forum link) but I read a while back about someone using some triggers to determine how physics works when someone jumps. Essentially you map triggers to all the platforms (or walkable surfaces) somewhat akin to the way OneWayCollision platforms work. When the player is in the trigger (onEnter) you set the constantForceY to zero and walk along the platform. Then, when you leave the trigger (onLeave) by walking off the platform or jumping, then you set the constantForceY to something non-zero. The catch here? You have to have triggers everywhere watching for the player (or anything else in their collision groups). Big levels = lots and lots of triggers requiring collision detection. Is this type of collision worse than the tileLayer collision stuff? If not then one could potentially just shut off collision on the tileLayer-level platforms and then use the collision with the triggers to run on...
So I guess it boils down to this: which is more efficient? The castCollision/pickSomething route or the triggers route? The prior requires constant extraneous collision detection while the latter adds a huge amount of objects to the collision system (though you could cut out a whole lot by turning off collision on the tileLayer).
Thoughts?
Here's what I understand as drawbacks for the three different jumping styles:
1) The CastCollision route. This is the route taken in the TGB MiniPlatformerTutorial. The issue I have with this algorithm [at least as implemented in the tutorial] is that it requires you to call "onUpdateScene()" for movement resulting in at least two calls to castCollision() per frame update (the second call was to fix the bug described and fixed here). I feel like this is very inefficient. I believe that movement should not necessarily require a call to "onUpdateScene()".
2) The Pick[Line/Rect] route. I will admit that I don't fully understand this method. From what I understand, however, it would require the same constant updating as the castCollision route.
3) The Triggers route. I don't remember where I saw it (can't find the forum link) but I read a while back about someone using some triggers to determine how physics works when someone jumps. Essentially you map triggers to all the platforms (or walkable surfaces) somewhat akin to the way OneWayCollision platforms work. When the player is in the trigger (onEnter) you set the constantForceY to zero and walk along the platform. Then, when you leave the trigger (onLeave) by walking off the platform or jumping, then you set the constantForceY to something non-zero. The catch here? You have to have triggers everywhere watching for the player (or anything else in their collision groups). Big levels = lots and lots of triggers requiring collision detection. Is this type of collision worse than the tileLayer collision stuff? If not then one could potentially just shut off collision on the tileLayer-level platforms and then use the collision with the triggers to run on...
So I guess it boils down to this: which is more efficient? The castCollision/pickSomething route or the triggers route? The prior requires constant extraneous collision detection while the latter adds a huge amount of objects to the collision system (though you could cut out a whole lot by turning off collision on the tileLayer).
Thoughts?
#42
Sure, the ceiling sticking bugs might be fixed with the overhauled collision detection system in the upcoming release but us users have no idea when that will even become available or what will change / be fixed. We have to work with what we have now. I edited the Platformer Tutorial to get rid of the wall sticking/climbing as best as possible, even though the rewriting includes many 'hacks', to allow for expected simulation (the code should get simpler if the next update arrives with certain clutch fixes).
It just seems that there's a lot of scattered, extremely useful practices for game programming. And heck, even if you don't use the type system you outline above for pseudo type checking, the algorithm is certainly applicable elsewhere. Call it horizon-expanding. :D
11/19/2006 (4:17 pm)
Quote:TGB will most likely eventually have the 'object type' method that was designed for TorqueX rather than the bitmask system it uses today.That's all well and good but us lowly users don't know what's coming down the tubes... This stuff is useful to us now and having even a brief explanation a-la what you wrote above would be extremely helpful for developing games in the present. And perhaps a TDN section called "Best Practices" would be an awesome addition to the Wiki. Heck, you could even preface every entry with "This document applies to versions 1.0.0 to 1.1.2 of the Torque Game Builder." Or even organize the website by TGB version.
Sure, the ceiling sticking bugs might be fixed with the overhauled collision detection system in the upcoming release but us users have no idea when that will even become available or what will change / be fixed. We have to work with what we have now. I edited the Platformer Tutorial to get rid of the wall sticking/climbing as best as possible, even though the rewriting includes many 'hacks', to allow for expected simulation (the code should get simpler if the next update arrives with certain clutch fixes).
It just seems that there's a lot of scattered, extremely useful practices for game programming. And heck, even if you don't use the type system you outline above for pseudo type checking, the algorithm is certainly applicable elsewhere. Call it horizon-expanding. :D
#43
11/20/2006 (2:02 pm)
Users are encouraged to add content to TDN. If you found something useful and want to share it, feel free to post an article. If it's something you think should be included with the documentation you can contact someone here, probably Matt L, and give them a link to it.
#44
So I define onCollision to check whether I'm grounded:
I also redefine the playerJump() function so we can handle the actual jumping in updateVertical():
And the updateVertical() function:
The main thing for me is solving the inability to jump off of certain platforms that one should be able to jump off of. I've no idea why it happens for certain platforms and not others, when they're all of the same type, but shifting the character's position up by a tiny amount before changing the Y velocity completely solves the problem, and seems to work for custom object collision polygons, even without completely flat "bottoms".
As I don't know enough to know whether this solution is highly problematic in some way or not, I'd appreciate any feedback.
11/21/2006 (11:33 pm)
Hmm, so I've only recently started working with TGB, and have been trying to get the functionality of the MiniPlatformerTutorial working correctly. Cutting and pasting the code on the tutorial continued to give me problems, e.g. my character would be unable to jump off certain platforms that were formally no different from any other. I also couldn't figure out how to get the Pick method working. After a lot of struggling, I came up with the following solution, which doesn't handle ramps and is a teeny bit hackish, but otherwise fairly elegant, I think. Or it could be really horrible and violating coding principles that I'm not aware of. This is based entirely on the MiniPlatformerTutorial code:So I define onCollision to check whether I'm grounded:
function t2dSceneObject::onCollision( %srcObj, %dstObj, %srcRef, %dstRef, %time, %normal, %contactCount, %contacts )
{
if (%srcObj == $pGuy && %normal == PI && $pGuy.getLinearVelocityY() >= 0)
{
$pGuy.airborne = false;
}
}I also redefine the playerJump() function so we can handle the actual jumping in updateVertical():
function playerJump()
{
$pGuy.jump = true;
}And the updateVertical() function:
function playerClass::updateVertical(%this)
{
if(%this.getLinearVelocityY() > 3) { [b]// prevents jumping after walking off a platform, as well as queuing an extra jump in mid-jump (Y velocity must be greater than 3, because Y velocity "on the ground" tends to hover between 2 and 3)[/b]
%this.airborne = true;
%this.jump = false;
}
if(!%this.airborne && %this.jump) {
%this.jump = false;
%this.airborne = true;
%this.setPositionY(%this.getPositionY() - 0.01); [b]// this solves the problem of not being able to jump from certain platforms[/b]
%this.setLinearVelocityY(-255);
}
}The main thing for me is solving the inability to jump off of certain platforms that one should be able to jump off of. I've no idea why it happens for certain platforms and not others, when they're all of the same type, but shifting the character's position up by a tiny amount before changing the Y velocity completely solves the problem, and seems to work for custom object collision polygons, even without completely flat "bottoms".
As I don't know enough to know whether this solution is highly problematic in some way or not, I'd appreciate any feedback.
#45
As for the awkward situation with not being able to jump from certain platforms, try rebuilding your map. People have had problems with their TileMaps before and rebuilding the levels fixed those issues (one person was getting stuck on ceilings - rebuilding the level fixed the issue). TileMaps, or at least the collisions they rely on, are a bit buggy as of the current version of TGB (1.1.2).
I would not be surprised in the slightest if your level got corrupted somewhere down the line. I've seen it before!
Let us know how it goes!
11/22/2006 (8:40 am)
Interesting solution to the problem. Note that your linearVelocity values in the updateVertical function (I see a three written there) are completely dependent on your own implementation. I think my speeds hover around 40-50 generally. Thanks for the commenting, though!As for the awkward situation with not being able to jump from certain platforms, try rebuilding your map. People have had problems with their TileMaps before and rebuilding the levels fixed those issues (one person was getting stuck on ceilings - rebuilding the level fixed the issue). TileMaps, or at least the collisions they rely on, are a bit buggy as of the current version of TGB (1.1.2).
I would not be surprised in the slightest if your level got corrupted somewhere down the line. I've seen it before!
Let us know how it goes!
#46
I have tried rebuilding the map before, though, and continued to get problems.
Anyway, definitely appreciate all the work you've put into the tutorial, and in these forums discussions. They've been a huge help.
11/22/2006 (10:14 am)
Yup, yup, the values are definitely implementation-dependent.I have tried rebuilding the map before, though, and continued to get problems.
Anyway, definitely appreciate all the work you've put into the tutorial, and in these forums discussions. They've been a huge help.
#47
Also, you may want to increase the linearVelocity at which your character is moving. Perhaps there just isn't enough "speed" for the system to reliably simulate the physics?
You may have to increase the size of your map for the speed increases to make any sense... unless you have a slow moving character as part of the design...
11/22/2006 (3:59 pm)
When you rebuilt the map were the problematic platforms the same or did they change?Also, you may want to increase the linearVelocity at which your character is moving. Perhaps there just isn't enough "speed" for the system to reliably simulate the physics?
You may have to increase the size of your map for the speed increases to make any sense... unless you have a slow moving character as part of the design...
#48
I've posted a temporary fix which you can make if you have the source version, if not, Thomas posted at the end stating this should be fixed in the 1.1.3 release.
edit: spelling ;)
11/22/2006 (4:05 pm)
Walter: I'm not certain, but it sounds like the sticking to the platform issue you're having is along similar lines to the one I described in this thread.I've posted a temporary fix which you can make if you have the source version, if not, Thomas posted at the end stating this should be fixed in the 1.1.3 release.
edit: spelling ;)
#49
Gary: Yeah, I'm pretty sure I'm having that exact problem. I do have the source version, but right now I'm too lazy to figure out how to recompile a new TGB binary. :P
Thanks for the help, guys, and happy Thanksgiving! (Assuming you're celebrating it. :)
11/23/2006 (3:12 pm)
Eric: When you say "rebuild the map", do you mean scrap the current tilemap and reconstruct it from scratch? That's what I've done, and the sticking points were either in new places or the same. They might have disappeared initially, but returned when editing it.Gary: Yeah, I'm pretty sure I'm having that exact problem. I do have the source version, but right now I'm too lazy to figure out how to recompile a new TGB binary. :P
Thanks for the help, guys, and happy Thanksgiving! (Assuming you're celebrating it. :)
#50
I noticed in another forum you said that you have Mac OSX. I'm not sure what you're using to edit files with but the XCode environment works wonders for script and source editing. I haven't actually edited more than one or two lines in the source, myself, but I have added resources to the project and recompiled virtually without issue every time. If you use XCode, the process is as simple as doing "Build->Clean" and then "Build->Build". Very, very simple.
11/23/2006 (3:54 pm)
Yeah, that's what I meant: start the level from scratch. You said that the issues disappeared initially but returned when you edited the map. Does that mean that after initial creation everything worked fine? How exactly did you edit the map? This might help isolate a few problems...I noticed in another forum you said that you have Mac OSX. I'm not sure what you're using to edit files with but the XCode environment works wonders for script and source editing. I haven't actually edited more than one or two lines in the source, myself, but I have added resources to the project and recompiled virtually without issue every time. If you use XCode, the process is as simple as doing "Build->Clean" and then "Build->Build". Very, very simple.
#51
So I followed your instructions on rebuilding the TGB binary (making sure to apply the fix to t2dPhysics.cc first). After renaming the original and the new build, and commenting out the "%this.setPositionY(%this.getPositionY() - 0.01);" line from my code above, I still get stuck!
Out of curiosity, Eric, are you using a significantly different platforming implementation than the one currently in the MiniPlatformerTutorial, and in either case, does Gary's fix work for you without requiring you to rebuild tilemaps?
EDIT: Whoops, I may have done the rebuild wrong. I did it using the xcodeproj file, which resulted in a Debug version. Will try this again.
EDIT 2: Hm, nevermind. I guess I did it correctly. Only problem is that the Debug version (which is 11MB compared to the original's 35MB) won't build my project into a working app.
11/24/2006 (9:02 am)
I edited tilemaps using the Eraser, Eye Dropper, Paint, and Flood Fill tools, as well as modifying tile sizes and the tilemap's x and y tiles. Should've mentioned before that my tile sizes are currently set to 24x24, with my pGuy at 22x22. I'm not entirely sure if everything worked fine upon tilemap rebuild...I actually don't recall ever getting perfect SPACEBAR->Jump response before implementing my own semi-solution, except maybe in small tilemaps. (Sorry this is so vague.)So I followed your instructions on rebuilding the TGB binary (making sure to apply the fix to t2dPhysics.cc first). After renaming the original and the new build, and commenting out the "%this.setPositionY(%this.getPositionY() - 0.01);" line from my code above, I still get stuck!
Out of curiosity, Eric, are you using a significantly different platforming implementation than the one currently in the MiniPlatformerTutorial, and in either case, does Gary's fix work for you without requiring you to rebuild tilemaps?
EDIT: Whoops, I may have done the rebuild wrong. I did it using the xcodeproj file, which resulted in a Debug version. Will try this again.
EDIT 2: Hm, nevermind. I guess I did it correctly. Only problem is that the Debug version (which is 11MB compared to the original's 35MB) won't build my project into a working app.
#52
I don't know where this rebuilding the level business came from, but let me assure you that the bugs in the collision code will affect your game no matter what. It's easy to attribute them to other things because the sticking doesn't occur all the time, but trust me, rebuilding your levels from scratch will only get you TGB practice. Not that that alone is a bad thing, but I think wasting time rebuilding your levels to try to fix a collision problem is - especially when it doesn't actually do you any good.
Your setPositionY workaround is the reccomended temporary sollution until 1.1.3 is released with the CLAMP response fix. Also, a value of 0.01 (as you posted) should work in almost every case - it's not like the velocity check in that regard.
Edit: Spelling.
11/25/2006 (7:35 am)
I've never personally used XCode, but in VS you can specify whether you want a Debug build or a Release build. Depending on the UI in XCode you might have to dig for the setting, but Release is what you want. I don't know where this rebuilding the level business came from, but let me assure you that the bugs in the collision code will affect your game no matter what. It's easy to attribute them to other things because the sticking doesn't occur all the time, but trust me, rebuilding your levels from scratch will only get you TGB practice. Not that that alone is a bad thing, but I think wasting time rebuilding your levels to try to fix a collision problem is - especially when it doesn't actually do you any good.
Your setPositionY workaround is the reccomended temporary sollution until 1.1.3 is released with the CLAMP response fix. Also, a value of 0.01 (as you posted) should work in almost every case - it's not like the velocity check in that regard.
Edit: Spelling.
#53
How exactly do the tileMap files work? They're not text files so it makes them a bit difficult to debug (so far as I've investigated).
11/25/2006 (7:46 am)
@Thomas: That's not entirely correct. I received a level file from another person suffering from a sticking bug. Everything looked okay. I used his code on my level and things worked perfectly. I used my code on his level and the sticking remained. He rebuilt the entire level and he didn't have the 'sticking to ceiling' problem anymore. I feel like there might be a bug or two in the tileMap code, too.How exactly do the tileMap files work? They're not text files so it makes them a bit difficult to debug (so far as I've investigated).
#54
Thanks for your help, guys.
11/25/2006 (9:35 am)
Ah, found the Release build setting. That did the trick. Jumping works perfectly now without the setPositionY line.Thanks for your help, guys.
#55
As of now, I believe tile layers are stored as a series of tiles, which is why they weren't stored as text by default. Adam has talked about making the tiles reference brushes to make the files smaller and store them uncompiled in either the regular TorqueSctript format, or XML.
11/27/2006 (8:30 pm)
@Eric - I'm not trying to be argumentative, but it seems like the only differences in that thread had to do with custom collision polys. Rebuilding an entire level from scratch to fix this is definitely a waste of time, as you can generally fix that in the level builder without starting from scratch. Tou can paint *just* collision data on tiles without affecting anything else (image, flip, etc).As of now, I believe tile layers are stored as a series of tiles, which is why they weren't stored as text by default. Adam has talked about making the tiles reference brushes to make the files smaller and store them uncompiled in either the regular TorqueSctript format, or XML.
#56
Interesting to hear about the tileLayer files. As for the future, I'd have to cast my vote (what little, if anything, it's worth) for XML. There may be quite a bit of overhead but you can then use any number of XML tools to help you with code production.
@Walter: Great! Good to hear that you got everything to work without more hacking!
11/27/2006 (8:45 pm)
@Thomas: Oh, I'm not trying to be argumentative either. I just wanted to point out that rebuilding a level can help. That our code worked in my level and not his until he rebuilt it points to an issue somewhere in the builder->level-file code potentially. Perhaps it's a random 'rounding/floating point' thing that you get when you build a level within the editor related to the collision bugs. Something's amiss, though, and rebuilding a quick test-level to see if it's the level that's the issue can't hurt. As for painting collision... I hadn't considered that. Good point. Hopefully this will simply become moot in future versions of the engine.Interesting to hear about the tileLayer files. As for the future, I'd have to cast my vote (what little, if anything, it's worth) for XML. There may be quite a bit of overhead but you can then use any number of XML tools to help you with code production.
@Walter: Great! Good to hear that you got everything to work without more hacking!
#57
Hope that helps!
05/01/2007 (8:45 pm)
As of 1.1.3 [at least?] there is a "wall sticking bug" in which [at least?] using a long vertical collision surface could result in the player getting stuck and being able to scale the wall by repeatedly jumping into it. The sticking doesn't occur every time. A script-side solution to this problem is available within this thread. Note that this is applicable to code found within the MiniPlatformerTutorial.Hope that helps!
#58
I have solved a bit of the collision problems in the ninja mini platformer. Though its not perfect yet. The platformer tutorial is updated in TDN.
I am not a programmer and this is more of TGB based solution. But I think using the link above for script solution and working it together with the TGB based solutions, the problem will be sorted out.
Have a look at it, while I test the script.
I think the problem is mainly with how the polygon collision work and updates in the engine and not only with scripting.
06/25/2007 (8:49 am)
EricI have solved a bit of the collision problems in the ninja mini platformer. Though its not perfect yet. The platformer tutorial is updated in TDN.
I am not a programmer and this is more of TGB based solution. But I think using the link above for script solution and working it together with the TGB based solutions, the problem will be sorted out.
Have a look at it, while I test the script.
I think the problem is mainly with how the polygon collision work and updates in the engine and not only with scripting.
#59
Thanks for your work on the tutorial. It's good to see a bunch of potential fixes on the tutorial to give people an idea of things to try if they come across any problems. As for me, I've kind of stagnated at this point. I finished the demo of the game that I'm building and am currently waiting to see if any of the issues will be resolved for the 1.5 update. As it stands, TGB is not a particularly grand engine for platformer style games. The collisions don't seem to handle the problems specific to platformer types.
That being said, perhaps people should try to buck the trend and come up with another type of gameplay that's similar to platformer but different enough that TGB handles it with flying colors. Work within the boundaries, you know...
But now I'm drifting off into "what-if" land.
As for the fixes, the custom polygon you used smacks as similar to a different thread I posted in regarding custom polygons. You can reduce a lot of snags by making your custom polygon fairly standard (using well defined points with "easy angles". Dragging polygon points around ends up producing lots of decimal points that perhaps don't wash out well in T2D. I've found that using numbers like 0, 0.5, 0.75, 1.0, etc. seem to work better overall. That and going about it with 30, 45, 60, etc. degree angles produces some good results. There's a lot of points like that that wouldn't do well on the main Tutorial page, though. The Tutorial tries to be as general as possible and provides a good diving board.
If you come up with anything else, please continue to post your findings! Every little bit helps!
06/25/2007 (6:53 pm)
@Wicked:Thanks for your work on the tutorial. It's good to see a bunch of potential fixes on the tutorial to give people an idea of things to try if they come across any problems. As for me, I've kind of stagnated at this point. I finished the demo of the game that I'm building and am currently waiting to see if any of the issues will be resolved for the 1.5 update. As it stands, TGB is not a particularly grand engine for platformer style games. The collisions don't seem to handle the problems specific to platformer types.
That being said, perhaps people should try to buck the trend and come up with another type of gameplay that's similar to platformer but different enough that TGB handles it with flying colors. Work within the boundaries, you know...
But now I'm drifting off into "what-if" land.
As for the fixes, the custom polygon you used smacks as similar to a different thread I posted in regarding custom polygons. You can reduce a lot of snags by making your custom polygon fairly standard (using well defined points with "easy angles". Dragging polygon points around ends up producing lots of decimal points that perhaps don't wash out well in T2D. I've found that using numbers like 0, 0.5, 0.75, 1.0, etc. seem to work better overall. That and going about it with 30, 45, 60, etc. degree angles produces some good results. There's a lot of points like that that wouldn't do well on the main Tutorial page, though. The Tutorial tries to be as general as possible and provides a good diving board.
If you come up with anything else, please continue to post your findings! Every little bit helps!
#60
I understand the stagnation. Even I realized that TGB is not good for platformers overall, thats why I bought TGB with TXB and the platformer starter kit for TXB.
Even if I fail to finish the game with TGB , I will have a ready made template in TXB to finish my game.
Yes I will be restricted to only windows platform but better I make something then nothing at all.
Only problem : learning them together is grilling me to core :)
Thanks for your feedback and for that data. That will really help.
I have just started, still a long way to go. I have no idea yet how to make ai of enemy work.
Will keep posting as I learn more..
Thanks again.
06/26/2007 (12:20 am)
EricI understand the stagnation. Even I realized that TGB is not good for platformers overall, thats why I bought TGB with TXB and the platformer starter kit for TXB.
Even if I fail to finish the game with TGB , I will have a ready made template in TXB to finish my game.
Yes I will be restricted to only windows platform but better I make something then nothing at all.
Only problem : learning them together is grilling me to core :)
Thanks for your feedback and for that data. That will really help.
I have just started, still a long way to go. I have no idea yet how to make ai of enemy work.
Will keep posting as I learn more..
Thanks again.
Torque Owner Thomas Buscaglia
I think the more immediate problem is the search functionality on the site. I agree that we are lacking in that area on the site/forums aswell as on TDN.