Project link: https://scratch.mit.edu/projects/762984372/

Issue: During a camera zoom, player clips through the floor

To elaborate, my project utilizes a dynamic camera script to position objects (and the player) and adjust their size with a zoom level. During the main gameplay loop, when the player uses a certain ability (keybinded to “q”), they inexplicably sink into the ground during the camera zoom, which you may assume is not beneficial for them.

Position and size fencing is bypassed via a script and the positioning system doesn't seem to have any issues, additionally, the player is not scripted to move during the “q” attack excluding the initial lunge which only changes the player X position.

Another issue that may be related is player collision box mildly clipping into the walls when pressed against them.

To reproduce this issue, wait for intro cutscene and loading cutscene to end and then press “q”. Might help to also disable ghost effect on player collision and ground collision. Camera positioning script can be found in the “Player” sprite and the involved sprites are only really “Player” and “Collidable”. Fencing bypass is achieved via “pos” myblock.

Attempted fixes:

- Turning off fencing via third party, fixes it but still doesn't solve the root problem
- Rounding camera zoom to 3 d.p., seems to have no efect

So i'm stumped and the player is half underground unless someone can find the cause of this “mild” inconvenience.

Solution proposed (replacing collision with a list/variable based check) currently isn't planned for implementation so if the cause of the clipping is found that would be prefered

Why is the player's position affected at all by moving/zooming the camera? Shouldn't the camera only affect where they appear on the screen? Its possible the problem is that your player is operating via “x/y position” and “touching _” blocks instead of being hard coded into the game as a hitbox. If you haven't already, you should make the player simply existent in variables (rather than on the screen) to avoid tangling its position on the screen with its position in reality.

Does that make sense? Tell me if this was helpful!

Current system functions off physical hitbox comparison and not variable hitboxes to avoid having to compare the players theoretical hitbox (hitbox only in variables) with a really long list which might cause lag long game development time. The script operates using touching and X/Y positioning blocks currently In theory, the camera shouldn't affect the hitbox of the player but the current issue seems to suggest otherwise (as disabling fencing and not having the camera zoom removes the issue).

Thank you for your suggestion though, it was helpful for considering other alternatives!

Yeah, if you switched to variable hitboxes it would probably be a lot of work but also probably fix this bug and a lot of future bugs. The nice thing is that after you spend forever implementing a more complicated but more flexible system the rest of the coding process becomes pretty easy. As far as performance is concerned, using that idea shouldn't slow things down very much - and if they do, it can probably be worked around by calculation-skipping and improving code structure.

Issue I see is for more complex maps, e.g. the addition of slopes, moving collidables and enemies that react uniquely to collidables. Slopes would require either a special formula for hitbox comparison or marking out several collidable cubes, moving collidables would need to either function off a tick based collidable system or have an exception in the code and enemies that react to collidables would add additional clones iterating through the collidables.

Hmm… yeah, slopes would be complicated. I haven't really done slope stuff before. My guess would be to use more complicated geometry stuff rather than square and circle shaped hitboxes. But umm… good luck!

Seriously though, that would be very hard. Adding hitbox collisions that take rotation into account would be a lot of work. I'm assuming you're picturing boxes at a ~30 degree angle on the floor?

The way I see it there are two options.

1. “Touching sprite” collisions (what you have right now)
   

The problem is that camera zooming makes the game freak out, since something only intended as a visual effect is affecting the player's position in space. Camera scrolling is also a potential issue waiting to happen.

The fix would probably be removing camera zooming completely but I could see more problems surfacing later.

• Variable hitboxes
  

More flexible and safe from graphic effects but harder to program. Still, programming it wouldn't be too hard - until you add rotating objects and slopes.

The fix would be either be being a mega-genius and adding the hard stuff anyway (which I couldn't do btw) or just not using slopes.