This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Hexes vs squares (was Re: JConq)


"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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]