Change angle player based on platform angle

0 favourites
  • 11 posts
From the Asset Store
Basic Rounded Vector Geometry Player Design with Glow for 3 player games
  • Hello everyone,

    I'm trying to optimize the logic that I have already made. Checking the CPU usage it takes 2% only for this function.

    Basically, on top of the collision player I have the animation player. When the player move, there are 2 sprites on the right and left of the collision player that is always static at angle 0. These 2 sprites, check if they are touching the solid terrain. If the player moves and there is a hills for example, the angle changes. When the angle changes, I'm able to understand if the player is uphill or downhill based on where the player moves.

    I bet there is a better way to achieve this. However I can't figure out another solution. The fact that I'm using 2 sprite to check every time the collision impact the performance. I would avoid to change the angle of the player based on the solid terrain angle. I found several examples on the forum but all the links are unfortunately broken.

    Thanks!

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Hey!

    Maybe try the line of sight raycasting? You can get the reflecting angle from that.

  • Hey!

    Maybe try the line of sight raycasting? You can get the reflecting angle from that.

    I knew that the sight raycast is helpful if you want to integrate it when you are using enemy or similar. How would you apply in this scenario?

    Also, I'm checking only the terrain solid visible on screen, and also I have an extra event that's disable all collision based on the distance. But still, 2% of the CPU is too much. Is one of the most high % of my events.

    Thank you

  • Maybe cast from players origin to a player imagepoint at his "feet". Or just below his "feet". I suspect you only need to cast one ray.

  • I put together a simple demonstration for you. It's the surface normal you want, not reflection. My bad.

    It is far from perfect, just an idea.

    gofile.io/d/VUZlpB

  • Forgive me if I misunderstood your question but to simplify your current method could you not just check for overlap on the player sprite at an X offset?

  • I put together a simple demonstration for you. It's the surface normal you want, not reflection. My bad.

    It is far from perfect, just an idea.

    https://gofile.io/d/VUZlpB

    Thank you for the awesome example, I did a quick test however the performance are about the same.

    Forgive me if I misunderstood your question but to simplify your current method could you not just check for overlap on the player sprite at an X offset?

    Yes, I tried it but for some reason it doesn't work. I would take a better look. I did the X offset from a specific ImagePoint.

  • What I would do is:

    Before game starts, spend around 1 second, to (automatically) survey the terrain and store 'angle' data in an array. That way, all the CPU-consuming tasks (collision-checking for angle detection) will be done beforehand and not in real-time.

    For example: Use the Ray-casting method by (above), and have it run along the terrain rapidly (use object time-scale if possible), and as it moves, every X distance, it checks the angle and stores in an array.

    Then, when the player uses the terrain, based on the X location, it uses the array data to set angle.

    Just a thought. What do you think?

  • What I would do is:

    Before game starts, spend around 1 second, to (automatically) survey the terrain and store 'angle' data in an array. That way, all the CPU-consuming tasks (collision-checking for angle detection) will be done beforehand and not in real-time.

    For example: Use the Ray-casting method by (above), and have it run along the terrain rapidly (use object time-scale if possible), and as it moves, every X distance, it checks the angle and stores in an array.

    Then, when the player uses the terrain, based on the X location, it uses the array data to set angle.

    Just a thought. What do you think?

    This is sounds the best approach I guess. But could you elaborate a little bit more? The level is not linear, meaning that it can expand horizontally and vertically. Also, some platform can rotate and move. So my concern of having an array with fixed angle wouldn't allow me to change the angle on dynamic platform. Still, I could do it for the static ones, that are the most used... However, I would still need a system to get the angle for the dynamic platform.

    With the collision checks I did, it basically works with any solids of a specific family. But still, 2% of CPU is quite a lot. It is actually one of the most consuming CPU events.

    Does anyone know some math formula that would help with it? I can try to find a solution using only the player sprite with the x offset collision. This would decrease the check collision I guess. The game run smoothly already, but still 2% it seems quite a lot

  • The level is not linear, meaning that it can expand horizontally and vertically. Also, some platform can rotate and move. So my concern of having an array with fixed angle wouldn't allow me to change the angle on dynamic platform. Still, I could do it for the static ones, that are the most used... However, I would still need a system to get the angle for the dynamic platform.

    Yeah, that approach will work for static platforms.

    I may be able to give you more ideas, if you could share how is your terrain going to be 'moving' or rotating? I can't relate, because of the sketch above, I am guessing it is made up of triangles, how are you managing the movement, a screenshot or video might help.

    I do have some ideas in mind, but it all depends on how your terrain is created (if it can be recreated differently maybe?).

  • > The level is not linear, meaning that it can expand horizontally and vertically. Also, some platform can rotate and move. So my concern of having an array with fixed angle wouldn't allow me to change the angle on dynamic platform. Still, I could do it for the static ones, that are the most used... However, I would still need a system to get the angle for the dynamic platform.

    Yeah, that approach will work for static platforms.

    I may be able to give you more ideas, if you could share how is your terrain going to be 'moving' or rotating? I can't relate, because of the sketch above, I am guessing it is made up of triangles, how are you managing the movement, a screenshot or video might help.

    I do have some ideas in mind, but it all depends on how your terrain is created (if it can be recreated differently maybe?).

    The solids are sprites and they can be angles or squares. Most of them have a triangle collision because I guess it take less resources to check the collision. So to make up the terrain that the user will never touch below, I use triangle collision. The difference between the static platform and dynamic platform is that the dynamic can move and rotate without using any behavior. I differentiate them because the dynamic platform have the designed attached on it, so when they move the graphics needs to move accordingly. Also, the dynamic platform can form a "unique" platform that can move all together using the pin behavior. Both solids are in the same family, so in my logic I'm checking the collision on the family.

    It is important to note that the player can't move if the degree is of solid is close to the 75 degrees. The example that provided is really good, because even if the player get even extreme angle, I could still use another event to limit the range angle of the player. Also, the angle that needs to be changes is only on the animation, not on the player platform behavior, forcing the player to don't move in right angles.

    I will post a gif of the game soon. Thank you!

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)