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)

[Naokaukodem]

Originally posted by sabrewolf
- depending on how you lay the tiles either N-S or E-W are "faster" to move (no zigzag)

And I say that what you say would become:

Originally posted by 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)

if you place the units in in either the N/S (or E/W) part of a tile only while moving it so that you could use left and right (or up and down) keys.

[sabrewolf]

yeah, but then it's again subtile movement as was discussed above...

following form for tiles seems most "natural".

 __
/  \
\__/

N-S-movement would be faster and easier than E-W in this case... but that actually makes sence. our world is approx. 20'000km from N-pole to S-pole, but 40'000km around the equator (logical: one is full, the other is a half circumference)

[DarkCloud]

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

Couldn't you tilt and bend the octagons and sort of distort them a little (especially if the game models hills and mountains like in Alpha Centauri with height) ?

[sabrewolf]

i can't picture how you mean that. can you draw a sketch or use the code-tag (see my post above) to use ascii art?

[wrylachlan]

Originally posted by DarkCloud

Couldn't you tilt and bend the octagons and sort of distort them a little (especially if the game models hills and mountains like in Alpha Centauri with height) ?

No. It's physically impossible to use octagons as a regular tile.

[Krum]

I don't see any advantages for squares over hexes.

Hey, look what I found:

http://c2.com/cgi/wiki?HexGridDisk

also check out the links at the bottom for more on a sphere for a civ-type game.

[Leland]

Originally posted by DarkCloud

Couldn't you tilt and bend the octagons and sort of distort them a little (especially if the game models hills and mountains like in Alpha Centauri with height) ?

You'd have to distort the entire map geometry and then project that to 2D. This is theoretically possible but the distortions would be ludicruously big. Imagine a globe where one tile occupies as much space as all the other tiles combined and you get the idea.

[Naokaukodem]

Originally posted by Leland
a globe where one tile occupies as much space as all the other tiles combined and you get the idea.

Nice

Originally posted by sabrewolf
yeah, but then it's again subtile movement as was discussed above...

Depending on what you consider as a subtile movement... here is another picture where the hex tiles are subdivided in trapezoïds, which does not constitute -IMO- sub movement but rather sub movement management.

From 1 to 10 use keys 8 9 6 6 6 2 2 4 7
instead of . . . . . . . . 8 9 3 9 3 2 2 7 7

[sabrewolf]

ah ok, i think i now get what you mean.
imho, that would be using subtiles, although your steps would be just on main tiles... so i understand what you were thinking.

the problem herein could lie in the 3rd (from 3 to 4) step. how should the computer know that right (key '6') should go to tile 4 and not the one above. in your picture it's clear, as the unit is standing on the bottom half of tile 3. but if using full tiles, the unit will likely be positionned in the centre of each tile...

maybe i havn't given this concept enough thought.

thanks for your illustrations and welcome to apolyton

[wrylachlan]

Originally posted by Naokaukodem


Nice



Depending on what you consider as a subtile movement... here is another picture where the hex tiles are subdivided in trapezoïds, which does not constitute -IMO- sub movement but rather sub movement management.

From 1 to 10 use keys 8 9 6 6 6 2 2 4 7
instead of . . . . . . . . 8 9 3 9 3 2 2 7 7

erm... dude... those are squares. the edges may be tilted, but the movement is exactly the same as square tiles.

[Naokaukodem]

Originally posted by sabrewolf
the problem herein could lie in the 3rd (from 3 to 4) step. how should the computer know that right (key '6') should go to tile 4 and not the one above. in your picture it's clear, as the unit is standing on the bottom half of tile 3. but if using full tiles, the unit will likely be positionned in the centre of each tile...

Ok i forgot some precisions for this model. The unit would re-center on an hex tile only at the end of its move, I mean just when the movement points would reach 0. So of course if it stops or fortifies on the 3rd hex, it would not be anymore in a square, therefore the key for 3rd would "change" as it would not be 6 anymore but 3. A unit could also stay for ever in a square, but it would confuse the player IMO, plus it would really put a mess in all units relative positions and their appreciation on the map.

Well... now to answer to wrylachlan in the same time, basically it would not be squares, that I setted for the example and the comprehension. It would be visual way points as in the first picture above.

Originally posted by sabrewolf
thanks for your illustrations and welcome to apolyton

Thx for the welcoming.

[wrylachlan]

Originally posted by Naokaukodem


Ok i forgot some precisions for this model. The unit would re-center on an hex tile only at the end of its move, I mean just when the movement points would reach 0. So of course if it stops or fortifies on the 3rd hex, it would not be anymore in a square, therefore the key for 3rd would "change" as it would not be 6 anymore but 3. A unit could also stay for ever in a square, but it would confuse the player IMO, plus it would really put a mess in all units relative positions and their appreciation on the map.

Well... now to answer to wrylachlan in the same time, basically it would not be squares, that I setted for the example and the comprehension. It would be visual way points as in the first picture above.

In the above example, what would you press if you wanted to move from tile 2 to tile 3 and then to the tile above 3? Or to the tiles diagonally up and right or up and left?

[sabrewolf]

Originally posted by wrylachlan
In the above example, what would you press if you wanted to move from tile 2 to tile 3 and then to the tile above 3? Or to the tiles diagonally up and right or up and left?

you could still get from 2 to the tile above 3 by going north-east (key 9)... basicly, his proposal works the same as it would with just NE, N, NW, SE, S, SW ... but additionally E and W would be added, depending from where you come. so if you came from a southern tile, your movement to the right would take you to the lower of the to rightish tiles...
basicly, using countermomentum.

naokaukodem, is that right what i'm saying?

[Naokaukodem]

Thank you sabrewolf for your explanation, which is right.

A move from 3 to above it would be like hex 6 to 7 or 7 to 8, and a move from 3 to NE or NW of it like a move from hex 9 to 10. Below is a picture of the 3 different key "maps", depending on the inner position of the unit. (inner position which would influence key map ONLY by the way)

[Madine]

Why wouldn't there just be 6 keys to move? This whole sub-movement thing seems much too complicated.