Sorry for the double post. But, to see the difference. You can open the example you provided originally. Select the Arrow Sprite in the Layout Editor. Then manually change the "Angle" field in the Properties on the left hand side to different values, from 0-359 to see what we are talking about as far as visual/facing angle

EDIT: It also appears the example is only reading off the movement on the Y Axis. So up is negative, down is positive.

Hey there Ecation :)

That is because, in your example file. You are reading the angle that the Sprite made to look like an arrow is moving.

If any object in Construct 3 is moving towards the Right on the X Axis, or Down on the Y Axis it is moving in a positive direction. If an object is moving Left on the X Axis, or Up on the Y Axis, it moves in the opposite direction, which then become negative.

So to make a platform object jump, you are changing the direction of movement into a negative number/value. Or say a trampoline in my current project. When the player lands on top of it in any way, it will set Platform Vector Y to -600 or -2000 depending on which trampoline is jumped onto(and how I've setup that trampoline's power variable). Which shoots the player upwards, and acts as a high jump.

If you start falling from that jump, then it's now moving in a positive direction on the Y Axis, from it's current position moving downward.

I hope that makes a little sense. The easiest way I learned angles and directions of movement in Construct 3. Is moving my mouse around the Layout Editor, and then watching the "Mouse: (x, y)" in the bottom right of the Layout Editor window. Moving it around, you can see the X and Y values increasing/decreasing, depending on the direction you move your mouse cursor.

EDIT: To further clarify. It's different from the facing angle. The facing angle works like a clock as mentioned earlier. Where facing right is 0, down is 90, left is 180, up is 270. Then right before completely becoming right faced again it goes from 270-359, then hits 0 when the object faces exactly to the right again.

So the Object facing angles, and the movement X & Y values are different in the way they work. After messing around and creating different games in Construct 3 it becomes much clearer over time. It took me a while of playing around with my Mouse Cursor location in the layout view. As well as manipulating object angles in the layout editor properties on the left hand side directly to figure it out.

FURTHER EDITS: Clarifying between "angles" and "directions" in some areas, to hopefully have this make more sense.

Apologies for the double post. But, I'll be on Discord for a while longer. Feel free to add me if you are on there. My username is between the quotations, "Fun & Games#6077"

I can take a quick look at your Project File, if you'd like.

EDIT: Here is a link to an entire screengrab of my Player's Event Sheet: https://ibb.co/sqbzGgg. If you want to get an idea of how I'm handling the various states of Teddy, in my project.

Yeah, I would set it up to jump with a certain key. Then on player landed, set back to idle/walking/etc. The only time I really mess around with Vectors, is for trampoline objects, sliding attacks, or knockbacks from enemies, etc. Or if I need to set the Vector(s) to 0, if they are causing an issue. The platform object will store the Vector value, then call it again.

I had an issue where my player would go into EdgeGrab of a ledge. And, if I pressed "S" to "Fall" out of the EdgeGrab state. The player would jump up a bit, before the "Fall" took place. This was because there was still a value held within Vector Y in that case. Then when I used the MoveTo behavior for the EdgeGrab it was moving the player to where it needed to be. But, without setting Vector X and Y to 0, the player was jumping and/or moving a bit left or right when I was trying to drop out of the EdgeGrab.

Looks like a sweet MegaMan X clone you have going there :). The gravity and jump in the video, reminds me of underwater areas of the original game.

When bugs crop up, I usually try to think of what I most recently added into my game, that may conflict with game play mechanics that were working previously.

I like keeping backups of each project, saved at different stages of development as well. So I can go back and review any changes I've made over time, or see how I was performing certain actions the day or two beforehand. If something strange happens along the way.

It's handy to use a collision box for the platform behaviors, then an animated sprite moved overtop and set as a child of the collision box at the start of layout. Using the collision box for any behaviors & collisions, and the player sprite on top for all the animations during various conditions. Especially, if the frames of the Player Sprite, Enemy Sprite, etc, change dimensions over time.

You can somewhat see what I mean in my YouTube video here: https://youtu.be/kHscxNDZqXU . There is some debug text used to keep an eye on the Player's State as well. As you can see the enemies do not use a collision box below the animated sprites. This is because I am sure to keep each frame of every animation the same dimension. So when I set a bounding box, origin point, and image points to every animation. They will be at the exact same location in each animation and frame of the enemy object.

Hopefully that makes some sense. Sometimes I feel like I'm just rambling. But, I'll have a tutorial series soon, where folks can follow along and recreate what I've got going in Teddy's Adventures.

Like lennaert said, there's probably a simple conflict somewhere in your event sheet(s). This happens to me all the time. There may need to be an extra check somewhere to see that you are not jumping/falling, but are on the ground. Then if so, set back to idle/walking states depending on if the keys used to move around are being pressed or not.

I got this sorted out perfectly just now. It turned out better to disable deceleration, have Player Slide, Stop, then re-enable default deceleration for Platform Behavior.

This way, it doesn't matter if the Player is Running, or Walking. Causing it to move it different speeds on the X plane. The player will bounce back the same distance, every time.

Thanks again for your support & helpful input dop2000 :)

> It's odd, because if I do set Vector X to 1000000 or -1000000 the player does move further than say setting it to 100000 or -100000

Maybe you've set a very high deceleration value? I just tested and couldn't see any difference between vectors 400, 10000 and 10000000. (character max speed=300, deceleration=1000)

Hmmm. I've got my PlayerBox set at 2000 for Default Deceleration.

EDIT: Max Speed is 330, acceleration 1500

EDIT 2: I do have a very high deceleration value for the Custom Movement Behavior. But, I am not using that at all within the PlayerDamage Functions. Purely the Platform Behavior for all movement on Vector X/Y.

I'm going to play around with it some more this afternoon. If it doesn't make much difference which way the bounce back is achieved. I will just leave it as is. It looks perfect right now, for this use.

Very cool, Tomycase! This looks great :)

EDIT: Hanging onto this example, for future use/review ;)

Hey hey :)

I'm curious about something, and figured I would make a quick post in the community before I power down for the night. While working on some new gameplay features in my current project. I was messing around with different knock back functions. When the player gets damaged, sending it backwards(relative to enemy.x or projectile collision) and upwards or downwards, by adjusting the Platform Behavior Vectors X & Y. Then flashing, taking damage, putting into Hurt State, etc.

What I noticed is I need to set the Vector X parameter to an extremely high amount of pixels, to get the result I am looking for. But, the Vector Y can be much much lower. I figure this is because of the Platform Behavior's, default Deceleration property. And, I'm assuming the Platform Gravity has nothing to do with any Friction slow down the player on the X plane, as the value can be far lower for sending the Player upwards on the Y plane.

Does it really make any difference, whether you are just setting an extremely high amount of value to the Platform Vector X? Or if you temporarily lower the Platform Deceleration, and then use a lower value on the action adjusting the Vector X(positive or negative depending on location to enemy), before setting the Deceleration back to it's default? I store all default platform behavior values for the Player as variables on start of layout, to easily set them back to default. If I ever need to change them for any other actions.

I'm not really sure if it makes a big difference or not computing/performance wise. I've tried it both ways, and can get the effect I'm looking for either way. Setting a really high value to Vector X, as a positive or negative value. Is just far less action blocks within the function, and keeps the event sheets a bit cleaner. But I'm working on a couple different knockback functions, to keep the event sheets minimal, either way.

Castlevania IV was the first SNES game I bought with my own cash, and I played the crap out of it XD.

Basically it would need to be setup as a linked chain of objects that move in conjunction with the head. Very close to what alextro has provided. The chain links(vertebrae of the skeleton's spine) were loose, and would overlap if they were within range of each other. In the original game anyways.

Basically the head of the thing would move around in circles, or figure eight motion. While pausing here and there to fire out a fireball from it's mouth. And the chain links attached to the head would dangle and move around. Like a loose hanging chain between the head, and the wall the other end is attached to.

I've never attempted anything like this sort of animation. But, I wonder if a timeline could be nice for something like this? That is if you want to take the time to animate each key frame, and link into position. And have pauses where it stops and fires out a fireball at the proper times.

Might be worth playing around with. I wish I had more time, to toy around with ideas like this one. Tomorrow is "my day off", so I'm on the computer least amount of time possible. But, maybe I'll hop on for an hour or so, and have a whack at it.