Jump to content
  • Advertisement


This topic is now archived and is closed to further replies.


Isometric-Hex map + movement...

This topic is 5866 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi there, I am looking in to doing a strategy game as something of a hobby. I am looking at each problem i need to solve seperatley and am currently performing "tech tests" to make sure i can achieve what i want before i get to far in to it. One stage i am looking at at the moment is an isometric-hex map. I have read a lot of the tutorials and white papers on this site (and others) and all seem to go through the same two seperate areas. Either Iso, or hex. But not an Iso-Hex map system combined. 1st off, is a Iso-Hex map possible and what areas do i need to look into. 2ndly, It is the outside edges of these hexes that allow movement, not actually moving through the centre of the tile. and each of the points of the hex are the co-ordinates of items and places. What is the best way to schieve this? I think i will leave it at that for my first post... TIA... Splat

Share this post

Link to post
Share on other sites

2ndly, It is the outside edges of these hexes that allow movement, not actually moving through the centre of the tile.
and each of the points of the hex are the co-ordinates of items and places.
What is the best way to achieve this?

are you asking or saying?
because what allows movement is you taking a character's x and y values and changing them.. moving to and through the center of tiles or not is up to you.
as for achieving it, well:
do you know basic physics?
X is total distance you have to move and x is movement per timeframe t, where
T is the total time to make the move and t is a period of time, over which you want to take a basic step, and maybe change moving frame of the character.
take X=v*t. divide it by t.
you get v, which is x(t), or the distance you have to move each t.
it's the same for moving to and thru the center of tiles, and for free movement. the difference is that in tile-to-tile movement, you set X, x and t (X is each tile-center to the next), and in free movement you set only t, getting a certain X from mouse input, whether directly or calculated for obstacles, and dividing X by t you get x.
also in tile-to-tile you get X from mouse input, but you round it to the center of whatever tile the mouse is over and then set a very big X which is a whole number of X's (number of tiles).
for tile-to-tile movement you can easily keep a matrix of directions and their "x", because each tile has a maximum of 8 surrounding tiles. in free motion you have to calculate these values each time you make a move (and depending on your AI, whenever the character runs into an obstacle )

as for combining Iso and Hex, i'm guessing the reason it's not out there is that nobody can see a good enough reason to do so (and publish it).
considering the fact that when making a game you control the screen and the data, anything relating to that and within logic, is possible. if you draw your hexs right, they will be the width of 1 diamond tile and the height of 2, then possibly rotated 90 degrees CW or CCW.
ok, so it will actually be a rectangle 1 diamond tile wide and 1 tile tall, with the top half of a diamond on top of the rectangle and the bottom half right below it.
you can connect more diamond tiles or vertical/horizontal halves of them to any number of hexagons. you just have to know how to calculate the location of all these things.

but the question remains: why would you want to do this? though it's not much harder taking care of hexs than it is diamonds, it seems like alot of fuss having both.
perhaps you could supply us (me anyway) with an example that makes good use of such a combination. email is also good

Make something idiot proof, and someone will make a better idiot..

[edited by - Demiurge on June 6, 2002 2:40:53 PM]

Share this post

Link to post
Share on other sites
Demiurge, as you said in your post, you can't put a few (square, symetrical) diamonds in a hex, they will be squished diamonds. The layout a diamond grid and an 8 way square grid are fundamentally the same, a hexagonal grid is quite different, and I'd say they are a lot harder.

I don't know if the reasons are good enough for every iso project, (and I haven't done anything with iso), but I know why I'd want a hexagonal system, its because it dramatically cuts down on distortions of movement (measured in units) when compared to a square grid. For example, 15 squares across and 15 squares diagonally are a huge difference. So if numbers of units are important to the game, such as a turn based RPG where distances to bowfire, spells, character movement, etc. are important, a hexagonal system is more sensible. Alternatively, you would have to convert screen coordinates (with their angles) to quantities of movement units. B-Bop, if units of movement are important, consider a hexagonal system. I have no idea how to render a hexagonal system on an isometric angle, and maybe only someone smarter than me would try it But if I were you, I'd learn more about hexagons and try a flat system first, before getting an idea about making it isometric.

[edited by - arctic weasel on June 7, 2002 3:18:34 PM]

[edited by - arctic weasel on June 7, 2002 3:23:36 PM]

Share this post

Link to post
Share on other sites
Thanks for replying...

OK, this is my very first foray into this kind of thing, so i dont have much experience / knowledge to place against some of the decisions i am making, but you learn by your mistakes or from others (which is why i am here).

I am basing this game on a board game. Not very exciting i know, but it seemed a nice basic place to start.

The board is made up of hexes, and some of these hexes have planets/trade ports INSIDE the hex. This will also be a turn based game rather than real-time.

I aksed my question very badly first time round, sorry about that everyone...
What i want is a Hex map but with an isometric viewing angle.
All movement is on the vertices of the hex, only in straight lines and only from point to point of each of the hex faces.

It is quite hard to explain... go to www.mikeward.uk.com and i have a picture of what i am on about.

you both raise good points... it''s good to see another perspective to the same problem.

There is no real mathematical reason for hex''s, that is just the way the board game is laid out, i always thought that the isometic view was basically the angle you were viewing the map? (sheer in-experience showing through here!) and that you could effectivley have any shaped tile as long as it was symetrical for easy lining up...
Like you say Arctic, maybe i should just do the first version with a top-down view...

Share this post

Link to post
Share on other sites
hey, i used to think isometric was that angle too. only when you look it up, or get into wanting to make such a game do you learn otherwise..
it''s just that angle because you can''t make an FPS with no perspective, because something 200 yards away would cover your screen, unless you''re making QuakeIV: Attack of the Mice..

hexs can technically be displayed both as "lying down" and as "standing up", and both should look ok. i think it''s in the look you give your map.
if you make something like CivII and III that fills up your screen like a square, i think it looks less `iso`. but if you make the hexs look like a horizontal diamond: (pretend # is a hex and look at it with your head tilted to either side)


it gives it a better look.
i''d give a picture but i don''t have NEwhere to upload it to. if you can look at TANS''s iso book, then find the picture of 9 diamonds on the left and 9 hexes on the right and turn the book around..
also, putting people and things that look like they''re standing up in a front view will give it a better look.

as for listing items, keep a seperate list (array, linked list whatever) of items that sit in the center of hexs and of items that sit between them.
that way it''s easy to check when you''re moving if you hit a sun or whatever.
if everything can go over the edge of a hex, question is should it also be blocking movement there..

p.s. there was a post a while back about different shaped tiles, in which i posted about trying pentagons for 5 way movement, but i was talking about just aligning up, not symmetry. still, someone said there what shapes could probably be used.. (part about "i posted in" should make it alot easier to find

Make something idiot proof, and someone will make a better idiot..

Share this post

Link to post
Share on other sites
When you say combining Iso and Hex, are you talking about something like this?

or maybe this?

It''s pretty easy to use squashed hexagons. It looks more 3d but they''re really just distorted 2d. The only thing you need to do is change the step in the y-direction in the draw and mouse routines.

As far as movement along hex edges, you can use the same routines for normal hex movement. Just shift the black board hexes over and down by 1/2 hex each way when you do the draw routine, and add some code to the move routine to only give the player 3 directions to travel instead of 6.

FWIW, the only regular polygonal shapes that tile perfectly in 2d are equilateral triangles, squares, and hexes.


Share this post

Link to post
Share on other sites

Bang on correct...

So, where do i learn how to do stuff like that in DirectX8 using VB???
Anyone know...?

I want that perspective with hex''s (only transparent!) with only the outside of the hex''s visible (i want a starfield for the background).

Where can i learn about "change the step in the y-direction in the draw and mouse routines" and the movement items you mentioned?
I know i need to get the basics down first (one step at a time and all that) but i still want as many tutorials as i can get my hands on to give me a better overview of the entire problem at hand.

Like i have already said, this is literally my first week with direct X although i am well versed with VB (thats why i am doing it using VB rather than having to learn a new language as well!)

I have a few books from Amazon on the way (so hopefully that explain the ins & outs of DX8 and some of the above) and i am making S L O W but steady progress on initialising DX and drawing 2D images (just doing the TRIANGLE_LINE, TRIANGLE_LIST, TRIANGLE_FAN stuff at the moment) from the tutorials on Directx4VB.com which are clear and easy to follow (although dont offer full explanations of why certain flags are used) and cross referencing them with the DX8SDK help files and MSDN, (which are not so clear)

Share this post

Link to post
Share on other sites
Those images are not 3d. They are 2d. it just *looks* 3d. The code that drew those images does not use any direct3d. It''s a simple trick, really.

But before getting to the trick, you''ll need to learn how to draw regular shaped hexagons to the screen. There are some good tutorials here on GameDev that can tell you how to do it. Check the Articles and Resources link at the top of the page.

The short version is draw 1 hexagon, then move to the right and draw another one right next to it, all the way across the screen. When you start on the next row, you start off 1/2 of a hexagon to the right, and only 3/4 of a the height down. This lets the second row fit into the angular gaps left by the first row.

All of the tutorials that I have seen assume that the hexes are the same size vertically as they are horizontally. They generally look like:

Where the hex height == hex width.

All I did was take the basic hex shape into a paint program and reduce it vertically. Each hex is 48 pixels wide and either 24 or 32 pixels high (I think, it''s been a while). They are drawn using the same routine as normal hexes (with the caveat that since height != width, the code needs to remember both).

The illusion is improved by the man, who was rendered at an angle consistent with reduced height hexagons. If a normal hexagon is 48 pixels tall and the reduced one is 32 pixels tall, then the view angle is cos-1(32/48) or about 42 degrees, IIRC. So the man was rendered for the first shot at a 42 degree angle.

And so the eye is fooled...

Your second question about leaving the centers empty is trivial for a 2d game. You''ll figure it out once you learn to do transparent blits.


Share this post

Link to post
Share on other sites
Just piping in on this subject, mainly on the "items and units on the corners not the middle" part, because this problem spurred my imagination and I came up with (what i believe to be) a pretty cool solution.

If you can only walk on the corners of a hex grid, you no longer actually have a hex grid. You have a rectangular grid, as shown in the picture above. and in this way you can still consider objects to be at the "center" of the tile. Of course, when they are drawn, they won''t be at the exact center of the tile (slightly above or slightly below instead). The aboveness or belowness has mathematical regularity depending on whether or not the tile is at an odd position or not. odd position yields a 1 in the following equation (x+y)&1. Moving from tile to tile is also pretty simple. from one tile, there are three other tiles to which you can move. the excluded direction also depends on the oddness of the tile. on all tiles you can move east and west. on even tiles you can move south, and on odd tiles you can move north.
if you cannot dispense with the hex grid itself, simply store three pointers to hex tile information within the rectangular grid. each rectangular tile is at the juncture of three hex tiles.

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!