Platform tutorials

#21 @Vern, in response to your first post at 00:42, I went through the Mini Platformer Tutorial and when I finished everything worked the way I expected it too -- with the exception of the wall climbing issue which you seem to be found as well, but that's an issue with the actual tutorial (only in that it does not take that into account, but the skills to fix it are given in the tutorial), this issue has also been raised in quite a few forums already as well -- and AzraelK has already provided two solutions in this thread alone.

@Vern, in response to your post at 00:50, the 'walking through tile' scenerio is something you can actually do if you read the other tutorials and piece everything together, as Mathhew pointed out that's the intention of these tutorials.

General theory for 'walk through tiles but jump and land on them' scenerio:

Set CustomData for ground tiles to 'ground', set CustomData for tiles you can walk through but land on when jumping and possibly jump down from (like in contra) to 'platform'

In your castCollision check, take the return value (refer to TGB Reference) and retrieve the object from the list, validate the object is a tile and then check it's CustomData -- if it's a platform, treat it as 'ground' and land on it. Ignore 'platform' tiles in all other collision validations.

This would allow you to simply walk or jump through a 'platform' tile, but when landing, it is treated as ground and you land 'on it' -- you could then have a 'jump + down' style key sequence like in contra that caused the player to fall through the tile, this code would simply place the player back in the 'air' (without reducing the Y position [ie; not making the player go up]) and cause the 'in air' validations to be taken into account once again where the 'ground' tile below would be the next collision returned from castCollision ...

As for the 'almost made it, but not far enough' scenerio, that can be resolved by validating the points in the collision -- was it the players head or feet that caused the collision? was the player above or below the tile when the collision occured?

Keep in mind, that's the general theory on how to do it -- not the overall 'this is how it's done' ...

Not trying to rant, just trying to provide some real quick 'info' ... whether it be useful or not :)

#22 Thanks David. It's useful to know that the other problems I'm having might be the result of me missing something or typing something in wrong in the tutorial. I'll give it another look.

Any idea why my guy is falling 1/3 of the way through a tile before he stops? When he walks, he walks through the top 1/3 portion of the tile, as if the ground is lower than it really is.

#23

Quote:Any idea why my guy is falling 1/3 of the way through a tile before he stops? When he walks, he walks through the top 1/3 portion of the tile, as if the ground is lower than it really is.

@Vern - I would check check collision polygon for your player. Did you set a custom collision poly?

#24 No, there is no collision poly. I did try adding one once, and when I did, everything went *haywire*. When he walks left/right, he bounces up and down violently, as if walking on a rough surface shaped like this (where "o" is the guy):

o
^^^^^^^^^^^^^

And he'll end up falling right through tiles when jumping in corners.

So I deleted him and put a fresh guy in, and reset the collision/physics options as per the tutorial's specs. (Deleting a sprite seems to be the only way of removing a collision poly from within the editor, short of messing with the datablock files manually.)

So no idea why that happens, and also no idea why he falls 1/3 of the way through the tile otherwise (it's closer to 1/4 actually). I double-checked everything vs. the tutorial last night, and it seems to check out. I don't get it.

-Vern

#25 BTW, here is the code for player.cs. Thought I'd post it, just to be sure.

In the editor, the tiles have their Collision checkbox checked, and the hero sprite has Send Collision, Receive Collision, and Send Physics checked in the Collision panel, and has Constant Force Y set to 100 in the Physics panel, along with Gravitic checkbox checked, and Force Scale set to 4.000.

My TileLayer object is also set up as per the tutorial's instructions.

function playerClass::onLevelLoaded(%this, %scenegraph)
{
	$pGuy = %this;
      
	moveMap.bindCmd(keyboard, "left", "playerLeft();", "playerLeftStop();");
	moveMap.bindCmd(keyboard, "right", "playerRight();", "playerRightStop();");
	moveMap.bindCmd(keyboard, "space", "playerJump();", "");
	
		// Tell physics engine to be more careful than normal!
	$pGuy.setCollisionMaxIterations(2);
	
		// Mount camera to player (adds scrolling to the game!)
		// "0 0" are the x, y offsets
		// Use lower values for %force to make it lag behind the player more
	%force = 20;	// 20
	sceneWindow2D.mount($pGuy, "0 0", %force, true);
}


function playerLeft()
{
	$pGuy.moveLeft = true;
	$pGuy.setFlip(true, false);
}

function playerLeftStop()
{
	$pGuy.moveLeft = false;
}

function playerRight()
{
	$pGuy.moveRight = true;
	$pGuy.setFlip(false, false);
}

function playerRightStop()
{
	$pGuy.moveRight = false;
}

	// This version makes sure there is ground beneath the player before allowing him to jump
function playerJump()
{
	%yVelocity = $pGuy.getLinearVelocityY();
	%xVelocity = $pGuy.getLinearVelocityX();
	
	
	$pGuy.setLinearVelocityY(100);
	$pGuy.setLinearVelocityX(0);

  	%collision = $pGuy.castCollision(0.005);	// Is ground under him?
    
	if(!(%collision $= ""))
	{
		$pGuy.setLinearVelocityY(-265);
	}
	else
	{
		$pGuy.setLinearVelocityY(%yVelocity);
	}

	$pGuy.setLinearVelocityX(%xVelocity);
}




function playerClass::setCurrentAnimation(%this, %yVelocity)
{
	if(%yVelocity < 0 )
    {
    	 %this.playAnimation(playerJumpUp);
    }
	else if(%yVelocity > 0 )
    {
    	 %this.playAnimation(playerJumpDown);
    }
    else
    {
		if(%this.moveLeft || %this.moveRight)
		{
			if(%this.getAnimationName() $= "playerRun")
			{
				if(%this.getIsAnimationFinished())
				{
					%this.playAnimation(playerRun);
				}
			}
			else
			{
				%this.playAnimation(playerRun);
			}
		}   
		else
		{
			%this.playAnimation(playerStand);
		}
    }
}


	// NOTE: This function is called CONSTANTLY -- every frame! So don't put too much in here!
function t2dSceneGraph::onUpdateScene()
{
	$pGuy.updateMovement();
}

function playerClass::updateMovement(%this)
{ 
	if (%this.moveLeft)
	{
		%this.setLinearVelocityX(-60);
	}
    
	if (%this.moveRight)
	{
		%this.setLinearVelocityX(60);
	}
    
	if (!%this.moveLeft && !%this.moveRight)
	{
		%this.setLinearVelocityX(0);
	}
	

		//
		// Fix for Torque's physics engine -- avoid friction and things we don't want
		//
	
	%yVelocity = $pGuy.getLinearVelocityY();
	
		// Update animation!
	$pGuy.setCurrentAnimation(%yVelocity);

                
    $pGuy.setLinearVelocityY(100);
  
    %collision = $pGuy.castCollision(0.005);	// Are we colliding with something directly below us? (check 0.005 sec in the future)
    $pGuy.setLinearVelocityY(%yVelocity );
    
    if(%collision $= "")
    {
        $pGuy.setConstantForceY(100);	// Nothing below us... Turn on gravity!
    }
    else
    {
        $pGuy.setConstantForceY(0);		// Something below us.. turn gravity off!
    }
}

*Edit: Oops, took out some code that I had added to test some things. It's back to normal now, but still has the 1/4 tile problem.

#26 Okay, I just rebuild the Mini Platform tutorial on Windows, and it doesn't have the problem described above in my other posts. (Those were on a Mac.) Seems the Mac version of Torque has some bugs in the tille stuff. Anyone else here a Mac user? Can anyone else confirm this, by doing the Mini Platform tutorial on a Mac?

#27 I'm sitting on a Mac and haven't experienced your problems...
It seems to work as expected (exept for the bugs in the scripts i.e slow moving up and down along walls)

#28 Thanks for the reply Andre. Based on your response, I tried recreating the whole thing on the Mac. I used the same script files, the same graphics, etc. All I did really was recreate the project in TGB. And now it works. Weird.

#29 @ David Higgins -- Hope you're still reading this thread, because I have a few questions about something you posted 3 days ago.

Quote:
General theory for 'walk through tiles but jump and land on them' scenerio:

Set CustomData for ground tiles to 'ground', set CustomData for tiles you can walk through but land on when jumping and possibly jump down from (like in contra) to 'platform'

In your castCollision check, take the return value (refer to TGB Reference) and retrieve the object from the list, validate the object is a tile and then check it's CustomData -- if it's a platform, treat it as 'ground' and land on it. Ignore 'platform' tiles in all other collision validations.

This would allow you to simply walk or jump through a 'platform' tile, but when landing, it is treated as ground and you land 'on it' -- you could then have a 'jump + down' style key sequence like in contra that caused the player to fall through the tile, this code would simply place the player back in the 'air' (without reducing the Y position [ie; not making the player go up]) and cause the 'in air' validations to be taken into account once again where the 'ground' tile below would be the next collision returned from castCollision ...

Questions:

1) You mention just "ignore" a collision when a tile is a platform, and you're not falling through it. How do you just ignore it? The way the Mini Platform Tutorial is set up, with the sprite set to do CLAMP whenever a collision is detected, collisions happen *automatically*.

The only way I can see around this is to turn off the send physics / receive physics options, and instead put in a callback that handles collisions myself. I'd then have to do all the repositioning calculations by hand, computing a tile's rectangle, the sprite's rectangle, and offsetting the sprite by the appropriate amount anytime it moves inside a tile that's "solid", so that the sprite is moved just outside the tile. Which is basically the doing it "by hand" approach I suggested might be necessary in my posts a while ago, vs. the "Let Torque do it for you" approach taken by the Mini Platformer tutorial.

So are you recommending the "do it by hand" approach after all, or is there a way to make simple modifications to the Mini Platformer Tutorial to add platform type tiles you can walk through, but not fall through?

2) You mentioned calling castCollision(), and retrieving the object from the list, to get access to the tile's CustomData. That would be great, but I don't think it's possible. CastCollision returns an object all right, but it's a tileLayer object -- not an individual tile. To get access to the tile, you need to know its row and column -- information which IS passed to an onCollision() callback, but which is NOT returned in castCollision's list. (CastCollision does return a *location* in world coordinates where the collision occurred, but I'd have to convert this to try to convert this to a tileRow and tileCol and hope that works.) I don't think it's possible to get the custom data from a tile that was collided with by using castCollision. Am I wrong?

The point is, the Mini Platformer Tutorial works okay for very simple situations, but for anything more complex, you basically have to tear everything out an use an entirely different approach that turns off Torque's physics, and computes everything manually for sprite-tile collisions. I'd still love to hear that this isn't so, but so far I've found no way to do what I want using the methods in Mini Platformer Tutorial. The "by hand" approach seems to be the only route to go.

My feeling is that the mini platformer tutorial does not provide an approach that is a good foundation to build upon for a real game. However, I would *love* to be proved wrong.

#30 For those of you experiencing the bug with the player slideing on platform tiles when he encounters them in ther air here is a fix. I'm going to update the minitutorial to include it since it seems to be an issue for people.

function playerClass::updateMovement(%this)
{
     %yVel = $pGuy.getLinearVelocityY();   // Move these two lines from later in the function..to the beginning
     $pGuy.setLinearVelocityY(0);
	 
     if(%this.moveLeft)
     {
            %this.setLinearVelocityX(-65);            
     }
    
     if(%this.moveRight)
     {
            %this.setLinearVelocityX(65);
     }
    
     if(!%this.moveLeft && !%this.moveRight)
     {
            %this.setLinearVelocityX(0);
     }
     
     %collision = $pGuy.castCollision(0.005); //add this collision check after setting the LinearVelocityX
    if(%collision !$= "" )
    {
    	%this.setLinearVelocityX(0);
    }
   

    $pGuy.setCurrentAnimation(%yVel);
                
    $pGuy.setLinearVelocityY(100);
  
    %collision = $pGuy.castCollision(0.005);
    $pGuy.setLinearVelocityY(%yVel);
    
    if(%collision $= "")
    {
        $pGuy.setConstantForceY(100);
    }
    else
    {
        $pGuy.setConstantForceY(0);
    }   
}

This will prevent the player from sticking to the sides of tiles.

#31 I've also updated the miniPlatformerTutorial section 5.2 player movement to include this fix.

I never intended for the miniPlatformerTutorial to be a framework to build a fully featured platformer from. A very simple platformer perhaps but even simplistic platformers like super mario have very subtle movement code that goes beyond simple gravity and impulse forces. Even on the original Nintendo version, Mario would speed up and slow down, depending on how long you held the jump button Mario would jump different heights. There are other similarities in how the in-air control of Mario works. It's actually a fairly challenging thing to clone exactly and mimic that Mario like gameplay feel.

I think the current tutorial might be enough for a more action oriented gameplay style, something like a double dragon side scroller where most of the interaction is in kicking and punching enemies as opposed to making skilled jumps.

The purpose of the tutorial was just to show how quickly you could get something basic up and running with TGB and give you a starting point from which to work. If you want Mario like gameplay then you could slowly start to remove the physics based movement and replace it with your own custom code. Same with animations etc. Most of the code in the tutorial has been simplified to make the concepts of programing and platformer mechanics easy to understand and accessible. For a larger more complex project you would want to take those concepts and build them out to something more robust.

I'm actually very please that so many people have taken the time to go all the way though the tutorial and set up their own projects. I may get time to create some mini sequels to the tutorial for adding enemies and some of the other basic mechanics of a platformer. Though it seems like there are already members of the community volunteering to do this.

#32

Quote:I never intended for the miniPlatformerTutorial to be a framework to build a fully featured platformer from. A very simple platformer perhaps but even simplistic platformers like super mario have very subtle movement code that goes beyond simple gravity and impulse forces. Even on the original Nintendo version, Mario would speed up and slow down, depending on how long you held the jump button Mario would jump different heights. There are other similarities in how the in-air control of Mario works. It's actually a fairly challenging thing to clone exactly and mimic that Mario like gameplay feel.

I don't know about others, but for me, it would be quite simple to change things like jumping behavior, movement acceleration, and whatnot. What's NOT easy is determining how we're supposed to handle the really tricky stuff, like platforms you can walk/jump up through, but not fall through, from within Torque's framework. I think the purpose of tutorials should be to explain the really trick stuff that we'd find next to impossible to figure out ourselves. That is, how to do this the "Torque" way.

I could of course always write my own code that installs an onTimer callback, and this callback moves the player each "frame", checks for collisions, and handles them appropriately, but now I'm handling everything myself -- rather than letting Torque handle the physics, collisions, etc. So it's always *possible* to do it the non-Torque way, but to try to figure out how to do certain things in Torque is sometimes very difficult, as the platform issue has shown.

Quote:The purpose of the tutorial was just to show how quickly you could get something basic up and running with TGB and give you a starting point from which to work.

Well, I want to write real games, and my first question when looking at something is not how quick/easy it is, but "is this a good foundation for a real game?" I think a lot of people on these forums are using the Mini Platformer Tutorial in the same way -- they're trying to use it as a foundation for a real game.

Currently, using the methods in the Mini Platformer Tutorial, there is *no* way to get both tiles and sprites that behave as "platforms" you can walk through, but not fall through. (Tile-only platforms yes, by using triggers, but this won't work for moving platforms made from sprites.) So the concept of "this can be modified / fleshed out for bigger games" fails. It *can't* be modified/fleshed out. A different approach needs to be taken from the ground up.

And that's where I'm at right now. I'd rather not use an approach unless I'm confident it *can* be modified to handle everything my game needs to handle. Otherwise I'm wasting time with it, because I'll have to rip it out and replace it with an entirely different approach later.

BTW, I hope I'm not coming across the wrong way. I really appreciate the tutorial, and all the work you guys are putting into Torque. I'm just trying to make the point that many people are looking to the tutorial that forms the basis for a real game -- such as a game that has platforms -- and if the tutorial uses an approach that can't be adapted to allow for things like platforms, then it's not an approach I want to build my game on.

#33 @Vern: good post, and in some ways I agree with you, but in many ways I think that you may want to re-think your design.

Torque's physics system is designed for specific things, and is very powerful for those things, but it's not designed to handle every single possible game concept out there.

This isn't just Torque however, it's the nature of game design when applied to engines and tools. For example, Torque's physics system is put together to do the best job a generic system can for simulating "real" 2D physics---but what platformer game out there used "real" physics?

Look at what you are asking for here specifically: you want objects in your game (sprites, tiles, doesn't matter) that are conditionally not even there--in certain cases, you can walk through them, but in certain other cases, you seem to want the physics system to automatically recognize that they should now collide.

Quite honestly, that's not a scenario the physics system was designed for, and trying to force it to do what you want (especially with just script) is like trying to scale a mountain wearing flip-flops--not really the best idea.

In another post, people were asking for a very specific capability as well--and truthfully, it's a capabilty that takes about 4 lines of (c++) code. That's why we provide the source code license--if you need to change something about how a system works, you can purchase a source code license, and handle it yourself quite easily (given some understanding of the systems involved).

Taking an even further step back, it's arguable that there are no real "physics" in a platformer that actually make sense from a normal systems perspective:

--you can jump many times your own height
--you can run up and down 45 degree slopes as if they were flat
--as you want, you can conditionally run through solid walls/floors/what have you
--many other specific circumstances

For the first TGB Boot Camp, I made a rather complex platformer style lab exercise, and yes, I was able to do everything I needed via script. I also turned off all TGB physics entirely, and dealt with the various conditional scenarios via script callbacks only (even down to horizontal and vertical basic movement, as well as "air time" movement), because it simply didn't make sense to try to apply impulse/velocity based physics design assumptions to a completely "non-realistic" physics scenario.

#34 First of all, I became a GG associate for some of the work I was doing promoting IGC, writing session summaries for the sessions etc. I'm not very experienced with Torque. The first time I tried TGB was version 1.1.1, I had no previous torque script experience or anything else. I think I downloaded TGB on a Wednesday, studied TDN and by Friday I had the project that would be come the miniPlatformerTutorial. I spend Saturday and Sunday writing the bulk of the tutorial.

For what you say about not being able to fall though tiles, it seems to me that TGB 1.1.1 collision system allows you to put objects in different groups within a layer and you can tell the player to only interact with specific groups and layers. In this way you could create a tile map as a layer on top of your platformer tilemap that would not interact with the player because it was in a different collision group from the platform tilemap layer.

Depending on the type of platformer you are looking to make, the miniPlatformerTutorial can be a good starting point for a game, but it doesn't give you all the answers. It exists to show you how much you can get done if you keep things simple and direct. The intention is to give you a taste of the potential to make a good platformer in TGB and inspire you to try. It seems a lot of people are trying (which I am very happy about) but they are also getting stuck. I think a few more tutorials might be necessary, but at some point the tutorials end and developers will need to fill in the blanks to figure out what needs to be done to get them to their final goal of a platformer.

#35 Dan,

Thanks for the reply. For some reason I had assumed the tutorials were written by the same people who wrote the engine, and knew it in and out, and therefore were recommending the "Torque" way of doing things. Sounds like you're instead a helpful person who has learned some Torque, and wrote a tutorial to try to help people get started (and therefore you don't know what the "best" way is necessary, but have found something that seems to work), so thanks for your contribution.

Stephen Zepp wrote:

Quote:Look at what you are asking for here specifically: you want objects in your game (sprites, tiles, doesn't matter) that are conditionally not even there--in certain cases, you can walk through them, but in certain other cases, you seem to want the physics system to automatically recognize that they should now collide.

Quite honestly, that's not a scenario the physics system was designed for, and trying to force it to do what you want (especially with just script) is like trying to scale a mountain wearing flip-flops--not really the best idea.

Yes, it's true you can't build the Torque engine in a way that *all* potential game needs are accounted for, but, given that 2D platformer games are such a common genre, and that "platform" tiles (that you can jump/walk through, but not fall through) are such a common staple of platform games -- in fact probably present in every single one of them -- wouldn't it make sense to have Torque include some functionality to support these natively, without requiring modifications to the C++ engine?

#36 @Vern, if GG wrote all the code for us ... it wouldn't make game dev so much fun ...

Also, as stated in my previous post, what I said was all theory, and was completely untested -- it was based on assumptions from what I'd read and learned over the past 4+ weeks of messing with the engine.

At the same time, I believe this particular line of "I want special tile functionality" chatter is best suited to wait until _after_ the special platformer framework is provided, as GG has already stated they intend to produce such an item ... we all just have to sit back and wait patiently ...

Perhaps your special tiles will be presented in this framework, and we'll all be enlightened at how easy it was for GG to code it ... and perhaps all pitch in and buy the TGB Dev Team pizza :)

#37 Haha, yeah, I'd be happy to buy them several pizzas if they came out with a framework that had this in it. :-)

@ Dan -- Just read some of your .plan. Interesting stuff! (About the "complexity barrier" and also the stuff about indie developers who jump on the "clone the latest casual success" bandwagon... You're exactly right about that.) I've seen Little Soldiers before, so it's interesting to make that connection. I tried emailing you, but the email in your profile doesn't work.

#38 Id buy them a whole pizza hut if the framework coming out soon :)

#39 I'll hold you to that! :P

#40 @Vern - Ahh yes! my profile was out of date. I've updated it to reflect my current information. Thanks.