Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2001:
[Freeciv-Dev] Re: [Patch] Fortress with enhanced vision (watchtower-lik
Home

[Freeciv-Dev] Re: [Patch] Fortress with enhanced vision (watchtower-lik

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Bert Buchholz <bertbuchholz@xxxxxx>
Cc: rf13@xxxxxxxxxxxxxxxxxxxxxx, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: [Patch] Fortress with enhanced vision (watchtower-like)
From: Jason Dorje Short <jshort@xxxxxxxxxxxxx>
Date: Sat, 25 Aug 2001 19:39:48 -0400

Bert Buchholz wrote:
> 
> On Sat, Aug 25, 2001 at 05:59:53PM +0200, Raimar Falke wrote:
> > On Sat, Aug 25, 2001 at 04:26:11PM +0200, Bert Buchholz wrote:
> > > IMPORTANT: Currently, if there are units with visionrange > 2, their
> > > visionrange is reduced. This is not logical, so maybe the visionrange
> > > shouldn't be set to 2 but enhanced by 1 (vision_range+1), but this would
> > > mean that spies inside a fortress would get a visionrange of 3, which
> > > seems to be very much. In fact, every visionrange > 2 seems to be too
> > > much, but maybe you think diffrently. Also, the value 2 is hardcoded,
> > > maybe that is not desired, even though I don't see too many reasons to
> > > play around with this one, but you never know :-)
> > For maximum flexibility it may be nice to have two variables:
> > watchtower_vision and watchtower_extra_vision. Your current code
> > implements watchtower_vision=2. Could you replace the hardcoded 2 with
> > a call to get_watchtower_vision() which is something like:
> >
> > {
> >  int base_vision=get_unit_type(punit->type)->vision_range;
> >
> >  return max(base_vision,
> >             max(watchtower_vision, base_vision+watchtower_extra_vision));
> > }
> 
> Hmm, of course, this function wouldn't be a problem, I'm just not sure
> if I understand the need of watchtower_extra_vision. When a unit's
> visionrange is smaller than watchtower_vision, it gets this new value
> and if it's the same or larger, it keeps it's own visionrange. I suppose
> I'm overlooking something here, otherwise, my way would be simpler.

Raimar is suggesting having 2 different ways watchtowers can work:

watchtower_vision => The unit's vision will be increased to match this.

watchtower_extra_vision => The watchtower gives all units this much
        *extra* vision.

As proposed, these values would be 2 and 0.  By giving both options and
making this a ruleset option, you allow for a lot of flexibility.

> > Could you also make these two variables changeable by server command
> > or ruleset?
> 
> Well, personally, I find it nicer to put this into a ruleset, but this
> is open to discussion. Assuming, it is put into a ruleset, I'm not sure
> where to put it. I think, the game.ruleset would be most fitting, what
> do the others think?

It must be changeable by the ruleset.  You can make it changable by
server option too, if you want.

> > Another issue to have a more fine grained control over vision
> > range. The vision range is currently a square with the dimensions
> > (vision*2+1)X(vision*2+1). Maybe this could be changed to somelike
> > like:
> >
> > vision=1:
> >
> >    x
> >   xux
> >    x
> >
> > vision=2:
> >
> >   xxx
> >   xux
> >   xxx
> >
> > vision=3:
> >    x
> >   xxx
> >  xxuxx
> >   xxx
> >    x
> > vision=4:
> >   xxx
> >  xxxxx
> >  xxuxx
> >  xxxxx
> >   xxx
> > and so on.
> 
> Yes, I see, this could possibly be used for other stuff as well, but is
> this implemented in some way already or would this have to be done
> completely new? Probably I could do this, but for that I'd have to take
> a closer look at the tile-coordinates-handling...

I had some thoughts on this before.  There are three ways to measure
distance:

(1) Use the lateral distance.  Thus distance=max(x-x0,y-y0).  This is
what you're doing now:

3 3 3 3 3 3 3
3 2 2 2 2 2 3
3 2 1 1 1 2 3
3 2 1 0 1 2 3
3 2 1 1 1 2 3
3 2 2 2 2 2 3
3 3 3 3 3 3 3

(2) Use the "manhattan" distance.  The manhattan distance is the sum of
the distances along each axis (or, in Manhattan/New York City, the
number of blocks you must walk to get from point A to point B). 
Manhattan distances are like so:

      3
    3 2 3
  3 2 1 2 3
3 2 1 0 1 2 3
  3 2 1 2 3
    3 2 3
      3

(3) Use the direct "pythagorean" distance.  This is the distance of a
straight line between the two points, calculated using the pythagorean
formula, so that your resulting shape corresponds to a circle.  The
following table shows the *squares* of the distances:

      9
  8 5 4 5 8
  5 2 1 2 5
9 4 1 0 1 4 9
  5 2 1 2 5
  8 5 4 5 8
      9

Which one of these is the closest to the way FreeCiv works now?  Well,
most people would tell you #1.  In fact, the answer is #3.  In all cases
that I know of, FreeCiv's areas correspond to circles.  But, the
pythagorean distance is never used internally - it's always some special
case like vision=1 (a circle of radius sqrt(2)), vision=2 (a circle of
radius sqrt(8)), or citysize=2 (a circle of radius sqrt(5)).  It would
be really good IMO if all of these were integrated to use just the
Pythagorean distance, so only one system would be used.  This would be a
problem from the ruleset's point of view since you would to need to use
non-integer distances to represent most distances (or, alternately,
conversions from the old system could be used like "vision=X" =>
vision_radius=X*sqrt(2)).  The first step, though, is to implement the
system.

jason


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