Help! My player is teleporting when I go left or right and I have no idea why.

0 favourites
  • 15 posts
From the Asset Store
Basic Rounded Vector Geometry Player Design with Glow for 3 player games
  • I click to run the game, the player sets down and then is teleported below the level.

    Can anyone help? I'm trying to insert new animations from a pixel artist I commissioned and this started happening.

    drive.google.com/file/d/1BFioyRM_NoVW9cUagCJHeAEEBellXNqQ/view Here is my google drive for the file. I'd really appreciate any help because I'd really like to not start over on my hobby project.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Your image origins are off. Go into the animation editor and, on the left side find the button to edit image points. Then, you just need to set the location of the origin to the correct point of the image.

  • This fixed it, but now there's a wonky animation ocurring when my character moves left to right. Do you know what that might be? I'm trying to figure it out.

    Is it the animation getting mixed up? i changed it to animate from the current frame instead of from the beginning just in case.

  • Thank you for the help btw. I took a few weeks off to commission and get this pixel art made and now I'm all out of practice and wondering why my guy doesn't even animate running lol.

  • I see this all the time with newer users. The animation is switching between the run and fall animations. Take a look at this screenshot:

    The arrow shows the distance between the floor and the collision bounds of the image while running. Since the collision bounds are not on the ground, the platform behavior thinks it is falling and swaps to the fall animation. I know intuitively, you think the collision bounds should stay wrapped exactly around the player but that isn't really the case in a game. Keep the collision bounds on the ground to avoid this problem.

  • I've moved all the collision bounds to the ground and the effect is still happening. I hate to keep bothering you with this, but any ideas? I've even made it so two points are on the ground while it sits there and it still seems to be ocurring.

  • Never mind, just took redoing all origin points because apparently there were some saving issues.

  • Hey a good trick and best practice is to use a different sprite object for controlling your collision and movement (usually a simple rectangle that never changes), and pinning your visual representation of the character to it

    also make sure that when you get a sprite commission to ask for the character to always be centered, so you don'T need to edit image points or things like that when you import files

  • Hey a good trick and best practice is to use a different sprite object for controlling your collision and movement (usually a simple rectangle that never changes), and pinning your visual representation of the character to it

    also make sure that when you get a sprite commission to ask for the character to always be centered, so you don'T need to edit image points or things like that when you import files

    Wouldn't your collision box be incorrect though if the character isn't perfectly rectangular?

  • Incorrect how ?

  • eleanorjmorel, please stop spreading this flawed logic. It has been passed around this forum for years but is only really useful in specific situations. The sprite has collision bounds for a reason. It is so you can define your collisions based on the sprite shape easily. A separate sprite which defines collision bounds is FAR more difficult to fit to the sprite object you are working with.

  • Incorrect how ?

    If you fired a bullet at a sprite that isn't a square but has a random square shaped collider the bullet would not collide with the correct collision point on the sprite

  • Nah.

    IT lets you ensure your physics object correctly fits your levels no matter what state the animation is in.

    it prevents a lot of bugs and fiddling with the animations for edge cases like one frame being 1 pixel too low pushing your character up. especially in larger projects. like, what if you'Re standing on a ledge and for a frame your collision is 1 less pixel wide and it just throws you down the ledge lmao

    it lets you reuse code for a lot of things since they'Re all based on the same physics objects

    collisions don'T need to be "character perfect" like give your players some leeway, let them put their head or body inside walls a little bit before you get a collision, what if your collision has weird diagonals for the arms when you'Re jumping and it just clips into a ledge you'Re trying to get to and your character ends up missing a jump for it (coming from below) or starts flying ( clipping from above)

    they do this in a lot of games like in "for Honor", characters are cylinders so they behave the same way no matter what their models are. In unity most games use pill collisions to let you walk up stairs instead of hart colliding with them and then IK the feel of the character. It'S a really common game development thing

    If you fired a bullet at a sprite that isn't a square but has a random square shaped collider the bullet would not collide with the correct collision point on the sprite

    Thats perfectly fine, it makes the player feel awesome that they evaded that shot. Then what you can do is make the player'S shots be way bigger so they'Re more likely to hit so the player feels like they'Re super accurate and talented at your game. That'S also a classic tactic a lot of games use

    If you look at celeste playthrough, a lot of players touch spikes without getting harmed!! IT'S a little gamedev secret !!!

  • eleanorjmorel I don't know your background in game developement but, I have over 10 years of experience working with Construct as well as Unity, Garage Games, Godot, XNA and programming games in Java, C++ and C#.

    Your examples are not relevant in this situation. For Honor is a full 3D game as well as Unities pill shaped colliders. If this sprite was a composite object made up of multiple sprites, then this could be a little more approriate to the situation.

    Your Celeste example actually shows a reason the separate collision object is a bad idea. If you define a hazard but your collsion bounds allow you to touch that hazard without being affected, that is a bad thing. I am not the developer of Celeste so I don't know what all decisison they made leading up to that situation so I can't really judge it.

    What I can say is, using a separate sprite for collisions instead of Constructs built in collsion bounds SHOULD NOT be passed around as the "best practice" for every situation. It adds another object that takes up memory. It creates a generic collision size/shape for objects when the developer may want something more specific (if you want the generic collision size/shape, you can use the bounding box as the collision bounds to get the same affect without these other problems). It adds complexity which is harder to upkeep (especially if the project winds up being handed off to another developer).

    Finally, I am not saying it is wrong to do. Just that pushing it as the end all be all for every situation is wrong. In this particular situation, I would not use a separate collision object. Your example of using the single object for multiple object types that have the same behaviors is one of the "specific situations" I referenced (however, this can be done using families without causing these other problems). Composite objects are another situation where a collision sprite would be a good option. This will be my last responce in this post about this subject. boomerfreak1, hopefully you have enough information about this to make your own decision about which method is the best one for your project.

  • eleanorjmorel I don't know your background in game developement but, I have over 10 years of experience working with Construct as well as Unity, Garage Games, Godot, XNA and programming games in Java, C++ and C#.

    Your examples are not relevant in this situation. For Honor is a full 3D game as well as Unities pill shaped colliders. If this sprite was a composite object made up of multiple sprites, then this could be a little more approriate to the situation.

    Your Celeste example actually shows a reason the separate collision object is a bad idea. If you define a hazard but your collsion bounds allow you to touch that hazard without being affected, that is a bad thing. I am not the developer of Celeste so I don't know what all decisison they made leading up to that situation so I can't really judge it.

    What I can say is, using a separate sprite for collisions instead of Constructs built in collsion bounds SHOULD NOT be passed around as the "best practice" for every situation. It adds another object that takes up memory. It creates a generic collision size/shape for objects when the developer may want something more specific. It adds complexity which is harder to upkeep (especially if the project winds up being handed off to another developer).

    Finally, I am not saying it is wrong to do. Just that pushing it as the end all be all for every situation is wrong. In this particular situation, I would not use a separate collision object. Your example of using the single object for multiple object types that have the same behaviors is one of the "specific situations" I referenced (however, this can be done using families without causing these other problems). As is composite objects. This will be my last responce in this post about this subject. boomerfreak1, hopefully you have enough information about this to make your own decision about which method is the best one for your project.

    I'm taking your word over his. I don't think its correct to wrap sprites in things that aren't the correct shape in this instance at all. If it was unity it would be a separate issue which I've programmed in. For a precision platformer it doesn't make sense to have the wrong shape. Super Meat Boy is a great example of how they made the character square just so they wouldn't have to change the shapes, Other platformers like yooka laylee and such use collisions that wrap to the object or sprite correctly anyways. Thank you man. Your advice was helpful. I'll add juice in other ways and not have incorrect collisions.

Jump to:
Order by:
Duplicate Topics
Posts
Views
Last Post
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)