ObjectEntity falling property, not being set consistently on gravity conditions

[agmcleod]

Original issue from google group:

I'm working on a top-down 2D RPG. I disabled gravity and derived my character entities from ObjectEntity.

When I call updateMovement() and a collision occurs on Y, the code changes Y velocity based on falling.

this.vel.y = (this.falling) ?collision.ytile.pos.y - this.collisionBox.bottom: 0 ;

The falling state is set in a collision or computeVelocity, but on the latter it only applies if gravity is set.

Thus, once I go into a collision with a ceiling in updateMovement, the falling state is set permanently to true.

The fix simply forces this.falling to true in computeVelocity when there is no gravity.

[Deathspike]

To elaborate further from the original topic (I forgot I could put issues here...)

A collision can trigger it:

https://github.com/melonjs/melonJS/blob/master/src/entity/entity.js#L1065

In computeVelocity it should become false:

https://github.com/melonjs/melonJS/blob/master/src/entity/entity.js#L949

But that won't work when gravity is disabled.

[agmcleod]

@Deathspike excellent, thank you!

[parasyte]

I'm kind of confused why this would be a problem.

The falling flag isn't really used for anything when gravity is 0. Yes, it will position the entity exactly against the solid tile by adjusting the velocity when the falling flag is set ... but it does unset the falling flag on a collision in the downward direction, and the velocity is zeroed.

Correct me if I'm wrong, but I believe this means the only effect is that your entity may not exactly touch tiles in the downward direction until after you've set the falling flag by bumping into a solid tile in the upward direction. Unless you have very high velocities, this should not be noticeable (a maximum of n - 1 pixels, where n is the velocity). And if you have high velocities, you'll have other problems, like #16. ;)

[Deathspike]

I'm going to illustrate the problem with this image of Pokemon, because I'm just implementing a movement system that is exactly like it and I haven't worked on my assets pipeline yet. In case you haven't ever played these games, you move in one direction in perfect alignment of the tiles. While you're moving you are not snapping to each tile, but you move as you would in a regular game. Now to illustrate the problem:

If I walk up and touch the collision layer (in red) at position 1, that particular collision will set the falling flag until I hit another collision going downwards, at which point the system is intended to snap me to perfect alignment above that collision. I then move to position 2 to prepare for a collision running into the house on the right, and start moving to collide with it. At this point, this collision will trigger on each axis (due to the perfect alignment of the character and tile) and use the falling flag to 'correct' my position to be properly aligned above the collision tile. The result is position 3, which is obviously wrong.

This can happen in rarer edge-cases in free-move top-down 2D movement, but the perfect alignment of my movement system guarantees this incorrect behavior. The solution I came up with was rather simplistic, don't use the falling flag when there is no gravity to begin with. Another solution that might be possible is to ensure that collision detection does not happen on the Y-axis when I touch a collision in this particular manner, but this change could have a lot more unforeseen side effects in other types of games.

I hope I elaborated sufficiently, please let me know :)

[agmcleod]

Interesting. I updated my ld27 game with the latest 0.9.10 build, let me know if you can reproduce it, as I've been having trouble. My game is just using updateMovement to work with the collision layer. Can check it out here: http://projects.agmprojects.com/ld27 The player can be accessed via game.player if you need to check the falling attribute.

[parasyte]

@Deathspike thank you for the detailed explanation! That's what I was looking for. I'll try it out when I can.

But I've also implemented a similar movement mechanic in Sprung Fever and I did not see the behaviour you describe. It's no longer used because the initial snap/alignment to the tile grid felt too jarring when changing directions.

[parasyte]

@Deathspike I haven't been able to replicate your findings. But it may be because my player entity is not the same height as the tiles in my map; Everything works exactly as it is supposed to when I forcefully align left/right movement to the tile grid. (And yes, I'm "bumping the player's head" to set the falling flag.)

Do you have a minimal test case that shows the problem? If not, I can create one.

[parasyte]

FYI, the Travis-CI error is a fluke. Some external npm SSL thing that has nothing to do with the patch.