Ok so I tried even making the sprite have 8 directional input and still not getting anything from the joysticks in vertical. Screenshot and file attached.

imgur.com/a/NpZv2JA

drive.google.com/file/d/1BFioyRM_NoVW9cUagCJHeAEEBellXNqQ/view

As the title says, I'm currently working on getting the gamepad joystick to move the camera for the player to look ahead a little. It works on the X axis, but I can't get the Y axis to work properly.

I've attached a screenshot of the functions I'm doing on the sprite that is invisible for the camera. Please let me know if anyone has a tip. Screens or written out what I need to do would be super helpful!

I can also lend my file if need be.

imgur.com/a/XmbZ5vl

Hello! I was wondering if anyone had a tutorial or some code screenshots for how to make a camera look ahead of the player and snap back using gamepad joysticks.

I'd like the player to look around the level slightly and when the joystick isn't in use the camera snaps back to the player position.

Any advice would be greatly appreciated

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.

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

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?

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

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.

Here, try

https://mega.nz/file/x1wlmQiR#78uKp5BSovMpvDdXahF6IDm0x8t9EdSupgWurYh9G5s

You're AMAZING, thank you!!!

As the title says, something really weird is going on with my character. All my character controls seem perfectly fine.

Here is a link to my file: If someone could help me fix the problem or do it themselves. I'm willing to venmo or paypal a small fee for helping me with this. I've been stuck for HOURS now and have no idea what is going on.

drive.google.com/file/d/1BFioyRM_NoVW9cUagCJHeAEEBellXNqQ/view

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.