Platformer physics messed up in Built version
by Andrew Sage · in Torque Game Builder · 11/11/2006 (7:08 pm) · 7 replies
I have been playing with a small platform game based on the TGB platform game example.
If the level is played from the editor or launched without the editor it works fine.
However if the game is built and the resulting executable played then it behaves differently. My player falls through tiles which it should collide against, the player will not move left or right and the jump sends the player flying up into the air.
I have tested this on both the Mac and Windows versions of TGB 1.1.1. and get the same results.
Encountering these inconsistencies between development and release versions for such a simple game has me worried about using TGB for a serious sized project.
If the level is played from the editor or launched without the editor it works fine.
However if the game is built and the resulting executable played then it behaves differently. My player falls through tiles which it should collide against, the player will not move left or right and the jump sends the player flying up into the air.
I have tested this on both the Mac and Windows versions of TGB 1.1.1. and get the same results.
Encountering these inconsistencies between development and release versions for such a simple game has me worried about using TGB for a serious sized project.
About the author
#2
My gut tells me however that you placed some global variable definitions (collision information specifically) in a place that is only executed when you run with the level builder, and if you move them to a more appropriate place you should be fine.
11/14/2006 (1:35 pm)
Quite honestly we don't have nearly enough details to know what is going on.My gut tells me however that you placed some global variable definitions (collision information specifically) in a place that is only executed when you run with the level builder, and if you move them to a more appropriate place you should be fine.
#3
11/14/2006 (8:26 pm)
Which platformer example are you referring to?
#4
Basically, when the level editor loads the level.t2d file for testing it makes a copy of all the values you set up in the editor version and applies them to the level version.
That is if I'm not off in my interpretation of the syntax.
This matters because you might be setting values in the code using the global name... even some checks could be done that way. If that name isn't copied, then the functions don't get applied.
Speaking of which... do you have any console output? Does the console still exist in the built versions?
11/14/2006 (9:13 pm)
I was looking over my level code and found the following for the player object:[b]new t2dAnimatedSprite(player) [/b]{
animationName = "PlayerStand";
canSaveDynamicFields = "1";
class = "playerClass";
Position = "-71.000 37.367";
size = "32.000 32.000";
...
};I could be totally off base here but I *think* that the first line actually tells the engine to make a copy of a pre-existing pGuy object. Perhaps you need to set up the pGuy in script on your levelLoaded function instead of relying on this.Basically, when the level editor loads the level.t2d file for testing it makes a copy of all the values you set up in the editor version and applies them to the level version.
That is if I'm not off in my interpretation of the syntax.
This matters because you might be setting values in the code using the global name... even some checks could be done that way. If that name isn't copied, then the functions don't get applied.
Speaking of which... do you have any console output? Does the console still exist in the built versions?
#5
Anyone know for certain which it is?
11/14/2006 (9:52 pm)
I think I'm probably wrong about the information being copied. It seems as though doing the "new t2dAnimatedSprite(player)" call sets the objects name to "player".Anyone know for certain which it is?
#6
11/15/2006 (5:01 pm)
Yes, it creates a new sprite object named player. If there are already some objects named player then you will just have one more with the same name. Nothing prevents you from having as many objects with the same name as you want.
#7
@Eric: I believe the $pGuy global in that example is set in the onLevelLoaded callback on the 'player' namespace, so the value of $pGuy would only be a valid object ID when the level is actually played, not the other way around. There is no pre-existing $pGuy object.
As for how serialization works in TGB, when you save your level TGB writes off what are basically templates for all objects to a level file. The templates store all the fields on the objects that aren't the default value. When you run/test the level TGB executes the level file and all the objects are created in a fresh scenegraph (all the objects in a level file are contained within one scenegraph object - the 'new' statement is right at the top). The optional argument in new statement's is the 'name' of the object.
11/16/2006 (3:17 am)
@Ben: That's true in that if you string-compare their 'name' fields they will evaluate equal, but only one object can be linked to a name at a given time. In other words, only one object will get any calls on the 'player' namespace. Offhand I'm 90% sure that the newest object gets the link, but don't quote me on that.@Eric: I believe the $pGuy global in that example is set in the onLevelLoaded callback on the 'player' namespace, so the value of $pGuy would only be a valid object ID when the level is actually played, not the other way around. There is no pre-existing $pGuy object.
As for how serialization works in TGB, when you save your level TGB writes off what are basically templates for all objects to a level file. The templates store all the fields on the objects that aren't the default value. When you run/test the level TGB executes the level file and all the objects are created in a fresh scenegraph (all the objects in a level file are contained within one scenegraph object - the 'new' statement is right at the top). The optional argument in new statement's is the 'name' of the object.
Torque Owner Andrew Sage