Bump the player when running into a corner if that will get them unstuck

[pmer]

No description provided.

[seisatsu]

With the current setup you kind of have to go out of your way to get stuck, though I can see some utility in this, especially if we decide to change at what point the entity collides with a tile like we were discussing earlier.

We may even add a "clip" option for the author to set how far the entity must be over the tile before clipping.

[pmer]

Here is what I'm thinking:

• Diagonal bump: If an entity is trying to move up-right (whether at a 45° or 30° or any other diagonal) but there is a wall above them, we should change their move to a move right.
  • This involves changing the stance... and even the facing! That means the PixelModeEntity must contain logic to change the stance and facing in response to a bump.
  • Does not use "clip" property.
• Straight bump: If an entity is trying to move up but there is a wall above them, we should check to see if they are within "clip" pixels away from a blank tile to the left or right of the one blocking us. If there is a blank tile, and the closest one is to the left, we change their move from an up to a left. We can also choose to limit the entity's speed to the precise distance required to get past the tile currently blocking them in case the entity has a high speed value. And etc. if the closest blank tile is to the right.
  • Also requires that PixelModeEntities have stance/facing logic.

The bumps will be fairly straightforward, I think. But the moving of stance & facing logic into the entity will be different. @seisatsu what do you think?

Edit: Updated straight bump algorithm to work with clips larger than one tile.

[pmer]

Here is an idea for moving the stance/facing system into entities:

• We know facing will only have four values so that can be entirely brought into the entity with no loss. The entity can just calculate this on its own. walk doesn't need to be told a facing.
• Stances are more complex. We want games to be allowed to have a number of different walk and stand animations for each entity. (Imagine an idle animation for an entity while they're waiting around, or a walking versus running animation for different speed walks.) Entity stances should be composed of two parts: an "animation base name" string that the world can set at any time and a direction that the PixelModeEntity code sets. The final stance is the concatenation of these two. How can PixelModeEntity know whether the stance direction is 4-way or 8-way? Answer: it always uses 8-way.
  • Games can willingly limit their calls to walk() such that only one of x or y is non-zero. This emulates 4-way.
  • The only game I've ever seen which had more than 8-way directional sprites is Diablo 2. It had maybe 16.
• Turn- and tile-mode entities are compatible with these changes & their walk() methods can be updated in sync. (Removing the facing argument & gaining an "animation base name" concept.)

[seisatsu]

Cool, just make sure not to change the stance in straight bump mode.

[pmer]

The straight bump mode will rotate the player by 90° so it'll have to change the stance. Hmm, it probably shouldn't change the facing though, should it?

[seisatsu]

I don't think the player should visually turn 90 degrees while bumping. Just make walking up go left for a split second. Turning in this situation would look twitchy.

[pmer]

Oh, that works.

[pmer]

@seisatsu Can you handle this one? You know the entity movement code well.

I'd tackle it in three stages:

1. Move facing & stance logic from stdlib to entity.
2. Add either diagonal or straight bumps.
3. Add the other of diagonal or straight.

Also pick either this or #125 for 0.0.8. There's so many issues requiring changes in entity.py it's scary right now.

[seisatsu]

I'll push #125 forward.

[pmer]

I am rewriting some of the PixelModeEntity movement code because I don't know how to modify it to add bumps as-is.

[pmer]

@seisatsu Should bumps be restricted to only the player entity? Or might other entities use bumps?

If just the player, then the maximum bump clip can be put in config.json and can be user-editable.

If arbitrary entities can use bumps, then bump clip should be in an entity descriptor file.

[seisatsu]

I'd put it in the descriptor file.