Archived

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

Isometric-Hex map + movement...

This topic is 5652 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
quote:

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

//Demiurge
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

//Demiurge
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.

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

JSwing

Share this post


Link to post
Share on other sites
THATS IT!!!

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.

HTH,
JSwing

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
Tanstaafl. Impressive.
^ Darth Vader voice.

The only problem is, if B-Bop is going to store stuff inside his hexagons, and if he''s using non-distorted real hexagons, you are back to a hexagonal grid, and now you have 2 paradigms.
I guess you could still use your rectangles, and store things inside the hexagons using a 12 coordinate system, x, and y for each of the six rectanges surrounding the center of each hexagon. For distorted hexagons, this is good. For exact hexagons, to accurately interact with everything, you''d need to use the hexagonal grid coordinates using the six directions.

Share this post


Link to post
Share on other sites

Now then, these are interesting ideas...

Thanks TANSTAAFL...
I like the rectangle thingies for movement rules, etc...

I have also had an idea... a sort of follow on to yours.

Instead of using Rects, why not use Triangles?
go to www.mikeward.uk.com to see what i am on about.
That way each "point" of a triangle is exactly in the centre of a hex and the centre of the triangle is exactly on a hex point...

So, items (inside a hex) are stored on the "points" of the triangle and movement is from the centre of 1 triangle to the centre of another...
(i hope that makes sense...?)
What do you hardened veterans think???????????

Anyway... DirectX8 is bashing my skull still but i am getting there.

I have decided to go for a 3D environment with a 2D hex map floating in space... If i fix the viewing camera at 42degrees then it should "simulate" an Iso-Hex view due to the fact that DX8 will auto scale items using distance and LOD rules. (please feel free to correct me if i am wrong...)

Then i will use sprites for the stuff that is moving about, and 3D object for planets and other immoveable objects.

Share this post


Link to post
Share on other sites
O, and by the way.

How the hell do you get pictures into your posts... i have tried several times to get them in here and i just cant get it to work?

Share this post


Link to post
Share on other sites
B-Bop, using triangles wouldn''t make it easier for your distorted hexagons, or if it does, you are smarter than me. A small accomplishment
I''ve used triangles to help me draw true hexagons quickly (www.kustompaper.com) especially because you can use right triangle geometry.

Haha, I am beating a dead horse here with my posts, sorry I''ll give it a rest. I guess the point I''m trying to make is this, you must know when you are switching between:
1. a two coordinate system with distorted hexagons
2. a three coordinate system with true hexagons
Trust me, it''s important.

Share this post


Link to post
Share on other sites
quote:
Original post by B-Bop
Instead of using Rects, why not use Triangles?
go to www.mikeward.uk.com to see what i am on about.
That way each "point" of a triangle is exactly in the centre of a hex and the centre of the triangle is exactly on a hex point...

So, items (inside a hex) are stored on the "points" of the triangle and movement is from the centre of 1 triangle to the centre of another...
(i hope that makes sense...?)
What do you hardened veterans think???????????



using triangles is essentially equivalent to using a rectangular grid and storing three pointers to the hex tiles. in addition, rectangles are much easier to work with mathematically than triangles, rhombusses, parallelograms, trapezoids, hexagons, irregular pentagons, or any other geometric shape provided you are using a cartesian coordinate system (which you are).

quote:
Original post by B-Bop
I have decided to go for a 3D environment with a 2D hex map floating in space... If i fix the viewing camera at 42degrees then it should "simulate" an Iso-Hex view due to the fact that DX8 will auto scale items using distance and LOD rules. (please feel free to correct me if i am wrong...)
Then i will use sprites for the stuff that is moving about, and 3D object for planets and other immoveable objects.



D3D does NOT auto scale items. The D3D functions for helping create matrices create matrices that do so, yes. so don''t use them. construct your own matrices.

since you seem to be having a struggle with D3D, I''m going to provide here a brief refresher on what matrices in D3D ACTUALLY do for you (which is not exactly the same as what they are INTENDED to do for you)

in a typical vertex transformation pipeline, each vertex goes through three matrices, world->view->projection. what a matrix really is happens to be a set of four linear equations helpful in transforming points. the equations look like this:

x2=a*x1+b*y1+c*z1+d*w1
y2=e*x1+f*y1+g*z1+h*w1
z2=i*x1+j*y1+k*z1+l*w1
w2=m*x1+n*y1+o*z1+p*w1

as far as the matrix is concerned, it looks like this(at least in d3d):

a e i m
b f j n
c g k o
d h l p

in an orthographic (non-perspective corrected) projection, which is what i believe you want, w always should stay 1 unless you want to use it for zooming, and that case only affects the projection matrix. so, most of the time, m,n,and o are 0(zero), and p is 1.

since at the end of the pipeline you are in cube space (with -1<=x<=1, -1<=y<=1, and 0<=z<=1 being the only items that will be shown), your task is simply to come up with equations that will give you those sorts of numbers for that which you want to view. typically I do this by setting up a projection matrix that transforms coordinates as though they were being projected onto a 640x480 screen, with (0,0) still in the middle but with greater y values towards the bottom of the screen(just like in standard 2d).

I also determine an arbitrary range for my z values, also in "pixels". if you don''t have really high peaks or really low valleys(or extremely tall items to place on the map), a -128 to +128 should be sufficient. if you don''t have anything lower than the map itself, you can chop it off at 0.0 for the lower end. the lower the z value, the farther away (i.e. the higher the value place onto the z buffer).

so, with this sort of scheme, you might say that your projection matrix takes coordinates from (-SCREEN_WIDTH/2,-SCREEN_HEIGHT/2)(the upper left corner) to (+SCREEN_WIDTH/2,+SCREEN_HEIGHT/2)(the lower right corner), with z values anywhere from -128 to +128.

setting up equations for this is not difficult. you start with the x equation, then do the y equation, then the z.

for the x equation, -SCREEN_WIDTH/2 maps to -1, and +SCREEN_WIDTH/2 maps to 1, so the x equation is simply:

x2=(2/SCREEN_WIDTH)*x1+0*y1+0*z1+0*w1

for the y equation, this is much the same, except that we are flipping the coordinate system upside down, so must multiply by -1.

y2=0*x1+(-2/SCREEN_HEIGHT)*y1+0*z1+0*w1

for the z coordinate, which in the end should wind up between 0 and 1 and starts out at -128(which maps to 1) to +128(which maps to 0), we again must invert by multiplying by -1, divide by 256, and add 0.5. it winds up looking like this:

z2=0*x1+0*y1+(-1/256)*z1+0.5*w1

since w is 1 throughout, 0.5 times w will give us the slight offset we need to make this sort of thing work.

from here, you just keep working backwards. you can even use 3d models in this scheme, provided you orient them so that their "feet" or whatever are at 0,0,0, and z points downwards(or just construct a matrix that will rotate them so that this is so).

Share this post


Link to post
Share on other sites