Open pmer opened 7 years ago
Here is what I'm thinking:
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.
Here is an idea for moving the stance/facing system into entities:
walk
doesn't need to be told a facing.walk()
such that only one of x or y is non-zero. This emulates 4-way.walk()
methods can be updated in sync. (Removing the facing argument & gaining an "animation base name" concept.)Cool, just make sure not to change the stance in straight bump mode.
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?
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.
Oh, that works.
@seisatsu Can you handle this one? You know the entity movement code well.
I'd tackle it in three stages:
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.
I'll push #125 forward.
I am rewriting some of the PixelModeEntity movement code because I don't know how to modify it to add bumps as-is.
@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.
I'd put it in the descriptor file.
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.