Slipping and sliding

My latest test has brought me to the point where I have actually created a preliminary incarnation of the physics system behind Slipslide, the game which I ultimately intend to make (as I mentioned in an earlier post). So, I've decided that now is the time to shed some light on the game.
Firstly, Slipslide is essentially a puzzle game. But no, it isn't another Tetris clone or one of those annoying match-the-blocks deals. Slipslide is based on a puzzle which was found in Pokémon Silver, in an icy cave (the name of which currently evades me) and in one of the gym sections. In these puzzles, you were required to make it from one side of the area to another by sliding across. Once you started moving in a given direction, you were unable to stop or change direction until you hit something. There would be many boulders littered around the area, and you would need to reach the exit by sliding between them, as shown in the image. It's basically a particularly hard type of maze.
The first Slipslide game, which we made using the Blender game engine, attempted to put this idea into the third dimension. However, the translation was a bit too lossy, and the game ultimately ended up being amusing for a while but incredibly buggy. Unfortunately, setting up collision bounds for objects in 3D just didn't work properly, and many levels had glitches where you could go through the obstacles or hitting an obstacle launched you into the air for some reason. This wasn't helped by the fact that the Bullet physics engine (the one used by the Blender game engine) was far too realistic and completely unsuited to a game with such simple physics. Blender's game engine, while being great for simple projects or visualisations, isn't powerful enough to handle the vast amounts of logic hack-arounds I was loading it with to make it move in the way I intended. To keep it running at a playable speed, the visuals had to be cut back severely and there were levels with plain white floors or absolutely texture-free skies.
Therefore, I'm going to be writing its sequel in PyGame. No ready-made game engine, no built-in physics, no GUI level designer and no point-and-click logic; I'm going to do this one entirely from scratch. This means I have complete control of what happens - I'll no longer need to put in tons of logic in an attempt to simplify the physics as there'll be none there. So the final game will be much faster and truer to the original concept. Which brings me back to the latest development test.
I've written a class of sprite which follows the Slipslide laws of physics to the letter; once you press an arrow key it moves in that direction until it hits the edge of the screen where it stops. There aren't any obstacles currently, but that shouldn't be particularly hard to add. The main thing is that while the logic for Slipslide 1 probably used several hundred lines of auto-generated C++, this one uses a mere 70 lines of hand-coded Python.
Now that I have a basic understanding of sprites, I'm going to look into animations and collision detection. More updates to come...