Ask GarageGames

#1 Well I suppose I'll take the plunge and go first. :)

Before that though, I just wanted to say "thanks" to Matt for taking the time to do this -- I know they've got a lot on their plate at this point with Torque2 under full steam and whatnot, but I just wanted to say how much I appreciate the continued support of TGB and their other products. Many of us will be very sorry to see TGB go, but we have high hopes for what Torque2 will bring us, so we're looking forward to that. :)

Anyways, on to the question.

One of the best tutorials that really helped me get off the ground with TGB was the MiniPlatformerTutorial -- an excellently minimalistic (but expandable) start to a platformer game. It takes great advantage of the powerful TGB tile engine, and it helps make level creation a breeze. It has less than 100 lines of code, which makes it altogether simple and understandable to new users of TGB. In short, it's a fantastic tutorial.

However, there are a few issues that still crop up from time to time, and unless I've missed something, I've not yet found a solid way to fix the issue.

One such issue is the ability to climb walls or stick on ceilings. By twiddling with collision box sizes and scalings, you can mostly hide the problem, but it seems that the TGB collision resolution code has some issues with allowing objects to intersect with each other, and thereby get somewhat "stuck".

Anyways, I'm not entirely sure as to all of the causes of the wall-climbing bug, but reports of it are wide and varied.

One attempted solution was to always apply a downward force to the player. I don't know how this still plays out, but in old versions of TGB (1.1.3-ish), it would make the player jitter and skip along the floor, and especially if your camera was hard-mounted to your player, the full-screen jitter made your eyes all woogly.

Another solution was to modify the player's collision box on-the-fly with hard-coded values, so as to get around this problem. If it were for some esoteric feature of TGB, then I think resorting to this hack would be more acceptable. But if such a hard-coded workaround is presented as "the way" to do even the most basic platformer, then that's not a very good presentation of the ability of TGB.

Another solution was to save the player's position/velocity, set his velocity temporarily to 0, then move the player in miniscule amounts left/right/down, and then cast collision to check to see if the player's really on the ground or just stuck in a wall/ceiling. After checking, the player's original position/velocity would be restored. This is certainly less hackish than modifying collision boundaries on the fly with hardcoded numbers, but I'm still hoping for a simpler solution.

Another (partial) solution was to remove the collision map of the tile map, and just create your own t2dSceneObjects with collision boundaries, and if you want one-way platforms, then create triggers with them too. Sadly, this takes away the ability to create levels with the tile engine, rendering the per-tile-collision-boxes of the tile engine to a useless feature. Even so, I've historically not found this to be a perfect solution for removing TGB collision bugs.

There may be other solutions that I've missed. I typed most of this from memory, and while I think it is accurate information, I hope that I have not gone too far away from truth. Up until today, I actually hadn't heard of anyone successfully creating a glitch-free platformer without using any of the above hacks. I'm hoping for a TGB example of similar similar scope/behavior to the SlickSet Simple Platformer example.

I think one of my larger issues surrounding this issue is the lack of confidence that instills in me for the TGB collision-resolution physics system -- even in the Behavior Playground example that came with TGB 1.5, when flying the space-ship in the upper-left corner, you can get some very odd collision behavior when coasting and colliding with that center barrier.

So I guess my question to GG is this:
What is the GG-intended "best practice" method for resolving the wall-climbing issue in the MiniPlatformer example (hopefully while still using the physics and tile engines of TGB)?

Thank you very much for your time. :)

Respectfully,
Clint Herron

#2 Great post Clint... I've seen this error numerous times. Quick question, do you (or anyone else reading this) have a project with this already put together that I can use to just jump in there (as well as making sure what I test against is in fact the issue).

#3 Sure thing -- we actually just made one a few days ago as a birthday present for a friend. By tweaking with the collision box sizes, I was able to get rid of ceiling sticking bugs, but you can still wall climb if you jump into the side of a column. You can find the download link for it here:
BDL_Final.zip (15.2 M)

IIRC, it builds off of a fairly faithful following of the MiniPlatformer tutorial, though we added a few peripherals.

--clint

Edit: I found an older build of the game where you can still get stuck in the ceilings, depending on what you jump up into.
BDL_2007_10_26_First_Proto.zip

#4 @Clint:
Heh! I got stuck to the ceiling on your final build :P Jump at a ceiling while running to the side. I'm using OS X.

#5 @Matt Van Gorkom:
Hah, I guess you're right, I didn't even catch that!

Ah well. :)

#6 Use oncollision callback, and use "mRadToDeg(mAsin(getWord(%normal, 0)));" to get the angle of the collision in degree. Then, according to the degree the player collide with tilemaps, you can make the right reaction to prevent those type of bugs.

#7 Ok, I tried it two different methods that seem to work on the surface, let me know how they work for you and what you think.


1)

In this method I create a "testCollision" object and mount it to the player, just past the tip of the foot and a bit higher (to prevent colliding with the floor). Then when the player does it's move updates I do a castCollision on this testCollision object (it's set to not collide with the player). If it finds something then the players x velocity isn't updated. The collision settings on this object could be updated to only collide with the proper object groups & layers. This seems to work on initial tests, let me know if you run into further issues.

Wall Climb Issue 01

2)

This method is basically what Benjamin suggested though I'm not getting a degree I simply am checking if you collide with the TileMap class and if the x normal is over 0.8 (or over -0.8), you could add a y check to make it more effective also. Doing the degree step would be a good way to progress this further into a more solid solution.

Wall Climb Issue 01



Let me know if either or neither of these work for you and/or if you run into further issues with these "fixes" :)

#8 Great -- thanks a lot for the fixes, Matt! :) I really appreciate you taking the time to look at this. Sorry for not getting back to you sooner.

It seems like Fix #2 is the more generic and general-use workaround for this issue -- it's not a fix for collision code, but it's small and general-purpose and I can roll with it. Thanks! :) I guess we should update the MiniPlatformer tutorial with this method?

If I can ask a somewhat probing question related to this issue (and if you can't answer right now, that's fine -- I understand)...

Now that there is more "transparent" development with GarageGames, is there any sort of publicly-viewable roadmap for what's planned for TGB between now and Torque2? I've just got a funny feeling that the collision-resolution bugs that are at the root of this problem won't see fixes in TGB's lifecycle.

Again, if you can't answer that, that's fine.

Thanks again!

--clint

#9 Argh!

Well Matt, I just tried out your fixes, and I was able to reproduce the bug in both versions. (Note the standing poses, rather than a running, jumping, or falling pose -- in both situations, the character was standing there without me pressing buttons, falling downwards *very* slowly, giving me plenty of time to take a screenshot before he made his way to the bottom of the wall he was climbing).

Screenshot of bug occurring in version 1 (notice the little sprite artifact from the second collision box you made):


Screenshot of bug occurring in version 2 (no visual artifacts, but this one felt easier to reproduce than in version 1):


I'm sorry to be the bearer of bad news -- thanks a lot for your help on this one, Matt! We might be close with one of these -- it might just be something small we're missing.

--clint

#10 The fixes I posted were specifically handling when you run into a wall and preventing the climb effect... were these taken in the case of falling and/or jumping against the wall?

I didn't think you meant that be the scope of the issue so I stopped there, though I have some ideas on handling that situation as well.

#11 Yes -- these were taken when jumping next to a wall, or falling next to a wall. If you jump and collide with a wall, you can sometimes just stand there (or at least have enough ground under you to jump again). Likewise, you can get it such that if you collide with the ceiling, you can get stuck in the ceiling and walk along as if you were on the ground. Sometimes you can hit a corner and it will "unstick" your collision box so that you can fall to the ground again, but this doesn't always work. Here's a screenshot of the ceiling-walk in action:




You know what's crazy? I never even noticed the wall-climbing bug that you just fixed. I think it was just too subtle for me to notice before. I always thought it meant the wall-jumping issue.

Thanks a lot for the help, and again -- sorry for not being clear enough about the issues at hand.

--clint

#12 Will the 1.5.2 update fix the Camera Jittery Mounting issue ?

#13 Matthew

Is there a way an owner of the new TGB get the old checkers demo from the previous iterations?

#14 @Donald
Download TGB1.1.3. Login with your account and looks at your TGB download: 1.1.3 is still available.
Then, use the 1.1.3 documentation.

#15 It's obvious that the TGB community wants more official tutorials geared more towards plat forming type games. My question is, what is GarageGames doing about this and the fact that the TGB docs are a bit on the outdated side? Considering that TGB is such a great tool one would think we should've seen much better up-to-date documentation for it.

#16 Edel, your questions have been raised by a lot of people. In response to your documentation question, Matthew has a rather large post which remains on the front page regarding the documentation and how people feel about it.

#17 Hey Matt,

I'm not sure if you still have time for this (if not, that's okay), I'm still curious as to how one should get around the collision-box-intersection bugs that cause the wall and ceiling sticking issues. I know I mentioned ceiling-sticking in my first post, but sorry for not being clear enough about my real question at the time.

--clint

#18 Hey Clint,

Thanks for bringing this back up... currently have been working hard to get the next TGB release out, as mentioned in a previous post by Deborah we are really trying to get it out this week. After this gets out I'll try to spend some good time on the forums responding to any questions that may arise as well as keeping an eye on any issues that might have been missed. This will be a great time to try and handle your question posed as well as some others that might be placed in here.

You're original question was

What is the GG-intended "best practice" method for resolving the wall-climbing issue in the MiniPlatformer example (hopefully while still using the physics and tile engines of TGB)?

Would it be fair to re-word it to this (trying to keep this clear so when this can be migrated to some sort of FAQ or Knowledge Base it will be much easier).

What is the GG-intended "best practice" method for resolving the wall-climbing issue and the wall/ceiling sticking issues in the MiniPlatformer example (hopefully while still using the physics and tile engines of TGB)?

Feel free to re-state the question if that isn't the question you are looking at me approaching.