[Freeciv-Dev] Re: nonstandard maps

[Mike Kaufman <mkaufman@xxxxxxxxxxxxxx>]

On Sun, Aug 12, 2001 at 10:44:08PM +0200, Gaute B Strokkenes wrote:
> On Sun, 12 Aug 2001, mkaufman@xxxxxxxxxxxxxx wrote:
> > On Sun, Aug 12, 2001 at 02:56:40AM +0200, Gaute B Strokkenes wrote:
> >>  You're also assuming that you can normalize x and y coordinates
> >> separately.  That's fine for rectangles, cylinders and tori but
> >> fails for Möbius strips and Klein bottles.  The last two are
> >> perfectly possibly, if a bit odd, choices of topology and it would
> >> be kind of fun to support them.
> > 
> > The last two are not perfectly possible. Both those surfaces are
> > non-orientable.
> 
> And your point is?  The only problem I can think of is that going a
> single step in one direction and then one step in the opposite
> direction does not necessarily result in getting back to the original
> tile, but that is not an unsurmountable problem.

No. the mobius strip is the easy example. visualize a strip (or make one) and 
then think about the normal vector to the surface (color one side). That is 
your "up" orientation. If you follow the strip around you'll come to the point 
where you have a discontinuity in the Gauss map (the map of normal vectors) 
that is where you get screwed (it's actually worse than that because if you 
keep going, the side that you originally designated as "up" is now "down", 
that's why it's non-orientable).  You're (at least I am) sticking your terrain 
onto one side of the mobius strip (the side that's oriented "up"). When you 
come to the discontinuity, you basically hit the back side of your map (there 
ain't any terrain there) so you can't move in that direction period. Now if you 
decide to stick terrain to both sides of the strip, then you just get what 
we've got right now: a long rectangular map that wraps in one direction. My 
point is that non-orientable surfaces are pointless to talk about.

> 
> > I can dream up all kinds of orientable surfaces that would be fun or
> > at least interesting to try out, but it would be nuts to code or
> > maintain the code.

> I can't.  We are restricted by the need to be able to present the

Here's an easy one: take two rectangles with flaps and join them together at 
the ends of the flaps (number to number).

         3
       XXXXX
       XXXXX
   XXXXXXXXXXXXX
 1 XXXXXXXXXXXXX 2
   XXXXXXXXXXXXX
       XXXXX
       XXXXX
         4

         4
       XXXXX
       XXXXX
   XXXXXXXXXXXXX
 1 XXXXXXXXXXXXX 2
   XXXXXXXXXXXXX
       XXXXX
       XXXXX
         3

I think that that one would be fun. (this sort of thing would work for any 
n-gon n>2)

Yes, this is the sort of thing that is going to require something like 
T_BLACKHOLE which you describe below, but we've got that kind of thing right 
now, albeit in a different form. It's built right into map_adjust_* (a unit 
simply can't move off the the north of south edge of the map. same dealy here.

I've thought for a while that we needed something like T_BLACKHOLE (so we could 
do things like impassable mountain ranges (think about the strategic and 
gameplay consequences of such things. wow. want an economic game? how 'bout a 
map like this:

  XXX    XXX
  XXXXXXXXXX
  XXX    XXX
   X      X
   X      X
  XXX    XXX
  XXXXXXXXXX
  XXX    XXX

all of a sudden smallpox is pointless. Better get that spaceship up quick...)). 

> world as a grid, which pretty much prevents us from having arbitrary
> 2-manifolds, such as a sphere.  At least I can't think of any.

yes, I was going to respond to Reiner about this, but I can do it here.
This is my issue with his proposition about topologies such as blocks. What 
does one do at the corners? You've got to map your surface into R^2 to present 
a locally planar mapview to work on. For something as simple as a sphere, 
you've got to squash and stretch the coordinates to make it fit. We're 
contrained by the tile object.

This normally wouldn't be a problem, since, locally, small patches of sphere 
look just like rectangles. The problem, is that, I as the user, can adjust the 
size of my viewport--and thus the size of my patch--to an arbitrary size (at 
least on X-Windows) At that point, the locality breaks down. Note that we have 
this potential problem right now with simple x-wrapping.

We could do for a spherical surface what we do now for x-wrap, which is simply 
restrict the user from increasing the patch size (right now if you try and make 
your viewport wider than map.xsize, you get black the rest of the way). On a 
sphere, you could restrict the patch to less than a hemishpere. Then you could 
simply use a graph function (x,y,sqrt(r^2-x^2-y^2)) and drop the z coordinate. 
Then your viewport could be rectangular, but your mapview would not. It would 
be circular. There would be blackness outside your patch.

Hmm, now that I'm thinking about it, it seems doable.

> I think the best way to do this would be to add a new tile type,
> T_BLACKHOLE or somesuch, which is unpassable, unusable etc. etc.  Then
> you could sculpt whatever you wanted out of the shapes available.

For Ross: this arbitrary map discussion, and Reiner's old post leads me to 
believe that there needs to be a map.earthlike=1|0 in which the mapgen routines 
do the polar-equatorial thing or not. How difficult is this?

-mike