next »

[Ixis]

I'm working on a game (big surprise), and it's an iso Tactics Ogre/FFT:A style strategy RPG.

I've been looking around for some tutorials on how iso tiling goes (I know about type B, 2:1 and how to draw them) but I need help figuring out how to tell my programmer how to setup the program to put these tiles together.

So would my actual tiles (the ones the program uses to put together a map) be rectangular or is there a simple way to do it in squares? Should the tiles be actual 32x32 blocks that are put together like a lego set? Or should I make a big final iso image like the one below, but broken into layers based on buildings/walls/etc?



I know how to put down pixels but having a program parse those into something that works is hopelessly confusing to me. I feel like there's a trick here, but I might be wrong.

[Tiderion]

Are you trying to get an algorithm to randomly generate maps?

It would seem to me that if you are generating maps for a tactics game then the tiles would need to be made 3-dimensionally and you need to create an editor that allows you to stack the tiles on top of the generic field. FF:Tactics was designed to have a 3D field that stuff is piled on top of which can then only be seen from a select number of views.

[Ixis]

FFT was actually 3d though, this is a 2d game. In FFT the goal was to use the PSXs graphics to emulate the iso tiles of games like Tactics Ogre (it was made by the same team, in fact.)

In essence I'm asking about how a 2d editor would parse the data for maps in this way, while also keeping track of unit placement, and allowing for a synthetic limited perspective wherein units appear behind objects that would logically be in front of them relative to the camera (at a fixed place.) I've been finding some tutorials with algorithms and tables and stuff, but they're all old and reference image files that no longer exist, lol.

[AndyKorth]

Isometric tile systems are fairly hard to program, imo. I've done square, top-down systems and 3D games, and I find that either one is a lot easier than a isometric tile system.

As for your question about how to store the data, I just decide that the bottom corner of the map is 0,0 and moving up and to the right increases x, while moving up and to the left increases the y coordinate. u

The tile images are probably best off in their diamond shape filled into a square grid. Make the area around the tile transparent so when your code draws the entire tile, it can be drawn over other tiles. In the reference image, you've got barrels and crates that have more "height" to them than a flat tile of grass.

The reference image also adds varied height... that just adds another degree of complexity, but it's just something you will need to keep in mind. Those houses are modular, so they were certainly pieces together...It looks like there are a lot of different individual pieces in that tile set, but I'm not 100% sure how the buildings are broken up.

If you need help translating coordinates from an isometric space to screenspace for drawing, I do have sample code I can share... But I'm at GDC right now and it's not with me. Someone would have to remind me.

I don't want to be discouraging, but iso tilesets are a huge pain in the butt. I do think they look great though.

[Ixis]

Thanks! Actually my programmer and I worked out a way of doing it similar to what you suggested!. The varying heights aren't so bad as every tile will have a visual height value (created in photoshop) and a height hash value the program can parse into determining how it interacts with the player (starting height - end height = vertical movement where positive values cause the player to drop X steps and negative values up to 2 steps require a hop, save specific classes/abilities.) Barrels, bushes and buildings are treated as static units that don't move and aren't selectable. A building you can stand on will of course be made in photoshop and broken up into pieces.

[AndyKorth]

Sounds like you've got it under control!

[eclectocrat]

I've already gone through the whole process on my game. It kind of sucks. Start with a basic flat isometric engine. The drawing order code will work on a isometric + Z coord game just fine. Once your flat engine is done, you've got to add a Z coordinate, which is projected onto the screen Y coord. Drawing it is not all that tough, you've already got the gist of it down. Every 'tile' including objects like house pieces, has a 'depth'. When drawing a character on top of that object, you start with the base coordinates for that tile with a level of 0, and then translate the Y coord by the depth.

Point p = tilePoint;
Point screen(
        (p.x - p.y) * (_tilesize.w/2),
        (p.x + p.y) * (_tilesize.h/2));
screen.y -= depth; // upper-left corner origin.

The 'screen' coord now has the point you need to draw your object at.

Good luck! The world needs more tactics games!

[Ixis]

Thanks eclectocrat, I'll try that out and see how it goes!

@AndyKorth: Yep, after I figured everything out I made a post explaining how to go about doing iso tactics games in a SNES style on Pixelation, but I'll repost my findings here too in case someone needs to know how to do this in the future so they don't wind up hopelessly lost like I did.

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. :D


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.