search

Den4200 / game-jam-2020

My team's submission for Python Discord's Game Jam 2020.
https://pythondiscord.com/pages/events/game-jam-2020/
MIT License
3 stars 1 forks source link

MovingSprite movement is inaccurate #14

Closed Den4200 closed 4 years ago

Den4200 commented 4 years ago

When a sprite inherits this class and uses the move_to function, the sprite does not end up exactly where the destination was set. This needs to be fixed.

Den4200 commented 4 years ago

This may not seem too much of an issue. However, when inheriting this class along with PathFinder, a problem is very apparent. Since the sprite does not end up exactly where the destination was set, the sprite gets stuck whilst traversing the nodes in the linked list. This then causes the sprite to never reach its destination, causing the player to be stuck there forever.

albertopoljak commented 4 years ago

Done, but the player must tranverse to the nearest center as we discussed in Discord which is lengthy for here but just to say it as note.

albertopoljak commented 4 years ago

There's something wrong with it again

albertopoljak commented 4 years ago

Works nicely.

However when the player gets hit, sometimes he will get pushed just far enough into the wall (for example if he is standing in corner and the shoot is coming from derivative of 45 degrees pushing him further into corner) for the next CLOSEST tile to be the actual wall.

Curent idea is:

if there is collision with wall:

However if the player gets pushed just far enough then the closest tile will be a wall, so he will try to move in wall and get stuck in infinite loop.

Currently the engine deals with this by checking if the closest tile is passable, if it is not get the tile BELOW that tile (other directions to be implemented).

So currently the only direction that works is if the player gets pushed up (if up is wall then get the tile from below)

albertopoljak commented 4 years ago

I will try to change this so that if player hits the wall he reverses the vector direction. This should in theory work for all cases and should be pretty straight forward to implement (as we already have implementation that will slow him down after throwback), idk why I didn't think of it sooner.

albertopoljak commented 4 years ago

Dropping throwback support.