For my ruleset, I'd like to have some roads that share movement.  Two
examples that may be useful for discussion: having a "Track" with move_cost
3 be a prerequisite for road for only certain terrains, and having a "Canal"
that acts like a river, except it needs building, requires technology, and
has some other unfortunate side effects.

    In the case of "Track", the easy way to implement it in the ruleset
would be to have two different sorts of road ("Road", "Mountain Road") that
share a flag, and set "Rail" to depend upon that flag rather than depending
on a road being emplaced.  "Mountain Road" could then be dependent on the
appropriate terrain flag and the presence of a "Track".  In the case of "Canal",
the easy way to implement it in the ruleset is to ignore move_cost entirely,
and only make it native for unit classes without UCF_TERRAIN_SPEED.  In the
first case, this is frustrating because units would require SINGLE_MOVE (or
more) move points to move from "Road" to "Mountain Road".  In the second case,
this is frustrating because it's hard to have a logical justification for why
it might be easy to travel along a river but hard to travel along a canal: both
surely have banks (and early canals usually had parallel oxtracks or similar),
or, if the rationalisation involves little river rafts that the user doesn't
need to micromanage (similar to the planes that fly out to drop paratroopers),
then it doesn't make any sense *not* to allow them on canals.

    So, the solution would be to have some road compatibility check in
map.c:tile_move_cost_ptrs().  There are two methods to do this in the
ruleset that seem to have precedent: either define the road_class concept,
and have all roads that belong to the same road_class be compatible, or
to have an "integrates" field that takes a bitvector of roads with which
the current road is compatible.  The former is less expensive in terms of
the necessary operations in tile_move_cost_ptrs() (because we can iterate
over the road classes, and then only iterate over members internally
when checking nativity, rather than having to recursively iterate all
the roads for roads*roads operations), but the latter may be more
comprehensible to ruleset authors (because it looks just like so many other
lists in the rulesets, and there are no new concepts involved).

    If anyone has a recommendation for one or the other of the above
mechanisms, or has some other suggestion (I'd really like something that
let different unit classes have different move_costs for the same road,
but haven't figured out any sane way to do that), please share.  In the
absence of opinion, I'd probably select the road_class implementation,
because it means that implementing the reqs for canals doesn't require
first allowing disjunctive requirement specification (which has it's own
large set of dependencies).

    Thanks for your help.

-- 
Emmet HIKORY

_______________________________________________
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

Reply via email to