He did, but I wanted to know how to go about drawing the sprites, and I wound up learning a bit of the coding side of things too.

And as one of those pixel artists that approves of using limited palettes and following the artistic challenges of creating games on old hardware it was important to me. One of those things most people won't notice or care about, but which would hopefully impress people who know about pixel art.

Thanks guys! Spent most of yesterday figuring this out and I'm posting what I found in the hopes of helping anyone else wondering about these things. I did take a peek into Tactics Ogre: LUCT (the SNES version, not the new fancy PSP one), here's what I found.


Here's normal Tactics Ogre with all the tiles setup perfectly.


Here's Tactics Ogre without the tiles on layer 2. The ground tiles are layer 1, and from what I could see layers 3 and 4 aren't used (except for maybe UI and such, but I can't say for sure as I kept having strange issues where character sprites would appear above the UI, or parts of the UI would disappear. These aren't issues in the game but problems specifically in the way certain emulators handle the rom). These tiles can animate as well. Height (or "Step" in the world of TO:LUCT) are values unique to each tile. Determining units moving across the field is handled simply by a simple equation "beginning step - end step", where if the value is positive the unit can move across and fall about 16 pixels, and if it's negative by 1 the unit will bump up 16 pixels. At -2 and lower the unit will jump based on that particular units jump value (most units cannot jump higher than 2 steps.)


Here's the same image but with the bottom layer taken out. We can see the transparent tiles here. They're actually 16x16 and not 32x32.


Lastly here's all the tiles turned on with a grid added manually by me. So, what we see is that even though the map visually looks to be isometric, it's still a grid, but cleverly disguised as something isometric at the base. The trouble of course is figuring out the math for unit placement and having a good enough engine to help you parse the tiles (it'd be hard to imagine where every tile goes if you're making 2 hash maps, one for layer 1 and one for layer 2.) There's an alternate, cheaper (non-oldschool way) that I think we'll try, however if you want to go hardcore oldschool with it, you might want to have 2 sets of every 16x16 tile you create: one with the hash value of the tile drawn above it and one without. This way you could visually create the map you want to create in whatever program you wish, and then easily follow the numbers to figure out the hash table.

As for doing height you'll probably want a 3rd table for indicating that (and maybe a 4th to determine where the unit is on the X,Y axis.) From there it's simple math to figuring out when, where and how units move and/or jump as well as what tiles are over or under the unit.

UPDATES

Found my old password, so I'm back to Ixis for now! Here's an update keeping the CC in mind.