2D Jumping Mechanic

Hi everyone! Thanks for reading first of all. Secondly, this is my first post, and I really look forward to getting involved in this amazing community of independent game developers!

Anyway, I'm developing a 2D top down action RPG and I am having trouble achieving a convincing jump animation. What I want to do is have the character jump and have it's Y position and scale (scale is no problem) appear to change during the jump in order to simulate it's z axis position changing.
Of course, merely changing the z position does not affect this in the top down orientation that game currently employs using Unity's 2D toolset. I don't want to change the absolute Y position as that will affect collisions on the ground level. I guess I'm asking, is it possible to cause the sprite to 'virtually' move up/render higher on the Y axis without changing its absolute Y position? Or, and this is more of a long shot I imagine, perhaps there a way to make z position render as it would in an isometric-type perspective?

I used the mechanic I describe in a version of the game I originally made in DarkBasic by adding the Z position to the Y in order to achieve the effect, but of course, I had to ensure my collision detection and rendering took this z position into account, which was actually easier to do than it appears to be in Unity, as the system I built was able to keep track of both absolute and virtual y positions for all entities.

I realize I could create a new animation for jumping but the complications that creates adjusting my sprite sheets, managing the colliders, and other prefab/animation spawning seems like a lot of extra work I could avoid if I could make this mechanic work smoothly.

 

So.... what are you asking exactly?

I'm not quite following when you say you want the scale and the Y position to change to visualize the jump. If it is a top down view 2D game Y position would represent movement such as north or south. The only way to represent movement in the Z plane in this 2D top down game is as you said to use scaling.

You can certainly track Z position if you like. But it might be simpler to just use the current scale to not only display the jump height increase but also hold the actual position. For example the main "depth" would correspond to z scale of 1. The height of the jump might be 1.4 or 1.5 whatever. If the player drops down to a lower level going underground the z scale might be 0.7 or so.

If you create corresponding layers such as Z10, Z15 and Z7 or whatever you want to name them you could then handle collisions only with objects corresponding to the player's current z (scaling value).

I may have misunderstood and completely missed the point. Based on what I got from your post the above is what popped in my head.

 

Excuse me for the confusion, it's not top down. The angle of the character sprites and terrain sprite give the impression of an almost 'isometric' type view angle. So, consider how a sprite would look jumping up from the ground plane from that perspective. Jumping would move the sprite up and down the y axis. If the character casts a shadow at its feet, jumping would move the character farther up the y axis away from the stationary shadow, and back down to meet it again. Turtles in Time gives a good sense of the mechanic I want. i.e. The sprite is rendered at (x , y + jumpHeight) where (x,y) is the gameObject's position.

This is not my game, but visually, the maps and character rendering are about in line with what I'm trying to achieve as for perspective.

Id say try to imagine Turtles in Time jumping from this angle and you will see what I mean.

Basically, is there a way to I move the sprite rendering up on the y axis relative to the camera without actually changing the gameObject's position? Like, can I implement a rendering offset on the y axis during the jump sequence, just for the sprite renderer?

 

Oh yeah I see now. And actually I am implementing a rendering offset in my 2D platform game. It is straightforward. I just use a Vector2D v2Position variable to hold the position of my sprites. I do that for any game project. Each update the v2Positions are modified based on current velocities. Then I copy v2Position to v2PixelPosition and align v2PixelPosition x and y coords to pixel values. Then I add any vertical rendering offsets needed to the y position of v2PixelPosition. After that the gameObject's transform.position is set to v2PixelPosition.

I roll my own physics. If you are using the canned physics you will lose this kind of control. At least as far as I know. There is probably some way to workaround it. If you do not use the canned physics then you can do anything you need just using code.

 

Thanks for the detailed response. I suppose I will have to take a similar route as well. I have been using the canned physics and have been thinking about how I may need to build my own way to handle everything for problems such as this. I'm gonna consider this answered Thanks again!

However, if there is anyone with other ideas out there that are more baked in, I'd be open to hear them!

 

Maybe include your character art as a child of your physics gameobject and animate its Y offset independently of what the parent physics collider is up to?

 

Thanks for the advice brendan.vance! I just logged on to update my solution and I did just that. I have a playerPlatform object as the parent to my characters and update their location to match their respective parent objects. The child gets a jumpHeight added to their position, which defaults to zero unless jumping, and when jumping this value tweens between 0 and a maxJumpHeight. Works great, I just had to attach my playerControl script to the parent and adjust it to seek the animator of it's child to update animations.

P.s. When I did start controlling the child's animator through the parent, even though I have the parent find the Animator component in Awake() by first getting its child's name, the editor game me the error that it couldn't find an Animator component in the parent object (clearly strange). I had to fix this by manually assigning the variable that stores the child's name in the inspector window. The wierd thing is that I have two player objects using this parent-child control mechanic [the player can switch between party members on the fly, with the uncontrolled party member defaulting to its AI routine (which is, for now, part of playerControl); each has the same playerControl script attached] and only one was giving me the error and refusing to store the name of the child for reference in the parent's playerControl script. But, that's a whole 'nother can of worms tho, perhaps a unity bug...?