Yes, you read correctly. The Slipslide 2 physics system is finally functional! But how on Earth did you undertake such a feat and succeed, you ask? Well, I shall elaborate for you.
Firstly, I used the method I mentioned in a previous post where it stops you from moving when you hit a block. But, to avoid the problem of the player not being able to move again, I made it set the player's position so that they were next the block instead of actually colliding with it. This means they can then move again, or even move back to collide with that block again; it'll still work. And no, that doesn't mean they hit a block and end up several pixels away from it. As it happens, PyGame only detects collisions when two objects overlap so I can move them to be right next to the block. This also gives a very slight bounce effect, which I find adds to the realism slightly.
However, making it work out where the block was and therefore where the player should be was more difficult. I had to make it think of the map as a grid, by dividing the player's pixel co-ordinates by 24 to get their grid co-ordinates (as each tile is 24*24 pixels). Because they were intersecting with the block this came up as the block's co-ordinates when rounded to an integer (Python always rounds numbers down). But I didn't want to place the player inside the block, so what I did was make it add 1 to the x co-ordinate if the player was going left, add 1 to the y co-ordinate if they were going up and so on. To do this, I set up a variable named "direction" which changes between "up", "down", "left", "right" and "stop" when the player presses an arrow key.
The walls, however, use a separate system entirely. For these, I set it up so that the character's __init__ (initialisation) method took variables for the maximum and minimum x and y co-ordinates. If the player's position ever crosses those points, it stops them and moves them back to just beside the wall (similar to the block collisions).
To celebrate the success of the physics test, I also added in some music which loops perpetually in the background. As expected, there were no problems on that front (PyGame already has a reasonably good mixer module built in). So now the only things missing are player animations, level-from-text loading, pausing, level goals, menus, sound effects, a proper sprite for the main character, level intros, the entire mediaload class, and a system for getting all a level's components from files using only the name of the folder containing them (which is easier than it sounds, but could still take a fair bit of planning). Yes, that is quite a lot. But the point is, the physics work! Yaaaaay!