I am thinking, that even though it is a prototype, we should build in the animation. Mainly, this is because I don’t want to do it later when we replace the graphics. So far we have the player attacking without any animation, and I am about to implement player jumping, again without the graphics. So, its a prototype, so we don’t want to waste time ( maybe looking for graphics, or building new ones ) , and we don’t want to invest into it ( buying premium assets ). SO, i am going to manipulate the ones we got. Boom, right!?

I just found that the sprite pack we are using for the player actually has an attack animation, so thats great. I am going to make a jump animation for four directions and then implement it in the game, and then go back and do the attack animation.

I am thinking that I can make the sprite have the shadow, and just move the image…and not the collider? I don’t want the player “bumping” into a mob that is two squares above the player because he is jumping into the ‘air’ .

I had thought about having a tile map for representing mob and player locations, this way we could have a virtual ‘zed’ axis for the player to jump up into. maybe that would be overkill?

And now I am realizing that if a mob was to fly, it would have to have location tied to the ground. hmmmmm Lets try just having the sprites be displaced from the collider ( so the image moves in animation but the collider stays put ). I think this makes sense. Other than missile attacks….. shit. Oh boy, two colliders? Why the heck not, right , I mean,…. I am not even sure that would work. How about we just go in that direction and hope it all works out for the best lol! HAHAHAHAHAHA

So, lets do this beeeatcho machado !

First, the damn sprite. I hope this works lol

front

side

back

Yeah, so …. a little distortion and a shadow?!////….. mmmmkay, lets see if it works lol

A day goes by, and I am wondering if i might be doing this wrong. So just to recap, the issue is this:

We want the player to jump. It is a 2d world, where everything is a flat image in the X and Y, and then there is some layering of images in the Z. If the flat image could jump, the change in Z wouldn’t really be seen. in fact, you wouldn’t see it. So the idea was to have the sprites image move/animate, keep the collider still as to not ‘bump’ into sprites to the north of the player, and probably create a DoubleZed variable holding the virtual Zed difference. So, mobs at ground level would be 1, and a jump would go to 2, and a bird could fly at 3-5 or higher…. things in the water and underground would be 0 or less.

When I write it all out, it seems completely retarded, like I am overthinking something really simple. I do this a lot, hence my internal suspicion.

The part of this I think I should change right now before implementing it in unity is not having the jump animation include a shadow, but instead, create a shadow in real time…. some way , some how…. maybe if using a light source and actual shadows, it might look really awesome. Or if anything else, it would be a object within the player object, that grows and shrinks depending on the jump height.

Just frames, no shadow

Ugh, just got the animation clips set up and then had unity crash, only to reboot and find I didn’t save . The clips are still there, just empty. Nothing quite like doing something twice. Okay, back to it.

So when it crashed, the player woulden’t move, yet I hadn’t done anything in the code, only set up the animation clips for attacking and jumping. In my jumping animations, I had transform properties animated, which apparently is a no no if you are moving the player via other means. I think anyways. But this makes sense, and it is better. I am not sure what I was thinking.

So, yeah, the script will control the jump – and this way we can turn the collider into a trigger while its in the air, which will be the solution for bumping into bad guys ( or untouchable blocks ) when jumping.

I also don’t want to write a gravity script…. so, to use the Unity physics engine, we will turn on Gravity momentarily , take note of the jump off point, and when we reach it again, we will stop the player, nullify its velocity, turn off gravity , and make sure the player is where he jumped off from. Boom!

Two days later, and the player animates whilst attacking ( I think he is animated to shoot a bow, so reversing the motions kind of make him look like he punching – and then the weapon item can have a animation set, that should be able to append to the animation and play together – that is going to look crude as heck for the prototype ) and jumping!

Focusing first on jumping north, we have to calculate where the ground is, or rather, where the shadow should be, minus the distance Y+ that is from jumping. I thought it would be as simple as the_ground = player_position.y – velocity.y if velocity.y is above zero. Close but no cigar. The shadow goes from bottom to the top of the screen with no real relation with the player, which ruins the illusion.

So here, it works, pretty darn well, and honestly I have no idea what the #*@! is going on

so now, jumping south.

Basically, the shadow becomes the “landing” point, so going south was a bit of a challenge in the sense that the player doesn’t really show any kind of true movement, the shadow becomes the new “spot” to where the player is. So I simply make the shadow move to a certain point based on jump height ( a variable ) and then allow the player to “fall” ( in gravity ) to the shadow.

View the full article