Hex Tiles

#1 1. A hex is convex.
2. True. You would need to implement this yourself.

#2 You could just use two overlapping tile maps/layers, offset the second layer and use alternate tile
positions.

Create a script object to manage if for you which should make it quite painless to work with.
e.g.

function HexMap::setTile( %this, %x, %y, %tileImageMap, %frame )
{
      if( isOddTile( %x, %y ) )
             %this.tileLayer1.setStaticTile( %x, %y, %tileImageMap, %frame );
      else
             %this.tileLayer0.setStaticTile( %x, %y, %tileImageMap, %frame );
}

etc...

#3 Anyone have an example using Hex Tiles?

Thanks,
Sammual

#4 I'm not familiar w/ the tile editor in TGB,
so maybe this won't be helpful,
but you do know that you can make a hexagonal grid out of a single rectangular tile ?

#5 That is what I am doing to get the Grid itself when I need it but when each tile can be a different terrain type with different graphics and when you want to move from one hex to another it is a pain.

I am attempting to not re-create the wheel. I am sure that someone has used TGB to make hex 'objects'. I just hope they will let me learn from what they have done.

Sammual

#6 Roger that.

#7 I don't have any code that's really ideal for demo purposes but you can see my post here that talks about how we setup the tiles in the editor. It's really very simple math once I worked out which "whole pixel" values worked well (which are mentioned in the post). garagegames.com/mg/forums/result.thread.php?qt=46757

If I was doing a full on "Terrain" type setup like what you mentioned, I would simply use the tile editor for setting up the custom data for which tile to use and then have a routine that placed the actual hex image sprite at each tile location depending on what was in the custom data for the tile.

Hope it helps. Scream if you need help working out any of the math as I still have my notes and such if you have a specific issue. Good luck!

#8 I took a minute to look have a look at it and here's what I've come up with:



Basically you have a single column tile map for each column of the map offset so they fit snugly. So you really still have a normal 2D map thats intuitive to work with.

#9 I like it. It may not be quite as simple to code against for things like figuring out movement/path finding but it's certainly simple and you certainly do get better in-editor support if that's important to you.
Seriously, someone should spend the couple hours putting together a resource for handling offsets for rows/columns in the tile system/editor or allow brushes larger than the tile and then we'd be done with it :)
I can't tell you how long I spent coming up with "the perfect size" so that the brushes/imagemaps would come out as whole pixels... oh well, next time I need a hex system I'll know better :)
-Andrew

#10 Why would it not be simple to code against for things like movement/path finding? You abstract it all into a HexMap script class and it handles the simple lookup by column internally. Simple as pie.

As for offsets, it should be straight forward to add (I did it before on the older code when I started faffing with iso stuff in about 15 minutes).


Btw. the iso builder I am working on will have hex maps too ;p

#11 Sweet! Iso-hex maps made my head hurt. I'm really looking forward to it. When's it coming out again? :)
The HexMap abstraction is fine and it's not "difficult" exactly, but it'd be nice to work directly off a single tilemap so that you didn't have to write an abstraction that was doing the skipping between tilemaps for you.

#12 I'll be posting a blog sometime this week with progress updates (and some sweet new functionality!) so keep an eye out for it.