Hexfields instead of square grids (inc. demo src)

A 3D game in the spirit of Transport Tycoon. Click here for the web site.
User avatar
charlieg
Transport Coordinator
Transport Coordinator
Posts: 323
Joined: 08 Oct 2003 14:07
Contact:

Hexfields instead of square grids (inc. demo src)

Post by charlieg » 28 May 2004 00:27

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.
Open source tycoon games
--
Free Gamer - open source and Free Software games
FreeGameDev forums - open source game development community

ChrisCF
Transport Empire Developer
Transport Empire Developer
Posts: 3608
Joined: 26 Dec 2002 16:39
Location: Over there --->

Re: Hexfields instead of square grids (inc. demo src)

Post by ChrisCF » 28 May 2004 02:37

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.
Bugzilla available for use - PM for details.

chochmah
Engineer
Engineer
Posts: 60
Joined: 21 Nov 2003 15:03
Contact:

how do they look

Post by chochmah » 28 May 2004 11:58

hi
I'm taking the liberty of posting some drawings of tracks in a hexfild enviroment.
Picture one shows a hexfield grid in isoview.
Image
Pivture two shows how simple elevations and tracks might look like
Image
Picture three shows all possible tracks on a hextile (I'm not sure about the yellow tracks, the turns might be to tight)
Image

mnorman
Chief Executive
Chief Executive
Posts: 655
Joined: 03 Dec 2003 07:35
Location: Cambridge, England

Post by mnorman » 28 May 2004 12:04

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.

User avatar
charlieg
Transport Coordinator
Transport Coordinator
Posts: 323
Joined: 08 Oct 2003 14:07
Contact:

Re: Hexfields instead of square grids (inc. demo src)

Post by charlieg » 28 May 2004 12:58

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.
Open source tycoon games
--
Free Gamer - open source and Free Software games
FreeGameDev forums - open source game development community

chochmah
Engineer
Engineer
Posts: 60
Joined: 21 Nov 2003 15:03
Contact:

Post by chochmah » 28 May 2004 13:11

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

User avatar
charlieg
Transport Coordinator
Transport Coordinator
Posts: 323
Joined: 08 Oct 2003 14:07
Contact:

Post by charlieg » 28 May 2004 13:17

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.
Open source tycoon games
--
Free Gamer - open source and Free Software games
FreeGameDev forums - open source game development community

User avatar
Zuu
OpenTTD Developer
OpenTTD Developer
Posts: 4553
Joined: 09 Jun 2003 18:21
Location: /home/sweden

Post by Zuu » 28 May 2004 13:31

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!
My OpenTTD contributions (AIs, Game Scripts, patches, OpenTTD Auto Updater, and some sprites)
Junctioneer (a traffic intersection simulator)

ChrisCF
Transport Empire Developer
Transport Empire Developer
Posts: 3608
Joined: 26 Dec 2002 16:39
Location: Over there --->

Re: Hexfields instead of square grids (inc. demo src)

Post by ChrisCF » 28 May 2004 14:36

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
Engineer
Engineer
Posts: 60
Joined: 21 Nov 2003 15:03
Contact:

Post by chochmah » 28 May 2004 15:31

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
Chief Executive
Chief Executive
Posts: 655
Joined: 03 Dec 2003 07:35
Location: Cambridge, England

Post by mnorman » 28 May 2004 16:41

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
Engineer
Engineer
Posts: 60
Joined: 21 Nov 2003 15:03
Contact:

Flat Shading Hexfield Map

Post by chochmah » 31 May 2004 23:51

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

User avatar
Lilman424
Tycoon
Tycoon
Posts: 2743
Joined: 20 Oct 2002 14:55
Location: Georgia
Contact:

Post by Lilman424 » 01 Jun 2004 01:11

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

User avatar
eis_os
TTDPatch Developer
TTDPatch Developer
Posts: 3602
Joined: 07 Mar 2003 13:10
Location: Germany
Contact:

Post by eis_os » 01 Jun 2004 07:34

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?
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...
Image

chochmah
Engineer
Engineer
Posts: 60
Joined: 21 Nov 2003 15:03
Contact:

Post by chochmah » 01 Jun 2004 10:35

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.
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.
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,

User avatar
eis_os
TTDPatch Developer
TTDPatch Developer
Posts: 3602
Joined: 07 Mar 2003 13:10
Location: Germany
Contact:

Post by eis_os » 01 Jun 2004 10:47

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...
TTDPatch dev in retirement ... Search a grf, try Grf Crawler 0.9 - now with even faster details view and new features...
Image

chochmah
Engineer
Engineer
Posts: 60
Joined: 21 Nov 2003 15:03
Contact:

Cliffs

Post by chochmah » 01 Jun 2004 11:36

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

User avatar
charlieg
Transport Coordinator
Transport Coordinator
Posts: 323
Joined: 08 Oct 2003 14:07
Contact:

Re: Cliffs

Post by charlieg » 01 Jun 2004 13:03

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.
Open source tycoon games
--
Free Gamer - open source and Free Software games
FreeGameDev forums - open source game development community

ChrisCF
Transport Empire Developer
Transport Empire Developer
Posts: 3608
Joined: 26 Dec 2002 16:39
Location: Over there --->

Post by ChrisCF » 01 Jun 2004 15:12

Given array dimensions of n*256*256, I'd guess that's not for one tile ;)
Bugzilla available for use - PM for details.

chochmah
Engineer
Engineer
Posts: 60
Joined: 21 Nov 2003 15:03
Contact:

Triangle Strips, fans

Post by chochmah » 01 Jun 2004 18:15

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

Post Reply

Return to “Zugspiel”

Who is online

Users browsing this forum: No registered users and 2 guests