Why collision system makes me nervous
by M. Ugur Karakaplan · in Torque Game Builder · 07/18/2007 (5:24 am) · 11 replies
I believe everybody who wants to create a "game" with TGB faces the following problem; some are not aware at all, some ignore the fact, and some try to solve but can't find a way.
Well, if you create an object with a very basic collision polygon and set receive collision 'true', others 'false'. And create a player with send collision, and collision callback 'true' others 'false'. When keyboard keys are pressed player's linear velocity is set to a number. In onCollision callback of player, the linear velocity of the player is set to 0.
Now when you play this extremely simple game, what you would expect is that when player hits the object, it stops at the contact point. BUT NO! Sometimes your player will stop before a contact happens, and sometimes player will get in the polygon of object and get stuck there. You don't believe me? Go try it. For your very own game, if you use collision polygons, turn on your collision bounds in your debug rendering with writing %this.setdebugon(5) in your scene's onlevelloaded callback (by the way, if you go select it from the debug rendering tab in the right menu, it will only work in the scene view and it will not work in the game, it wasn't this way in 1.1.3, what kind of improvement is this?). Now play your game and see what happens.
TGB has no command for "if place_free then move", or "move_to_contact if there is collision" which could easily fix the problem. I really can't think of a solution with current code basket of TGB. This makes it impossible (yes, impossible) to make a well working platform game in TGB. Show me one if there is.
"There is something fundamentally wrong with the collision system of TGB". And that is why collision system makes me nervous.
Well, if you create an object with a very basic collision polygon and set receive collision 'true', others 'false'. And create a player with send collision, and collision callback 'true' others 'false'. When keyboard keys are pressed player's linear velocity is set to a number. In onCollision callback of player, the linear velocity of the player is set to 0.
Now when you play this extremely simple game, what you would expect is that when player hits the object, it stops at the contact point. BUT NO! Sometimes your player will stop before a contact happens, and sometimes player will get in the polygon of object and get stuck there. You don't believe me? Go try it. For your very own game, if you use collision polygons, turn on your collision bounds in your debug rendering with writing %this.setdebugon(5) in your scene's onlevelloaded callback (by the way, if you go select it from the debug rendering tab in the right menu, it will only work in the scene view and it will not work in the game, it wasn't this way in 1.1.3, what kind of improvement is this?). Now play your game and see what happens.
TGB has no command for "if place_free then move", or "move_to_contact if there is collision" which could easily fix the problem. I really can't think of a solution with current code basket of TGB. This makes it impossible (yes, impossible) to make a well working platform game in TGB. Show me one if there is.
"There is something fundamentally wrong with the collision system of TGB". And that is why collision system makes me nervous.
About the author
#2
07/18/2007 (10:59 am)
Well the solution is in exactly what you said. When you collide, move the object to the contact of the collision. The onCollision callback has a parameter for the collision point, so all you have to do is set the object's position to that minus the min/max value of your collision polygon. I use a simple "for" loop in the onLevelLoaded function to find the min/max values of the collision poly.
#3
07/18/2007 (8:34 pm)
Yep, you can work around it easily with oncollision callback.
#4
Extremely basic things are not covered in TGB yet. Why isn't there a decent collision system yet, or if there is an obvious problem with it, why isn't there a function to move stuff to contact point, or a function controlling if the next place is free of collision? These are very fundamental stuff that almost every game needs them. But everybody has to work around. "Don't be lazy... Work around... A game can't be done without working around and finding alternative solutions". How about finding an alternative to TGB then?
And the documentation... What a headache... What a chaos... I will give rewards to those who can find something about level system, resetting, speed, $timescale or other basic stuff by using that "search" box at the top right. That box doesn't work at all for God's sake! Can you find explanations for the functions, or usage in that documentation?
I feel like a masochist while using TGB. I think I will wait till TGB 5.0 if it can go that far.
@Benjamin, I have nothing against you or your wordings. I know that you are just a good member who try to help people, and I really appreciate that. I am just p!ssed off with TGB, and that's it.
07/19/2007 (9:19 am)
The thing with the TGB is that it is always working around something. People keep advising me to work around. Why? Is everything in TGB problematic that, instead of concentrating on what you really want to do, you have to waste your time working around the things? Basic stuff has to be there... Otherwise what's the meaning of using a builder or an engine? I can go use C++ and work around everything.Extremely basic things are not covered in TGB yet. Why isn't there a decent collision system yet, or if there is an obvious problem with it, why isn't there a function to move stuff to contact point, or a function controlling if the next place is free of collision? These are very fundamental stuff that almost every game needs them. But everybody has to work around. "Don't be lazy... Work around... A game can't be done without working around and finding alternative solutions". How about finding an alternative to TGB then?
And the documentation... What a headache... What a chaos... I will give rewards to those who can find something about level system, resetting, speed, $timescale or other basic stuff by using that "search" box at the top right. That box doesn't work at all for God's sake! Can you find explanations for the functions, or usage in that documentation?
I feel like a masochist while using TGB. I think I will wait till TGB 5.0 if it can go that far.
@Benjamin, I have nothing against you or your wordings. I know that you are just a good member who try to help people, and I really appreciate that. I am just p!ssed off with TGB, and that's it.
#5
You get the collision point information on every single ::onCollision callback. You have direct access to the object and can move it anywhere you want in response to an onCollision event.
Look up castCollision.
TGB already has both of those.
I would suggest it's more a situation where you should learn how to utilize what's already there, and realize that a genre agnostic game engine is going to in some cases make base assumptions that aren't appropriate for every possible scenario you (generic you) come up with. If you want to label that "work around", or label that "learn to effectively use the underlying systems", either way, making quality games with a flexible but agnostic game engine isn't something that's trivial.
Certainly a valid option, go for it :)
07/19/2007 (9:27 am)
Trying not to be disrespectful, but I'll address your points:Quote:
Extremely basic things are not covered in TGB yet. Why isn't there a decent collision system yet, or if there is an obvious problem with it, why isn't there a function to move stuff to contact point,
You get the collision point information on every single ::onCollision callback. You have direct access to the object and can move it anywhere you want in response to an onCollision event.
Quote:
or a function controlling if the next place is free of collision?
Look up castCollision.
Quote:
These are very fundamental stuff that almost every game needs them.
TGB already has both of those.
Quote:
But everybody has to work around. "Don't be lazy... Work around... A game can't be done without working around and finding alternative solutions".
I would suggest it's more a situation where you should learn how to utilize what's already there, and realize that a genre agnostic game engine is going to in some cases make base assumptions that aren't appropriate for every possible scenario you (generic you) come up with. If you want to label that "work around", or label that "learn to effectively use the underlying systems", either way, making quality games with a flexible but agnostic game engine isn't something that's trivial.
Quote:
How about finding an alternative to TGB then?
Certainly a valid option, go for it :)
#6
There's no offense, I do understand your point ^^'
These days I work around a looot of things in TGB (data management, sound management, saving config and option management, camera management, etc.), if you wan't things to go really as you like, you'll have to do a lot of these things (or wait for starter packs targeted toward specifics genre (unlike TGB which is for all type of game)).
This is simply the way TGB is (for now) : an excellent scripting language with an excellent level builder with an excellent rendering engine, and some good built in features.
Still, I agree that TGB is not a "maker" like GM or RM, but unlike these, in TGB you can easily tweaks things if you want them different. It give way more liberty to the user to do what he wants in the end. The bad side is that its features are really general, not really well made for any particular genre out of the box. Knowing that, there's indeed a lot of basic things that needs you to work on.
Personally, the only thing that really anger me, are bugs. Unstoppable bugs, like the one I encounter, are things that would make me want to find an alternative. But as long as they get addressed I have no way to complain.
And, about the documentation : keep the 1.1.3 documentation, in many aspects it is still better (the 1.1.3 TGB Reference is waaaayyy better than the actual 1.5.0). Though, I agree there's still too many things undocumented. It really need more work.
lot of edit everywhere ^^'
07/19/2007 (7:37 pm)
@Ugur KarakaplanThere's no offense, I do understand your point ^^'
These days I work around a looot of things in TGB (data management, sound management, saving config and option management, camera management, etc.), if you wan't things to go really as you like, you'll have to do a lot of these things (or wait for starter packs targeted toward specifics genre (unlike TGB which is for all type of game)).
This is simply the way TGB is (for now) : an excellent scripting language with an excellent level builder with an excellent rendering engine, and some good built in features.
Still, I agree that TGB is not a "maker" like GM or RM, but unlike these, in TGB you can easily tweaks things if you want them different. It give way more liberty to the user to do what he wants in the end. The bad side is that its features are really general, not really well made for any particular genre out of the box. Knowing that, there's indeed a lot of basic things that needs you to work on.
Personally, the only thing that really anger me, are bugs. Unstoppable bugs, like the one I encounter, are things that would make me want to find an alternative. But as long as they get addressed I have no way to complain.
And, about the documentation : keep the 1.1.3 documentation, in many aspects it is still better (the 1.1.3 TGB Reference is waaaayyy better than the actual 1.5.0). Though, I agree there's still too many things undocumented. It really need more work.
lot of edit everywhere ^^'
#7
I think not being disrespectful should not be an act of grace but a necessity for an employee. When you write it this way, it looks as if I was very disrespectful and you are threatening me that you can become harsh if this goes further.
What I say is very clear to many users -see Benjamin's post. When there are problems with what you produce and sell, it is users' duty to report or complain to have improvements in the product. You can't expect us to be silent. And I don't think the language of that message was strong. It just reflects the degree of annoyance I have. And it is very natural.
07/20/2007 (7:54 am)
Quote:Trying not to be disrespectful, but I'll address your points:
I think not being disrespectful should not be an act of grace but a necessity for an employee. When you write it this way, it looks as if I was very disrespectful and you are threatening me that you can become harsh if this goes further.
What I say is very clear to many users -see Benjamin's post. When there are problems with what you produce and sell, it is users' duty to report or complain to have improvements in the product. You can't expect us to be silent. And I don't think the language of that message was strong. It just reflects the degree of annoyance I have. And it is very natural.
Quote: TGB already has both of those.So do you see what I mean? If it was well documented, or if there were really "tons of tutorials" as mentioned in the web site, we would not be wasting our times discussing it here. TGB may be genre agnostic, however, if you know that a significant percent of the users of TGB wants to make a platform game (come on, it is one of the main game genres, no one could deny it), and if you very well know that "Collision have us running into walls" as this is the header of this forum, why do you torture people? There is no documentation about this issue, no tutorial, and no help or no code when you search it in the forums (by the way the search engine of this web site is far worse than that of documentation. It gives you totally irrelevant and inaccessible results. The latter doesn't give a result at all which saves your time at least.)
Quote: I would suggest it's more a situation where you should learn how to utilize what's already thereI know I should learn but in order to learn something there should be something to read, or follow or something. How do you expect from people to make a decent game following the fish tutorial? Or find information from a disorganized, unsearchable documentation? I really sincerely want to learn, but how Stephen how? Show me a stable source of information that will carry people to the level of starting a game of any genre with TGB. These forums? Or the books which are not on TGB? The documentation? "Tons" of tutorials?
Quote:Certainly a valid option, go for it :)I think if you really trusted in TGB, you would not say this as your being an employee. I do not say that TGB is the worst builder. Conversely, and to your surprise, I do believe that it is flexible (which is an advantage) and very promising. However, when an employee comes with discouraging wordings, I lose the idea. I don't want you to compare TGB with other softwares and present the advantages of TGB. What I think is that an employee should be ready to admit the current deficiencies and work to improve and overcome the problems to make the product more attractive to use. This is the virtue.
#8
Each of the points you brought up has been covered in multiple areas (forums, TDN tutorials), and your general tone was one of frustration and complaints that were disrespectful themselves towards the product (you said yourself in the post you were "p!ssed", which is not normally a way to get useful information from a user community), and at that point, given your issues (which again, as I describe, are explained in multiple areas that are directly available to you), using a different product may be a good option for you, so I agreed with the statement you made.
As Benjamin noted, TGB is not a game maker tool, it's a game engine. It is both more powerful, and more complex than other tools. It certainly has issues (and every valid report of bugs, concerns, or feedback is taken very seriously), and those issues are continuously addressed.
Regarding your points themselves: if you had simply asked the questions instead of posting a complaint post, you would have had the exact answers you needed extremely rapidly. If you had posted a description of what you were trying to accomplish, you may even have had people give you demonstration code to do exactly (or close to) what you want.
Instead, you elected to complain instead of ask and possibly suggest, and in that light it's not a case where it makes sense to try to "convince" you, but instead offer you options that would make you more capable of meeting what appear to be your needs.
07/20/2007 (8:34 am)
Thanks for your opinions. Not every product is for every user, and if you are struggling with TGB for whatever reason, and feel that your time is not being used well, then the best recommendation you can receive is to use a different product to meet your goals.Each of the points you brought up has been covered in multiple areas (forums, TDN tutorials), and your general tone was one of frustration and complaints that were disrespectful themselves towards the product (you said yourself in the post you were "p!ssed", which is not normally a way to get useful information from a user community), and at that point, given your issues (which again, as I describe, are explained in multiple areas that are directly available to you), using a different product may be a good option for you, so I agreed with the statement you made.
As Benjamin noted, TGB is not a game maker tool, it's a game engine. It is both more powerful, and more complex than other tools. It certainly has issues (and every valid report of bugs, concerns, or feedback is taken very seriously), and those issues are continuously addressed.
Regarding your points themselves: if you had simply asked the questions instead of posting a complaint post, you would have had the exact answers you needed extremely rapidly. If you had posted a description of what you were trying to accomplish, you may even have had people give you demonstration code to do exactly (or close to) what you want.
Instead, you elected to complain instead of ask and possibly suggest, and in that light it's not a case where it makes sense to try to "convince" you, but instead offer you options that would make you more capable of meeting what appear to be your needs.
#9
Ok. Let's see. With all my respect and serenity I am simply asking my question: I checked the contacts points which is returned by oncollision callback. In the echo, I saw that every collision of my isometric objects returns two contact points. I decided to create a target symbol on the contact points to verify that the points are the points I want. In the following first image, echo shows that there are two distinct contact points, and created target images verify that too.
However, in the second image, where the player gets into the wall, echo returns two points which are the same and target images are created on that returned contact location which is totally irrelevant to the collision because it is the origin of the player.
And in this latter situation, since the player gets into the wall, echo keeps returning the same numbers again and again till crush. The walls are the same. There is no other source of differentiation. And the following is the part of the code for this work. What would be the reason for this result and what can be done? I can send the full code and the project if you do not believe me.
07/20/2007 (11:56 am)
Quote:if you had simply asked the questions instead of posting a complaint post, you would have had the exact answers you needed extremely rapidly.
Ok. Let's see. With all my respect and serenity I am simply asking my question: I checked the contacts points which is returned by oncollision callback. In the echo, I saw that every collision of my isometric objects returns two contact points. I decided to create a target symbol on the contact points to verify that the points are the points I want. In the following first image, echo shows that there are two distinct contact points, and created target images verify that too.
*echo* position:47.359993 -40.191986 collision:64.000000 -31.999996 47.488003 -40.255993 collision count:2
However, in the second image, where the player gets into the wall, echo returns two points which are the same and target images are created on that returned contact location which is totally irrelevant to the collision because it is the origin of the player.
*echo* position:-262.912201 -75.520004 collision:-262.912201 -75.520004 -262.912201 -75.520004 collision count:2
And in this latter situation, since the player gets into the wall, echo keeps returning the same numbers again and again till crush. The walls are the same. There is no other source of differentiation. And the following is the part of the code for this work. What would be the reason for this result and what can be done? I can send the full code and the project if you do not believe me.
function target::onadd(%this)
{
%this.setposition(%this.xi, %this.yi);
%this.setimagemap(hedefimagemap);
%this.setsize(31,31);
%this.setlayer(0);
}
function player::onCollision(%srcObj, %dstObj, %srcRef, %dstRef, %time, %normal, %contactCount, %contacts)
{
echo("position:" @ $plyr.getposition());
echo("collision:" @ %contacts);
echo("collision count:" @ %contactcount);
%srcobj.a = getWord(%contacts,0);
%srcobj.b = getWord(%contacts,1);
%srcobj.c = getWord(%contacts,2);
%srcobj.d = getWord(%contacts,3);
%srcobj.target = new t2dStaticSprite()
{
scenegraph = %srcobj.scenegraph;
class = target;
name = trg;
xi = %srcobj.a;
yi = %srcobj.b;
};
%srcobj.target = new t2dStaticSprite()
{
scenegraph = %srcobj.scenegraph;
class = target;
name = trg;
xi = %srcobj.c;
yi = %srcobj.d;
};
if(%dstObj.blkheight>$plyr.height && %dstObj.class $= "trigger")
{
%srcobj.setLinearVelocity(0,0);
$img.setlinearvelocity(0,0);
}
}
#10
07/20/2007 (11:58 am)
I do believe you, and as I said in my first response, there is a subtle bug that wasn't reported in the new tick based physics system that is being assessed. We don't have an immediate answer yet, and I apologize for that.
#11
I hope it will be announced when this bug is debugged. Thank you.
07/20/2007 (12:03 pm)
Ok Stephen. Thank you for the extremely rapid response. I really appreciate that. So I believe, I have to wait for a solution to that bug, because it seems that the contact points returned by oncollision callback or castcollision function will not work in the existence of this bug.I hope it will be announced when this bug is debugged. Thank you.
Torque 3D Owner Stephen Zepp