Walking in front of/behind sprites

You just manage their relative depth. When you draw, you draw the "deepest" objects first, then the nearer ones. Sometimes, you might have to split up some of the images to get the effect you want -- for example, if you wanted a building with large columns on the front, and for the player to be able to walk between the columns and the face of the building, you would have the building and columns be separate images, and draw the character in between.

In a psuedo-2D engine (one which appears 2D, but is implemented with a 3D pipeline) you have more options for influencing how depth is applied.

Actually, reconsidering your specific case, it sounds like you want to be able to walk "around" houses, trees and other large objects in the game map; is that right?

If that's the case, you would typically accomplish that in one of two ways:

In a strict tile engine (all tiles the same size) you can accomplish this with having maps with multiple layers. In the past, I've used one base layer (eg, grass, dirt), one detail layer (things that accent the base layer, but appear under the player. eg flowers, dirt) and object layer (The player, Sprites, and other objects occupying that space), and an overhead layer, for stuff above the player. This is usually sufficient unless you have very complicated maps (say, a mountain pass with bridges passing directly over one another -- but even that can be gotten around by modifying collision data in many cases). You just draw things like this: base+detail->objects/sprites/players->overhead -- and each of those layers you draw from the top of the screen downwards.

In a non-strict tile engine (or generalized 2D engine) you can just draw objects as one image, ordered from the top of the screen down. There's still a base + detail layer usually, but no distinction between the object and overhead layers. In this case, you would typically define collision regions on objects which represent just the part of the object that the player and other sprites could collide with, rather than the entire image -- this usually corresponds with the outline of the object on the ground, in camera perspective.

Thanks for your replies.
Say I wanted to make it strictly tile based - and I wanted a house that I could walk behind - say 3*2 -
the bottom 3 tiles could have collision, and the top 3 (roof) didnt - drawing from top to bottom, in the order that you suggested - would allow me to walk behind ?

Yes -- in that case (assuming you mean the house occupies 3x2 onscreen tiles) the bottom row of tiles would be the "walls" of the house, and the top row would be (or at least include) the "roof" tiles. Put the wall tiles in the object layer with collision, and put the roof tiles in the overhead layer (the player can't collide with overhead tiles, so no collision.

Then you draw the base+detail layer, then objects, sprites, and the player, then the overhead layer. This will allow you to walk behind the roof tiles.

Ah! It makes perfect sense now, thanks

Couple of further questions that sprung to mind though - should the player be tile based (given that the legs etc, will have collision, but the head etc - should be drawn on top of other sprites - so that it can stand "in front" of them.

Also - do you think using alpha with overhead sprites - such as the roof of a building, will cause a slowdown?

The player shouldn't be a problem, as long as you draw all the objects within the object layer from the top of the screen to the bottom, then nearer objects will appear on top of further objects, regardless of their height. Its possible that you could have a very tall object clash with the overhead layer, but generally sprites and other objects are either short (no more than 2 tiles high) or naturally lend themselves to being put part-way in the overhead layer -- for example, the bottom-most part of a tree, like the trunk, would be an object layer tile, with collision, but the upper parts of the trunk and leaves would be overhead.

As for alpha -- of course it will be slower -- but not enough to matter, realistically speaking. I assume you mean full-transparency (binary, off/on transparency, e.g. color-key transparency) To give an example, I had a similar RPG engine running long ago on a 66Mhz 486, on a software blitter, with 100 sprites (with transparency) and 1 base layer + 2 layers with transparency, running at 60 frames per second, no problem. Granted that was at 320x200 resolution and 8bit color, but I think 2 orders of magnitude more Megahertz, SIMD, multicore, not to mention hardware graphics acceleration ought to make up for migrating to modern resolutions and color depths

Do be careful that you only draw the region of the map that is on-screen though. No need to draw the whole world when most of it is off-screen.