Complete.Org: Mailing Lists: Archives: freeciv-dev: February 2003:
[Freeciv-Dev] Re: (PR#2957) is ocean as a function with oceanness read f
Home

[Freeciv-Dev] Re: (PR#2957) is ocean as a function with oceanness read f

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: kayeats@xxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#2957) is ocean as a function with oceanness read from ruleset
From: "rwetmore@xxxxxxxxxxxx via RT" <rt@xxxxxxxxxxxxxx>
Date: Mon, 10 Feb 2003 17:48:21 -0800
Reply-to: rt.freeciv.org@xxxxxxxxxxxxxx

kayeats@xxxxxxxxxxxxxxxxxxxxxxxxx via RT wrote:
[...]
> It looks like we're looking at:
> 
> river, ocean, and polar flags, along with perhaps a "base good terrain"
> flag (and at worst a few more).  Its concievable that it would be
> worthwile for some of these (river esp, possibly also ocean) not to be
> flags at all but variables which can take more than two values (eg for
> river placing as mentioned in the previous email), but they could start
> out as flags and get pulled out as variables if the need arised.
> 
> global warming and nuclear winter variables which take a terrain type as a
> value.
> 
> terrain placing parameters.  About 6 given a framework something like my
> mapgen patch.  Other mapgen solutions would require something different.

I seriously doubt your "6" case will remain such for long.

One way to look at the problem of parameters is to list the possibilities
and then trim back, rather than incrementally adding everytime a new feature
idea rises to visible importance. This at least helps scope the problem.

If you go the T_FLAG route, then you you need to break things down to
fundamental features that can be recombined and whose effects can be
recombined or be the result of some combinatorial selection on the fly.
You write hard code for mini-effects and choose which on the fly.

The current system uses composite terrain types with "optimized" feature
handling and so you get very little cross linkage and a small set of basic
elements that need to be treated individually. The T_FLAGs are basically the
composite T_TERRAIN types, though sometimes one wants to apply an effect to
a set of types. The drawback is of course the hardcoding, or rather need to
figure out the way to handle new code interpretation on the fly if you add
a new type and handler.

But this is where things might lead with gen-map flags ...

Basic terrain type flags:

1)  3 types of "wetness"     wet, moist, dry
2)  3 types of "temperature" cold, temperate, hot
3)  3 types of "roughness"   flat, hilly and rocky
4)  3 types of "elevation"   deeps, coastal, heights

Special flags:  used for special effects (almost unlimited)

T_LAND       - basic land vs water (or maybe sea/archipelago/river/land)
T_ARCTIC     - polar ice cap
T_BADLANDS   - inaccessible terrain
T_WATER      - freshwater source (for irrigation)
T_PORTAL     - teleport location
  ...

This is already something like 16 or more flags and 300 combinations.

How do you build the tile graphics? Does every tile combination get its
own special graphic (this is the current system)? Or do they get built
up as some sort of sprite and dither effect on a few core elements?

Does a wet, temperate, hilly, coastal tile mean anything in terms of its
basic F/S/T and movement? Or are these all assigned specifically like
the current system? Do these convey any other meaning like which unit
types are allowed to travel over which types, or what bonuses they
might get (e.g. foot units unaffected by roughness, mobile can't move
into rocky, and are penalized for hilly, infantry units take damage
per turn in dry terrain, etc).

The problem is that things grow rather exponentially and after a while
the cross product combinations start to have limited viability. It is
often difficult to precisely measure an effect that results from a
combination of whatever T_FLAG types you select as the orthogonal set.

The choice usually comes down to doing a broad-based system poorly and
possibly unusably, or doing a restricted system well but with limited
extensibility and flexibility.

Or think of it as doing a lot of incremental gen-map effects along
a pre-selected set of T_FLAG variables, or a few specially coded
scalar product effects based on a few selected composite T_TERRAIN types.

Cheers,
RossW
=====




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