Strategic Games Mapping

[Big Dave]

Mark,
I have noticed that most games are going for square spaces on the maps. I understand that hexagons are alot of overhead for the CPU, and I've even heard that some companies prefer to avoid them because they're afraid that hexes will scare off "non-wargamers" or some such silliness.

What I'd like to know is, have you considered offset squares for your maps? This eliminates the .41 movement bonus for moving diagonally, and makes calculating distances (e.g. distance from a provincial capitol) easier.
Thanks for listening,

Big Dave

[Mark_Everson]

Hi Big Dave:

Yep, we've considered offset squares and rejected them as unnecessary. We're going to go with semi-realistic movement costs, so moving along a diagonal will cost 1.4x as many movement points as along an edge. To support this and for other reasons, Clash is probably also going to keep track of where a task force (TF) is within a square. This issue has come up b4 and been discussed. I couldn't find it quickly, and didn't want to take much time since i'm at work . You can probably find the previous thread(s) with a little searching of the forum if you care to. There is certainly some discussion in Druid's main military model writeup (Mil I, not II) which you can find in the status thread.

-Mark

[Big Dave]

Thanks for the reply Mark. Just one more thought before I go look for those other threads.

Offset squares would make it easier for the players then, since you're already taking the actual distance into account with the game engine.

Again, thanks for the courtesy of a reply on an issue you'd already dealt with.

Big Dave

[DaVinci]

Okay, after having looked over the threads on this item and having done a little playing in paintshop and photoshop, what I've come to conclude is that if done correctly, an isometric (diamond shaped grid) is just a cleverly hidden hex map. Of course, this requires some creative mapping techniques, and disallowing movement in one direction across the diamonds.

For example:



In this format, side to side movement across diamond vertices would be disallowed or cost 2x movement for any other direction. But along the sides and the vertical vertices, you would easily pay 1x movement. This would allow for more accurate movement costs and remove the necessity for having complicated 1.4x calculations and such which would be counter-intuitive for users, and slow down their ability to quickly play a turn. (always such a hassle to go hunt up those calculators to determine how far your phalanx can move)

Also, if the terrain chip makers and programmers bang heads long enough, you can come up with some very flexible means of producing the graphics for your terrain using this system.

I'll work on coming up with some examples here as time permits.

-DaVinci
--Show me a planet, and I'll show you a hex map waiting to happen.

[DaVinci]

moving this back here from the graphics board to keep it where it belongs:

Originally posted by Mark_Everson on 10-20-1999 10:09 PM

On the diamond-hexagon thing, I don't think you're right. The symmetry groups for hexagonal tiling and square tiling are just Different IMO and there's no way around it. Your proposed trick of simulating hexagons by not allowing diagonal movement then replaces a distance of 1.4L with 2L since to move diagonally you need to cross two edges rather than just take the direct route. Or perhaps I'm taking your implications too far .

---

Actually, you're not taking them quite far enough..

if you look at the graphical post that I put on the strategic mapping thread, a diamond tile scheme is already 'simulating' a hex map. If you take apart the lines and break down the 'areas' of the map into a pattern of circles, you .have. a hex grid. The diamond pattern is just the shape chosen to represent those 'areas' on a meshed grid. An isometric-diamond pattern and a hex map have an 'area-zone' pattern that are identical, the only difference is the shape chosen to represent those areas. And yes, I'm saying very much that the horizontal movement should be disallowed alltogether actually. If you merely 'charge' the unit 2x movement cost, you could in theory allow them to move through intervening rough terrain for a cheaper cost than necessary.

This removes the 'single line of mountains' problem. Using the corner movement allowance of a diamond map, a unit can circumvent a thin row of mountains by myseteriously crossing from one plains tile to another plains tile without having to be charged any extra cost for the mountains that they avoid. By treating the iso-grid as a hex grid, you avoid this 'corner cutting' to bypass difficult terrain.

Oh, and programmatically, there should be virtually no difference between using actual hexes instead of diamons in map generation. If you look at a diamon grid, each diamond is by definition 1/2 empty space that must be alpha channeled to the adjoining 4 tiles. In the case of a Hex grid, you reduce that to about 1/6 of the tile is area that must be alpha'd to those 4 tiles. That should actually, in theory, cut down on the amount of CPU overhead required. (being more of a theorist and artist, rather than a programmer, I could be totally wrong, however) By using actual hexes, we might be raising our tile count overhead some, but I think the benefits in detail on the map and in movement would be worth it.

Also, by using true hexes as opposed to diamonds, you remove the problems inherent in moving across verticies from land to land crossing water. There will be no question as to whether or not two land areas are connected by a land bridge when they appear as though they should, or aren't connect when they appear to be. By removing the vertice ambiguity, we raise the level of detail and cleanliness of the map alltogether.

------------------
-DaVinci
--Show me a planet, and I'll show you a hex map waiting to happen.

[This message has been edited by DaVinci (edited October 21, 1999).]

[Glak]

so?
Mark doesn't want a hex map

You are just arguing for a hex map that doesn't look like one. If the game is going to have a hex map it ought to at least look like one. I doubt that anyone would want ao play on a grid map that plays like a hex map. It just wouldn't feel right.

[DaVinci]

Actually, what I'm saying is that he's already .got. a hex map, he just doesn't know it yet.

By my reading, this project was born of a desire to correct errors seen in previous games. I've always found this one particular thing to be one of the areas that I didn't like in previous games. An isometric grid, when the lines are removed and the 'area of effect' is looked at, is really a hex grid already. It's all a matter of perspective. I understand that the design team doesn't want a hexgrid, but since an iso-grid practically is one. Why not forego the complications of fractional movement allotments and charges and just use the system to it's fullest extent possible? All you've done by using an isogrid is taken a hex map, straightened out the grid lines, added an element of error, and reduced the clarity of the situation. All the while, forcing yourself into fractional calculations of movement to allow for vertice movement that isn't an issue otherwise.

Besides, I don't believe in anything being set in stone forever. If you really wanted to get sick, remove tile allotment/movement altogether and use a decimal latitude/longitude algorythm for troop movement and location. Though that might get a .little. complicated.

Regardless. The sample tiles I'm working on are going to be the 94x48 iso tiles anyway as I recognize that this is likely what's going to be used. However, I'm also going to work up a samples of both the diamond-hex system and a true hex system. Just because I'm stubborn that way.

------------------
-DaVinci
--Show me a planet, and I'll show you a hex map waiting to happen.

[Paul Crocker]

Da Vinci: I think you bring up some good points (FE the cutting corners to avoid tough terrain), but we should probably be careful that we don't complicate things in the process. One thing in particular that I'm thinking of is how we display the map. I prefer maps that fairly clearly distinguish between hexes (grids, tiles or whatever shape they may be). Some of the terrain in Civ II really irritated me, because it was sometimes difficult to tell where one cell began and another ended without toggling on the horrid grid cell indicator. "Harder" edges between terrain types may alleviate this problem somewhat - I'm not talking about an obnoxiously discrete edge, but not completely vague either.

My point: Your method of "hiding" the hexes as a grid may just compound this problem (unless I'm missing something in your proposal). Maybe you could address my concern if I'm off base here...

[Big Dave]

I think that DaVinci's point is that since Mark seems unwilling (at this point) to change to an actual hex grid that one could be simulated with his existing grid setup. The only thing I don't like about DaVinci's idea is that being able to move accross one vertex (verticle) but not the other one (horizontal) is very counter intuitive to the player. The hex grid is my prefered choice, offset squares is my next preference, and DaVinci's proposal is a compromise that I'd be willing to accept. Isometric diamonds is (yawn) passe, it's been done, it has known shortcomings. You're attempting to break the rules to make something new and wonderful, why not go with something that we know works well(hexes) rather than stick with the tried and tired?

Big Dave

[Kull]

In one sentence, here's what DaVinci is saying:

If you use the isometric grid AND ALSO prohibit lateral motion (i.e. movement in the 90 and 180 degree directions), the end result is a "virtual" hexagon.

It DOES seem a lot more intuitive than factoring lateral movement. His grid is used simply to indicate that lateral movement from one diamond to another is REALLY "two" spaces, not "1.4".

[DaVinci]

Originally posted by Paul Crocker on 10-21-1999 06:03 PM


My point: Your method of "hiding" the hexes as a grid may just compound this problem (unless I'm missing something in your proposal). Maybe you could address my concern if I'm off base here...

Good Point!

Actually what I had meant to get across was hiding a grid as hexes, not the other way around. Use the diamond arrangement, but build the tiles so that they appear and are used as hexes, not as diamonds. This removes vertice movement abiguity and cost caculations as you're always moving across an edge instead of a vertice. The programming take on it should be identical, and the learning curve small. Sorry I didn't make this clearer.

I think what I've been trying to say, to sum up: An isometric diamond grid is a poor man's alternative to hexes.

The pattern of map coverage is identical, the programming aspect .should. be identical as far as laying the tiles on the screen. The Vertical offset hex map has the advantage of being the choice of wargamers for decades, an intuitive system of movement costs, and removes all ambiguity as far as movement across verticies goes. Graphical tile production may be a small bit more intensive, but shouldn't be troublesome.

Though, when it comes right down to it, I don't see this thread actually causing such a change. It was simply an idea that I tossed into the fire. There is, however, nothing that says that we have to stick with an isometric grid or that we can't draw the diamonds so that they 'appear' to be hexes. At which point we nix the horizontal movement and we have a hex map... Just things ta think about.

------------------
-DaVinci
--Show me a planet, and I'll show you a hex map waiting to happen.

[Mark_Everson]

I think there's a problem in this discussion where there's confusion between how things look in isometric perspective, versus the 'real' footprints on the ground (looking from directly above).

The Hexagonal overlay works for the way the map Looks. But the terrain on the ground is Supposed to be Squares. What DaVinci says is Only True of diamonds with one particular aspect ratio. What the diagram shows as regular hexagons would actually be Distorted hexagons on the ground when you remove the perspective from the isometric viewpoint.

A regular square grid (unless you shift alternate rows as Big Dave suggests) just plain doesn't map to hexagons. That is unless you do strange things like shifting rows, or dropping some squares.

To use Kull's terms, as You Look At It the long dimension of the diamonds is twice the short. But that is Simply Perspective! The diamonds are supposed to represent squares where the diagonals are of Equal Length.

I think hexagons are generally good, and have all the benefits you attribute to them. I played a lot of games based on them in olden days. But we have a non-negligible amount of effort already invested in squares.

You can blame me for that

However, two design features we're already going to do cancel the most onerous aspects of squares. We are going to:

1) with semi-realistic movement costs, so moving along a diagonal will cost 1.4x as many movement points as along an edge.

2) (probably) keep track of where a task force (TF) is within a square.

So my personal judgement and tastes say that we don't need to bag a bunch of already-done work for some moderate improvement in reality.

That said, I believe in the basic good judgement of the whole group. If a preponderance of team members support the change to hexes despite its cost, I'll go along with it

My guess on the cost in lost work to change over is probably at least a 100 hours or so. But I admit its just a crude guess.

-Mark

[korn469]

after playing the demo i would opt for a more realistic hex bases map...it seems that you guys have opted for alot of realism your game so my opinion is that hexes make a perfect fit for clash but that's just me

korn469

[Krenske]

Hello
Only my second post for the forum and first for the topic.

Da Vincis diamonds turned 45 degrees to the square works out "like" vertical offset squares and therefore like hexes, but it looks odd and appears counter intuitive, it would be better to just go with hexagons from the start.

Hexagons do give a more obvious circular horizon effect when exploring and in setting areas around cities etc. They would also simplify movement by eliminating the 1.4 move cost for the diagonal and will probably allow the removal of tracking position within squares.

As a graphical bonus they can be used to improve graphical representation and need not look like Hexes. If the graphical parts are the 6 equalateral triangles that make up a hex while the logical movement part is the hex. The triangles can be used in creating a 3D map by increasing the number of elevation points while still allowing hexagonal movement etc.

I probably need to describe that better. Each hex is made up of 6 triangles, each point of each triangle can represent an elevation point, this can be used to create a more topographical map. I hope that is a better description. Of course that factor is only relevant if 3d maps are used.

The triangles could of course be used in representing graphical subpart of a hex even if 3d is not used. A partially wooded hex could be created by having 2-3 of the triangles in the hex display trees. As deforestation occurs, gradually reduce the number of triangles with trees. This will have the hexes slowly change as improvement are made as opposed to the current "bang" one minute the hex/square is a forest next moment it is plains. This could even be used in determining production from the hex by playing mix and match with the constituent triangles.

Just my graphical ideas on hexes. Most people already understand the movement based ideas.

[This message has been edited by Krenske (edited October 26, 1999).]

[korn469]

great idea Krenske! the six triangles would really make the map look nice and we would have the simplicity of hex based movement

i also feel that diamonds are clumsy and hexes are better

korn469