Re: Non flat maps (use pentagons and septagons on maps)

[Jakob Ilves <illvilja at yahoo dot com>]

Hello!

(back in orbit! Back to the moon!)

--- Stan Shebs <shebs@apple.com> skrev:

> Jakob Ilves wrote:
> 
> >Hello!
> >
> >The orbiter is back, and in this email I'm considering to take a trip to the moon...  And you
> are
> >welcome to join me on the ride...
> >
> >One thing I've been tinkering with on paper and in Java for approx 10-12 years is to let
> strategy
> >games take place not only on a flat hexagon playfield but upon a playfield where you have
> >occasional pentagons and septagons thrown in.
> >
> Heh, not to be discouraging or anything, but I used up a bunch of dead
> trees sketching out hex sphere algorithms around 1995, finally gave up.
> Executive summary is that it's messy for geometry calculations (how
> units are nearby?), messy for graphics (although 3D hw changes the
> difficulty), and messy for AI. I then decided it was intrinsically
> out of scope for Xconq, and went on to the next knotty problem. :-)

Actually, I did not intend to use this pentahexahepta (PHH) world for Xconq, even if I think the
icosaeder (I checked the spelling ;-) would make sense with it's tradition in strategy boardgames.
 I've a dream of an empire/xconq like play by mail game where I would like to have these PHH
worlds in from the VERY start.  Not at an extreme granularity considering hexes, but still.

3D rendering actually not necessarely solve rendering the entire world.  It's easy to create PHH
worlds were the sectors (let's just call all hexes, pentagons and heptagons for "sectors") are
tied together in a topologically consistent way but still the entire world would be impossible to
render in a 3D model.  One could of course decide to only look at parts of the world and then let
the player put together a mental map himself.

Considering the 3d rendering of these things, if you attach a "tube" to a flat hex surface, is
that tube then going inwards (a tunnel) or outwards (a pillar) from the surface?  Topologically
they are equivalent, from a 3d rendering perspective they are not.  (and game mechanics as I see
itright now ONLY considers the 2d topology of things...)

But yes, as also Brandon pointed out there are tons of nasty obstacles (potential nightmares):
* AI would be a challenge (that's why I aim at PBM, there all players are human, hence no AI
needed.  Easy cop out for me ;-).
* How to render?  My plan right now is to let the player focus on the current sectors and then the
sectors within a certain radii is displayed as well, possibly distorted as needed.
* How to render the whole world?  Ouch!  Do I have to do that :-).  Seriously, I might "cut down"
the topological info for the whole world display, limiting the visibility of individual sectors. 
Or, I can use a flattened out, cut up map of the world.
* Economics of data storage.  Yes, it's a pain and my current prototype uses one Java object per
hex, per vertice and per edge, including links to all neighbor objects.  Lots of bytes per sector.
 But computer performance is getting cheaper and cheaper and so is memory...  Given my development
pace and Moores law, this memory usegae is not an issue ;-).

Why even do this?  I don't do it because it's hard.  I do it becaues it's darn impossible. (Ok,
that's a travesty of a quote I found on the NASA web site, I admit).  Mostly I want to create it
because I want to play it and it's too hard of a problem to expect anyone else create it for me.

(Brandon, I sincerely hope you get out of debt.  I also hope you manage to get together Ocean Mars
because it sounds like a very cool game!  Good luck with both!)

> Ironically, the most plausible model was a pair of hemispheres; while
> things are weird all along the seam, at least they're consistently
> weird, and the player can plan for it.
> 
> Stan

/IllvilJa, @ the moon 


=====
(Jakob Ilves) <illvilja@yahoo.com>
{http://www.geocities.com/illvilja}

Höstrusk och grå moln - köp en resa till solen på Yahoo! Resor på adressen http://se.docs.yahoo.com/travel/index.html