Re: JConq

[Hans Ronne <hronne at pp dot sbbs dot se>]

>Let me restate this question.  Best practices by virtually every
>commercially successful strategy game has been to use squares, not hexagons
>as the basis of game design.

I think a major reason is that Civ, the most successful computer strategy
game ever, used squares. Never underestimate the human tendency to stick
with existing solutions. I don't know why Sid Meier used squares instead of
hexes in the first place. Maybe the resulting marginal gains in computing
and graphics speed were important enough back in the days of the 286-based
machines.

As for rewriting xconq (or JConq) to use squares, I think it's doable, but
hardly worth the effort. First, it would require a lot of changes not only
in the interface but also in the kernel. Search algorithms assume a
hexagonal world, as do certain parts of the AI code. Second, all the games
(or at least the maps) would have to be rewritten from scratch. Believe me,
this is a lot of work. Check out the Middle East map in anc-near-east.g, I
spent a lot of time on it. Or even worse, Stan's gigantic map of the whole
Earth.

A third consideration, as Eric pointed out, is that hex maps are inherently
superior in the sense that they treat all directions as equal. With square
maps you get weird non-Euclidian effects as moving in some directions is
faster than others. There is also the issue of blocking. It is much too
easy to block enemy movement in a square grid game. For these reasons, a
world built out of hexes is more realistic, in the sense that it more
closely resembles the real world, which in turn makes it easier to write AI
code.

So if you want to port xconq to java, I would encourage you to give it a
try. I doubt the result would be much better than existing versions, but I
could be wrong, and the proof is in the pudding. However, changing the grid
seems to me like an unnecessary complication. It is not this part of xconq
that needs to be fixed, it is the network code.

Hans

Hans Ronne

hronne@pp.sbbs.se