Complete.Org: Mailing Lists: Archives: freeciv-dev: February 2004:
[Freeciv-Dev] Re: (PR#7287) Extended Topologies
Home

[Freeciv-Dev] Re: (PR#7287) Extended Topologies

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: mburda@xxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#7287) Extended Topologies
From: "Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>
Date: Sat, 21 Feb 2004 18:53:03 -0800
Reply-to: rt@xxxxxxxxxxx

<URL: http://rt.freeciv.org/Ticket/Display.html?id=7287 >

rwetmore@xxxxxxxxxxxx wrote:

> A mobius E-W or N-S wrap is functionally no different than a wrap
> to form a standard cylinder surface of twice the circumference.
> Since game players experience only the 2-D surface, they cannot
> see any of the 3-D features that leave some developers starry eyed.

Yes, I see this now.  The two-dimensional surface of a mobius strip is 
no different than a cylinder.  It's only when we look at it in three 
dimensions do we see how it is different.

Similarly a klein bottle is equivalent to a torus.  This means we can 
advertise that we support klein bottles!  Cool!

This leaves us with two different fake-mobius topologoies.

What I was calling a mobius strip topology was a cylinder with a flipped 
wrap.  I've diagrammed it plenty of times before.  I believe such a 
topology should be possible in two dimensions, although I don't know why 
anyone would want to play it.  (In three dimensions, I'm pretty sure 
this is impossible.)  I like Marcelo's name of "Jason strip" topology 
for this one :-).  One might imagine that this is the two-dimensional 
complement to the three-dimensional mobius concept.

What Marcelo was calling a mobius strip was a map with an offset wrap. 
In the Y direction we wrap normally, but in the X direction each wrap is 
accompanied by a ysize/2 (or whatever) offset.  I considered this type 
of topology early on in gen-topologies, and it is pretty interesting. 
It basically amounts to a hexagonal map (not hexagonal tiles, but a hex 
map).  Consider the following hexagon:
   ______
  /      \
/        \
\        /
  \______/

and tile it indefinitely in each direction.  Now you can wrap it using 
linear algebra using the vectors (0, map.ysize), (map.xsize, 
map.ysize/2) and (map.xsize, -map.ysize/2).  (The last one is obviously 
a linear combination of the first two.)  In fact, if you take the above 
hexagon and look at it like this:
   ______
  /|    |\
/_|    |_\
\ |    | /
  \|____|/

Then you can match the two pieces up on the left with the two holes on 
the right and get a rectangle.  This rectangle is our topology.  You can 
distort the hexagon if you like, and the wrap remains valid.

This topology is interesting because it approximates a circle (not a 
sphere, but a circle).  Thus it will probably be more playable than a torus.

---

> But in all cases, one should ask what the (added) value is to the
> user and not to the developer that is intrigued with higher math
> problems rather than game play.

Yes, this is an issue.  But since the developers are the ones doing the 
work, the developers are.  Added topologies don't hurt players, they 
just take more work for the developers.  (And note this work isn't just 
in terms of writing code for the topology, but in maintaining it as 
well.  This amounts to an indefinitely large amount of work.)

> In the latter vein, if you are discussing reverse and reverse-reverse
> or other weird things that an intelligent 11 year old user would
> have difficulty following, then you are probably not talking about
> a useful game topology.

The player doesn't care what topology he uses.  He just wants the game 
to be fun.  So it doesn't matter what terms we use; all that matters 
(from the player's point of view) is how much fun it is.

---

So, I'd consider the extended topologies with both of the above in mind. 
    Marcelo has already done a lot of work to get a very solid design 
that gets all the details right.  If we go forward with it, I'm willing 
to go over it and work through the problems with him.  But if there's 
_no chance_ that we want this topology, I don't want to do this (and 
Marcelo's work will have been wasted - very bad!).

Consider also that the extended topologies come in several forms.  For 
instance an offset-wrap as I describe it above will probably not take 
much work to implement, but gives only a small advantage over the 
current torus wrapping.  A quincuncial wrapping will take a fair amount 
of work to implement.  It is of high theoretical interest (how many 
hours have we spent discussing approximations of a sphere?) but its 
playability hasn't been determined.  People need to _play_ this thing 
before we can assess it.

jason




[Prev in Thread] Current Thread [Next in Thread]