All my sprites come from

http://www.reinerstileset.4players.de:1059/englisch.htm

The source for Run A War 1.0 is available for download from my site. You are welcome to get it and take a look. Its nicely broken into classes etc.

Basically this isometric view is a TopDown view made to look like an isometric view. Tiles are best when not square but instead are rectanguler (3:2 ratio - 64 * 48 is what I use).

Items in the game are all decendant from a single class. This is then inherited from and more properties and methods added as needed. I use a floating point location system with additional properties to store the rounded off values for quicker accessing.

I typically create a map class that stores the tile to display at each location as well as a list of items. There are in fact two lists stored - one with all the objects added as required (used for doing movement) and a second list with the objects sorted in Y order (used for drawing).

The map controls everything in the game - it does drawing as required and also does movement when required.

My item classes are typically very deep. I start with a Base Item that has all the basic information for drawing and movement. I then split it into movable objects and immovable objects. This speeds up the system for doing movement as the immovabale objects just never have their move method called. Sometimes (like Run-A-War) I then split immovable into two classes based on size. (see below for collision matrix as to why) And then split the movable objects into AI based and input controlled (Run-A-War adds a player level before this split).

I never do collision checking against the sprites. I find this really really slow and the improvement in accuracy is not really worth it. I use a collision array built over the map (ie each rectangular tile on the map is subdevided in memory by 9,12 or 16 smaller squares). Each item in the game that is an obstacle updates the collision array with its passable state and a pointer beck to itself. When an item moves it first deregisters itself from the collision array, moves then reregisters itself again. To check collisions I just check the collision array to see if another item is in that location. (In run a war see how close you can get to the various obstacles - sometimes when an obstacle is not placed exactly right you see to stop 1 or 2 steps away from it - this is because you enter the relevant position in the collision array that thinks the obstacle is in that square). Large obstacles just register themselves with multiple different collsiion array squares. (They can also obviously deregister themselves also). For flying objects just use a 2 (or more) dimensional array to indicate land and air (low medium high...) obstacles.

I've never found nice level changing tiles so I havn't quite got the different hieght look right yet.

Hope this is what you wanted to see. Just ask if there is anything else.