Squares, Hexes, Octagons...

[PresidentMarcos]

Hmm. But how will topography be handled? Elevation terrain squares? (Civ style) or actual raised squares? (SMAC style)

[LzPrst]

I'd like hexes. About the AC topography I'm uncertain. you cant put in a kilimanjaro like mountain with that can you? a 1 square/hex mountain several thousand meters above the rest of the roundlying area...
How would really steep area be handled? could a tank drive up if it had more than such and such angle? how would defensive bonuses be handled? would it be possible to have like the cliffs of dover, a straigt wall rising right out of the ocean? etc etc. If the topography can be handled better than in AC then I'm all for it.

[Shogun Gunner]

The scale issue always comes back to roost in these type of discussions.

For a large mountain, like Everest, Kilimanjaro, etc. its doubtful any type of forces could get onto the mountain proper. So the fighting would occur in the "foothills" and mountain passes. The defensive bonus, in my mind, really comes from the ability for the defensive troops to concentrate their forces and defend a limited number of corridors.

[DarkCloud]

Hexagons do have their benefits, mostly because they seem to be better able to model real terrain with more directions... and octagons, though unweildly, manage to even better model real terrain!

[Shogun Gunner]

Agreed. More sides the better for modeling terrain. Due to playability, I guess I'm still liking hexagons.

KILL THE SQUARES!!!

[sabrewolf]

DarkCloud, with octagons, you unfortunatly can't create regular tiles... you'd need small squares between. the only things that work are squares (and diamonds), hexagons and.... triangles

[Naokaukodem]

An hexagon would have not 6 general directions, no more than 12, but 18 IMO. Here is a little picture to illustrate this:

[Naokaukodem]

A unit would have to go from a red point to a blue point, then turn by 90° and follow a horizontal line of way. Graphically, curved roads could link red points to horizontal lines/roads for each of the two direction, and for each blue point. Well, there would not be 1 way per side, but 3.

[wrylachlan]

Originally posted by Naokaukodem
A unit would have to go from a red point to a blue point, then turn by 90° and follow a horizontal line of way. Graphically, curved roads could link red points to horizontal lines/roads for each of the two direction, and for each blue point. Well, there would not be 1 way per side, but 3.

But then you're not talking about tiles, you're talking about sub-tile movement, which is a whole different issue. You could just as easily do sub-tile movement with squares.
------------------------------------------------------------------
For my part, whether they go with squares or hexes (hex preferred), I'd like to see movement and defense bonuses based, not on the tile, but the difference between the tiles. So moving from grasslands to mountain is say 3 MP, but going mountain to mountain is only 2. Defending in a forest against an attack from the plains is one thing, but forest to forest is different.

Also, some borders simply can't be crossed. Like say there's a cliff between 2 tiles. No 2 ways about it, you have to go around.

[Naokaukodem]

It not really is sub tile movement, while units movement points are not involved. It is much more a try to determine a "easy" way to use keys in order to move naturally and without too many direction changes. In fact i designed the picture for a spherical map and orientation changes, otherwise they would have only 4 more directions that is 10 total for an immobile map, what IS anyway since the map is stopped in one direction in order to move any unit. (only the upest and the downest blue points are active) Instead of 2 horizontal moves required to move like so, it would require one vertical keyboard move to really move 1 vertically, the unit going from one blue point to another (opposed).

But to say all, since the map is not designed to be spherical, i would prefer the old square system, which i feel is nearly quite perfect, particularly with perspective distorsion. (maybe it would have to be increased?)

[wrylachlan]

Originally posted by Naokaukodem
It not really is sub tile movement, while units movement points are not involved. It is much more a try to determine a "easy" way to use keys in order to move naturally and without too many direction changes. In fact i designed the picture for a spherical map and orientation changes, otherwise they would have only 4 more directions that is 10 total for an immobile map, what IS anyway since the map is stopped in one direction in order to move any unit. (only the upest and the downest blue points are active) Instead of 2 horizontal moves required to move like so, it would require one vertical keyboard move to really move 1 vertically, the unit going from one blue point to another (opposed).

But to say all, since the map is not designed to be spherical, i would prefer the old square system, which i feel is nearly quite perfect, particularly with perspective distorsion. (maybe it would have to be increased?)

No offense, but that whole post was intirely unintelligible to me...

[Naokaukodem]

Originally posted by wrylachlan
No offense, but that whole post was intirely unintelligible to me...

I already heard this... so all my apologies.

By the way there is an explanation here: this is about how to move a unit NATURALLY within a hexagon with a keypad, and how to manage straight roads on such a grid instead of zag zig roads and movements alike.

Keys 789 and 123 would be used as mentionned before, and keys 4 and 6 would allow moves "in the path". I mean it would be impossible to use them from the center of an hexagon as a first move, but not from one of the blue points above. This means that any true move would be done from a red or blue point indifferently (depending on if it is a first move or not), but always end on a blue point. The unit would place itself on the center of an hex once its movement points spent. I'm sure you can understand that, even if my english is pretty ermm broken, randomly. (lack of practice ya know )

[wrylachlan]

Originally posted by Naokaukodem I already heard this... so all my apologies.

By the way there is an explanation here: this is about how to move a unit NATURALLY within a hexagon with a keypad, and how to manage straight roads on such a grid instead of zag zig roads and movements alike.

Keys 789 and 123 would be used as mentionned before, and keys 4 and 6 would allow moves "in the path". I mean it would be impossible to use them from the center of an hexagon as a first move, but not from one of the blue points above. This means that any true move would be done from a red or blue point indifferently (depending on if it is a first move or not), but always end on a blue point.

What you just described is very clearly sub-tile movement. If the Hex is a tile, then moving from the red center of the tile to the blue dot on the edge of the tile is clearly sub-tile movement.

The unit would place itself on the center of an hex once its movement points spent.

But then what's the point? How is making two moves, from the red to the blue, then from a blue to another blue, any different than simply using 1 keystroke to move from the red of one tile to the red of the next??? How is it more efficient?

I'm sure you can understand that, even if my english is pretty ermm broken, randomly. (lack of practice ya know )

At first I thought it might be the english. Now I'm kind of convinced I just think theres a problem with the basic idea...

[Naokaukodem]

Oh ok, no problem.

I just saw in some forum messages that one of the main problems with hexagons would be the way roads would be displayed, and the unatural way one using keys would have to proceed, zig and zag, just to go for example straight left or straight right... I don't know why this idea sticked to me as i rarely use keys to move my units though. Maybe because Civ is far to be a wargame and that the player need to feel free and natural particularly when it comes to explore.

By the way it would not be sub-tile movement I think as the moves would only be blue to blue, without entering the center of a hex during all the move, but stopping at the middle distance from the first edge to the center. Like this it may be more natural so that a baby could play at "hexciv" the same way he plays at civ... if there is not a flaw somewhere.

[sabrewolf]

my favourite arguments:

pro:
+ less graphics needed (6 boundaries have to be considered
+ smoother landforms possible
+ city radius's are equal (not the current "fat plus" shape)
+ same for distance corruption
+ radial stuff generally (plane ranges, artillery, movement) better
+ some of the best stragegy games in the late 80s were based on 6-sided-polygon tiles.

contra:
- civ1, civ2, civ3 based on squares (so probably the killer-argument)
- depending on how you lay the tiles either N-S or E-W are "faster" to move (no zigzag)