Follow-up Comment #21, patch #3829 (project freeciv):

This was only in my 2.5 list because I thought I would be able to write my
ruleset for 2.5.  Given that the ruleset I want to write has no units that are
either native to all land tiles or all water tiles, and many of the "air"
units cannot reach all tiles, there's far too much nativity work to do to the
engine for me to expect anything to work (I was seduced by some of the content
in NEWS and scattered bits in the SVN logs moving towards 2.5).  Additionally,
I needed the BaseFlag/RoadFlag stuff, which has already been pushed to 2.6. 
I'm not sure that my ruleset would be "high quality" when first published
anyway: there are far too many possible balancing issues that need to be
worked out, and I still have some conceptual issues to resolve (e.g. Should
Neritic units be native to Lakes without dredging?  What combination of
combat_bonus entries best models depth charges for better rock/paper/scissors
interaction of units?  Should borax be a bonus resource without a strip mine? 
If not, how can the AI be convinced not to transform the tile?) anyway.

On movement, I think that for compatibility, it makes sense to just
arbitrarily choose one of source, destination, minimum, or maximum cost to use
for integrated roads (and I'm not sure which either).  For future direction,
it probably makes sense to use some general game parameter that chooses from
different move modes, and then either set a callback for different
implementations of tile_move_cost_ptrs (or portions thereof), or find a
low-cost way of considering multiple solutions in the same implementation.  I
don't think that longer-term plan belongs as part of this ticket, as it has
wider scope, really, but rather that we ought just pick something and use that
(potentially including the slowest of the mixed roads).

Another thing I realise reviewing this ticket is that I never answered the
question about sprites and integration.  At least for the tileset I use, there
are separate sprites for each direction, which are all layered into the final
image.  In the case where road A integrates with road B, but road B does not
integrate with road A, and tile X has road A and tile Y has road B, the
current code will draw a connector for road A on tile X towards tile Y, but
not draw a connector from tile Y towards tile X (for either road type), which
looks a bit odd if we gain the movement benefit of road B (but may provide the
right visual feedback if we select another move_cost to use).

And as an aside, with this and roadflags, we can drop TF_BRIDGE,
RF_REQUIRES_BRIDGE and potentially RF_PREVENTS_OTHER_ROADS, because we'll be
able to describe the behaviour associated with those in terms of integrates[]
and reqs{} (and those with interest in making everything very pretty can then
even have different graphics in place for bridges, if they so desire).

    _______________________________________________________

Reply to this item at:

  <http://gna.org/patch/?3829>

_______________________________________________
  Message sent via/by Gna!
  http://gna.org/


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

Reply via email to