Re: Hexes vs squares (was Re: JConq)

[Simon Juncal <sjuncal at erols dot com>]

sorry to send this out using a reply all, but i can't get unsubed from 
the xconq list, which is pretty embarrassing considering i used to run 
an email list mysef... if someone could please clue me into how to unsub 
i'd be very grateful

Stan Shebs wrote:

>"A. Rick Anderson" wrote:
>
>>Every major commercially successful computer-based strategy game that I am
>>aware of in the last five uses a square-based grid.  Now I've already said
>>that I am not a UI person, so I can only speculate about why this is
>>true.  However, I am very reluctant to discard the example of these highly
>>successful games.
>>
>
>This is a very interesting game design point.  I think the choice
>has more to do with genre and audience than anything else.
>
>For instance, wargames nearly always use hexes, with some grand
>strategy games using regions (like Risk), and some tactical games
>using continuous terrain (like TacOps).  Hexes are especially good
>when distances matter, because between any two points the distance
>is the same irrespective of direction.  When your game needs trucks
>to be x% faster than tanks on roads but y% slower cross-country,
>hexes will give you the most accurate model of any tesselation.
>
>Squares have the advantage of being more familiar to the person
>who's spent more time driving around city streets than reading
>military history, and they work just fine when time and space
>don't really matter that much.  For instance,it doesn't really
>take warriors 50 years to walk 100 miles, or 1 year for a bomber
>to fly 500 miles, as happens in Civ; the abstraction of movement
>for the sake of playability is so extreme that the distinction
>between moving horizontally/vertically vs diagonally is trivial.
>Hexes would add nothing to Civ gameplay.
>
>One compromise I've seen in RTS games is to use a grid for
>representing terrain, but work with unit position and motion as
>continuous values.  That way you get artwork simplification
>while retaining realism and flow of the action.
>
>Xconq partially abstracts geometry, with the long-term expectation
>of enabling a game module to specify which way to go, but I now
>think that's too ambitious for a development team any smaller than
>10 FTE (full-time-equivalent) developers.  (To put it in perspective,
>Xconq has only occasionally gotten to 1 FTE...)  For any new game
>effort, it would be better to pick one geometry and stick with it.
>
>Stan
>