Hexfields instead of square grids (inc. demo src)

charlieg · **Joined:** Wed Oct 08, 2003 2:07 pm **Posts:** 322

Chochmah and I have had a few talks about this.

It lead to Chochmah knocking up a quick hex demo using Irrlicht. You can get the source here. I have not run it myself, as I use Linux and this demo is aimed at Windows. (I haven't tried to get it to run on Linux.)

My interest in using hexfields in a game was originally inspired from Amit's Game programming page. (No, I don't know who Amit is!) In particular, his notes on Sim Blob 2. If you look at the screenshots, you'll see that hexfields allow for a more dynamic, natural looking landscape, whilst retaining an element of simplicity for the player. (Although things are not quite so simple for the programmer!) Also, using hexfields would give Zugspiel at least 6 axis of movement instead of 4 when using square grids.

Anyway, I shall post a more thorough analysis in the coming weeks. It is something that tickled Chochmah but he is rightly apprehensive about going down that path unless it can be shown to be worthwhile with the mathematical complexity it introduces.

ChrisCF · **Posted:** Fri May 28, 2004 2:37 am

charlieg wrote:

Also, using hexfields would give Zugspiel at least 6 axis of movement instead of 4 when using square grids.

I'm sure this discussion has happened before somewhere. You mean 3 and 2 axes, respectively, not 6 and 4. There is such a thing as negative motion along an axis

<funky-vector-speak>The vectors of the two axes on square tiles form a basis on R^2, however those of the three on hexfields do not.

chochmah · **Joined:** Fri Nov 21, 2003 3:03 pm **Posts:** 60

hi
I'm taking the liberty of posting some drawings of tracks in a hexfild enviroment.
Picture one shows a hexfield grid in isoview.

Pivture two shows how simple elevations and tracks might look like

Picture three shows all possible tracks on a hextile (I'm not sure about the yellow tracks, the turns might be to tight)

mnorman · **Posted:** Fri May 28, 2004 12:04 pm

I think the yellow lines are far too tight.
Now the real problem with hex grips, is how do you work out the terrain, especially as there is no way of having a continuous slope across the hex.

charlieg · **Joined:** Wed Oct 08, 2003 2:07 pm **Posts:** 322

ChrisCF wrote:

I'm sure this discussion has happened before somewhere. You mean 3 and 2 axes, respectively, not 6 and 4. There is such a thing as negative motion along an axis

<funky-vector-speak>The vectors of the two axes on square tiles form a basis on R^2, however those of the three on hexfields do not.

No, I mean 6 and 4, you're not including diagonals.

chochmah · **Joined:** Fri Nov 21, 2003 3:03 pm **Posts:** 60

Note: the three vectors do form a basis on R^2. But not a minimal one.

charlieg · **Joined:** Wed Oct 08, 2003 2:07 pm **Posts:** 322

mnorman wrote:

I think the yellow lines are far too tight.

I disagree, but I see where you're coming from. With the red lines, you can easily split a hex in to halves. This is not so easy with the yellow lines.

My thought on this is that, instead of owning a whole hex or half a hex, you own the triangular segments of a hex. To work nicely, you need to break down each hex into 6 triangles, then each of those triangles (equilaterals) can be split down a line of reflection. That's not overly simple, but it means that no particular direction will consume more land than any other.

I'll post diagrams at some point.

mnorman wrote:

Now the real problem with hex grips, is how do you work out the terrain, especially as there is no way of having a continuous slope across the hex.

It's a polygon, of course it can be a flat slope. And as Zugspiel is 3d, it's not limited to any particular slope, so vertices can be offset as needed to make the terrain look good (to avoid spikey ridges).

I completely agree that hex would not work so great if the design was close to that of the original TT(D) games. But that's not a limit that needs to be imposed.

Zuu · **Posted:** Fri May 28, 2004 1:31 pm

Good idea. All games need to have something diffrent from each other. Unique idas gives the game something extra. Since we don't have(what I know) any Hex - TTD-like games, you will nead to think before.

Good Luck!

ChrisCF · **Posted:** Fri May 28, 2004 2:36 pm

charlieg wrote:

No, I mean 6 and 4, you're not including diagonals.

You're not supposed to include diagonals when counting axes. :roll:

Mathworld wrote:

("Vector Space Basis") A vector space V will have many different bases, but there are always the same number of basis vectors in each of them.

The set of two vectors { (0,1) , (1,0) } are a basis in R2, therefore all bases of R2 consist of two vectors, not three. As I said, co-ordinates become a problem, since with three axes in R2 space you cannot project the three unit vectors in a perpendicular manner in Euclidean geometry thus a movement along one axis will result in movement across one of the other two. Have I lost anyone yet?

Since they have an odd number of axes, you find that one field will contain one track in one compass direction, and two in the other. 12-sided tiles would work well for this if not for the minor problem that such regular tiles don't tesselate. Supporting the yellow lines would also work around this problem, and it should be possible to mutually exclude the immediately adjacent red and yellow lines so the tracks don't run too closely. Who's still not lost?

chochmah · **Joined:** Fri Nov 21, 2003 3:03 pm **Posts:** 60

to: Vector space basis
->sorry, I wantet to say three vectors spawn the space. They dont form a Basis.
anyway, lets find a datastructure for the tiles/landscape. I'd like to try out some things.
The Tracks running to close should not be a problem. We just have to make sure the trains dont get to close

The Problem with non discrete hightlevels is that you'll find it extrem diffincult to design a userinterface to edit the landscape. (Sim City 4000)

mnorman · **Posted:** Fri May 28, 2004 4:41 pm

I don't think that Charlieg was talking about non-discrete levels, but about curve transitions slightly displacing the points.
Of course, the idea would be to have the entire playing area as a bezier patch, but I'm sure that that would take too much processing power.

As for my comments about the yellow lines, this was not that they would have any problems within that hex, but that they would cause excessively sharp corners between hexes (a 3-D object suspended between two points on a line cannot follow that line without reversing if the line has a corner in it with an angle greater than 90 degrees, and these would allow 120 degrees. without them the maximum turning angle would be 60 degrees when using the lines on your diagram, which would be far superior.)

As for 6 directions vs 4 direction/8 directions, if the squares are allowed 8 directions then the hexagons have 12 different directions using the same metod for these extra directions as TTD used for the diagonals.

chochmah · **Joined:** Fri Nov 21, 2003 3:03 pm **Posts:** 60

hi, heres a picture of a Flat Shadet Hexfield Map. (The Normals are not calculatet properly)

Lilman424 · **Posted:** Tue Jun 01, 2004 1:11 am

yeah, the bottom is much smoother than the squares....I like it.

eis_os · **Posted:** Tue Jun 01, 2004 7:34 am

Hmm, looks really great, but from the point of view to make it useable for the user I see some problems.

You are talking about good things on hexfields,
if you look at the simblob2 page you see some render problems with it. (they can be solved)

Please make me a good example of landscapeing tool.
If I need a hour to make the landscape fit so I can lay my tracks I will be bored. Thats makes me think about the a good way to lay tracks as simple as possible. Do you know one for hexfields? Some people already find the TTD system complicate.

The square terrain is really nice, if the possible slope height combinations would be somehow reduced, so you don't strungle about height difference when you start laying tracks.

May I ask how a Train Station should look like on a hexgrid?

chochmah · **Joined:** Fri Nov 21, 2003 3:03 pm **Posts:** 60

Quote:

Please make me a good example of landscapeing tool.

Yes... Big Problem... expecially since I want to put on Cliffs later. (gives also problems with the triangle strips).
->Tracks : use textures glued on the terrain so bearing of tiles wont matter. (lthought that might look strange)
->Plattforms and Buildings : Autoslop of the tiles might be the answer... But I suppose I'll have to implement that before I can see how good it is.
I can't think of a good design of a user interface that can handle non discrete high values and slopes. Maybe with a lot of tools... like pick a tile and all tiles you click on will be set to the hight of the original tile. or pick a tile pick a second tile and the tiles between them will form a regualy ascending hillside.

Quote:

The square terrain is really nice, if the possible slope height combinations would be somehow reduced, so you don't strungle about height difference when you start laying tracks.

The square landscape is from zugspiel. I deactivatet the Landscape->makediscrete() if you switch that on you get a TT like terrain with only 1-step highdifferences.

Quote:

May I ask how a Train Station should look like on a hexgrid

I don't think this problem is solvable with a reasonable amount of effort. The Plattorms either have gaps between them or you have to write something that places different kind of plattforms contextsensitiv,

eis_os · **Posted:** Tue Jun 01, 2004 10:47 am

Ohh, cliffs and trianglelist ... I know the problems with it under WinRT, let's see when I get WinRT2s Octree Scenenode working, doesn't look to bad currently...

chochmah · **Joined:** Fri Nov 21, 2003 3:03 pm **Posts:** 60

Another Problem... If cliffs are allowed on every edge between hexfields you have to have three hight values for every point on the triangle grid exept the midpoints of hexfields. (or every corner the hexfields share)
That blows the memory usage a bit... additionaly you should have a bool var that tells if theres a cliff on the corner you currently on.

datastructure so far:

float HFX=37;
float HFY=35;
float trifield[3][256][256]; //triangle field
bool cliff[6][256][256]; // cliffsigns
GLfloat highnorm[256][256][3]; // normals for the triangles

charlieg · **Joined:** Wed Oct 08, 2003 2:07 pm **Posts:** 322

chochmah wrote:

Another Problem... If cliffs are allowed on every edge between hexfields you have to have three hight values for every point on the triangle grid exept the midpoints of hexfields. (or every corner the hexfields share)
That blows the memory usage a bit... additionaly you should have a bool var that tells if theres a cliff on the corner you currently on.

datastructure so far:

float HFX=37;
float HFY=35;
float trifield[3][256][256]; //triangle field
bool cliff[6][256][256]; // cliffsigns
GLfloat highnorm[256][256][3]; // normals for the triangles

Is that for a single hex? That looks like way too much.

ChrisCF · **Posted:** Tue Jun 01, 2004 3:12 pm

Given array dimensions of n*256*256, I'd guess that's not for one tile

chochmah · **Joined:** Fri Nov 21, 2003 3:03 pm **Posts:** 60

Triangle Strips and rendering them in the drawing loop works well and fast, texturing them is a little messy but works ok.
Now... I tryd it with Cliffs and thats completly different. Lots of modulo checks (if (!(i%3))) are required. I suppose thats to slow to be in the drawing loop. Possibility would be prerendering strips from the terrain data and putting the createt strips in some sort of datastructure. But that is complicatet and lots of work.
I'll try no to render all hexfields seperatly with TRIANGLE_FAN and then the cliffs (2 triangles per face) seperaly. I cant say how fast that will be but its significantly less work then the prerendering.
Has somebody any experience with that and can tell me whats best before I waste my time on deathends? thanks

Transport Tycoon Forums

Hexfields instead of square grids (inc. demo src)

Who is online