Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2000:
[Freeciv-Dev] Re: Suggestion: Growning cities
Home

[Freeciv-Dev] Re: Suggestion: Growning cities

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: Suggestion: Growning cities
From: ccrayne@xxxxxxxxxxx
Date: Sun, 27 Aug 2000 19:25:01 -0700

In <39A855FB.1BE6ADB7@xxxxxxxxxxxxxx>, on 08/27/00 
   at 09:42 AM, Steve Hodge <shodge@xxxxxxxxxxxxxx> said:

:Being able to handle an arbitrarily connected network of
:cells wouldn't be a bad thing for FreeCiv.

To me, the key design point in modifying Freeciv to allow playing on a
globe is that the implementation can be, and should be, divided into three
independent tasks:  a coordinate system which will uniquely identify any
point in the game space; a rendering algorithm for the detailed map in the
main window; and a rendering algorithm for the world view map.

I. Coordinate system

The current coordinate system is based on the concept of a point in a
plane (x,y) and the height above the plane (z) in which z is assumed to be
zero for all purposes except the map generator.  Although it is possible
to describe the surface of a sphere in such a system, it greatly increases
the computational cost of movement along the surface.

Instead, the existing x and y coordinates should be interpreted as angular
movement along lines of latitude and longitude, with z retaining its
current meaning as height above the surface.  The strength of this method
is that it preserves most of the simplicity of the current method.  In
fact, the current cylindrical map becomes just a special case of the
spherical one.

II.  Detailed Map

Although there are some known advantages to using something other than
squares to tile a physical game board, the assumption that this is also
true of a scrollable window does not automatically follow.  The game logic
deals with points, not areas.  Since all regular polygons have a clearly
defined center, how the areas surrounding each point are rendered is
solely an aesthetic issue.  And, as this window is not intended to show
the entire world at once, there are no closure problems (i.e.  the
pentagons are always on the dark side).

III.  World Map

Since this map is designed to show the entire world at a single glance, I
do not feel that a 3D view which the user had to rotate would be
acceptable.  Therefore, some means of unrolling a sphere is required.  The
easiest method would to use the same method as today, except that there
would be a different number of columns in each adjacent row, thus changing
the current rectangle to a diamond. Alternatively, the rectangular shape
could be preserved by padding the width of the elements in each row as
necessary.

IV.  Programming Considerations

Because N/S movement is always along a great circle route, the
y-coordinate handling remains unchanged, except for the special cases of
the poles themselves.  However, because the farther away a unit is from
the equator the fewer the number of equally spaced points there are on a
given line of latitude, the x-coordinates of these points are no longer
consecutive.  Thus, any routines which handle movement, or test for
adjacency, must look up the x increment for the corresponding y value in a
table built by the map generator.


Best,
        -- Chuck Crayne
-----------------------------------------------------------
ccrayne@xxxxxxxxxxx
-----------------------------------------------------------




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