First thing I did was to rewrite the code so that the mysterious and potentially confusing "bump" is split out into four variables:
tl,tr,bl,br = wallHit(self, mx, my)
if (mx > 0 and not ((tr > 0 and bl > 0 and br > 0) or (tr > 0 and br > 0) or (tr > 0 and br == 0) or (br > 0 and tr == 0 and bl == 0))): #right
x += (mx * self.movement)
if (mx < 0 and not ((tl > 0 and bl > 0 and br > 0) or (tl > 0 and bl > 0) or (tl > 0 and bl == 0) or (bl > 0 and tl == 0 and br == 0))): #left
x += (mx * self.movement)
if (my < 0 and (tl == 0 and tr == 0)): #up
y += (my * self.movement)
if (my > 0 and (br == 0 and bl == 0)): #down
y += (my * self.movement)
if (self.jump == 0):
if (br == 0 and bl == 0): #down
y += (1 * self.movement)
elif (self.jump > 0):
if (tr == 0 and tl == 0): #up
y += (-1 * self.movement)
player.jump -= 1
else:
player.jump = 0
This is still confusing, so I add:
tl = (tl>0)
tr = (tr>0)
bl = (bl>0)
br = (br>0)
And subsequently:
if (mx > 0 and not ((tr and bl and br) or (tr and br) or (tr and not br) or (br and not tr and not bl))): #right
x += (mx * self.movement)
if (mx < 0 and not ((tl and bl and br) or (tl and bl) or (tl and not bl) or (bl and not tl and not br))): #left
x += (mx * self.movement)
if (my < 0 and (not tl and not tr)): #up
y += (my * self.movement)
if (my > 0 and (not br and not bl)): #down
y += (my * self.movement)
if (self.jump == 0):
if (not br and not bl): #down
y += (1 * self.movement)
elif (self.jump > 0):
if (not tr and not tl): #up
y += (-1 * self.movement)
player.jump -= 1
else:
player.jump = 0
There's no reason to make your code look nasty until you're absolutely sure it works the way you want and you have to do it for some performance reason. Now we can start talking about the problem domain, and the specific kinds of behavior you want from your collision response.
The system you have now has a majorly important property: It tries to avoid performing any movement if there's overlap, which is less popular than the "move first, then separate the overlapping collision" system. The reason why the latter gets used more is because it's easier to get started with and performs a bit better. However, once you move beyond "everything is a same-size square" cases, you start having to hack special cases into separation algorithms so that they correctly slide characters that are running pressed up against the environment geometry, and you can run into nasty stuff where separating along both axes will pop the character the wrong way.
Your method can be cleaner because it will never overlap, but you'll have to add in a way to iteratively narrow movement, or else objects will just stop some number of pixels
before they touch the environment.
The other important thing here is that you treat x and y responses independently with ad-hoc logic. This is an easy source of "character walks through walls but can't jump" types of behavior. It's the most performant way to do things and can be made to work for simple platform behavior, but as you add special cases it can turn nasty very quickly, and it tends to interact poorly with animation behavior.
A more controlled solution for complex situations is to create a set of finite states and a transition system for "ground" "air" "slopeclimb" etc. Then you will be able to describe in very fine detail things like, "when the player is in the ground state, to transition to the air state, the player has to either have upwards y velocity, or have no ground underneath." And as you add more cases - moving platforms, ropes, slides, etc. - you add more states and more transitions.
If you do choose to code up a transition system, the rule of thumb is that the state is just a block of conditions to direct where to transition next(including "transition to the same state") - the action itself happens after you determine which transition to use.
Don't forget that a lot of collision problems can be conceptually inverted - the "avoid overlap" vs "overlap then separate" is one example. Another example is that instead of seeing the environment as an open space with walls, you can envision it as a totally solid area with gaps of geometry inside(this is how the BSP collision of Doom and Quake worked.)
Developer
