Re: [Xconq-hackers] A bunch of bug fixes, bug reports, and requests

[<ms...@an...>]

On Thu, 22 Mar 2007, Massimo Campostrini wrote:
> I am designing a World War I game, including of course trenches and
> barbed wire.  After some experimenting, I decided to use terrains for
> them, a coating for trenches and a border for barbed wire.

Coatings haven't been tested very much, so it won't surprise me if you
find a lot of bugs related to them.  Reports and fixes would be welcome.

> implementing border/connection - cell compatibility using a single table
> * adjacent-terrain-dislikes t1 t2 -> n
> it is possible to add a connection or border terrain tx
> between cell terrain t1 and cell terrain t1 if
> adjacent-terrain-dislikes(tx,t1)+adjacent-terrain-dislikes(tx,t2) < 100

As you probably know (based on the names) there's a series of
adjacent-terrain tables already, and there's a statement in the manual
"Incompatible types may not be juxtaposed, either at game setup time or by
unit action during a game."; but at the moment, those tables don't seem to
have any effect except during setup.  So it makes sense that there should
be tables in that series that will affect unit terrain-modification.

I wonder if the table you describe could be extended to also cover
compatibility between different border and connection types.  Here's what
I'd propose:

* call it "terrain-compatibility" to express that it covers more than just
  cell terrain disliking border/connection terrain
* when you try to add a connection or border, it checks the new type
  against both adjacent cells and all existing connection or border types
  on that edge
* if the sum is more than 100, fail.

That way you can set (road (sea shallows plains) (100 90 0)) and get roads
that go into the shallows for one cell but not into the sea, as in your
example; but you can also set (road trench 100) and get no possiblity of
making a road over a trench; and you can combine the two so that a border
or connection makes it harder, but not impossible, to build another border
or connection.

Thought: would there ever be cases where you'd want compatibility in the
other direction - like "you can't build a road unless there's already a
bridge" so that the bridge *allows* instead of *forbidding* the road?
That might be possible by the use of negative numbers in the
terrain-compatibility table.

Also, although this isn't an issue you brought up:  it seems like maybe
the adjacent-terrain-effect table should take effect when a unit changes a
cell terrain type.  Probably just by being applied immediately, like
wrecking.  The terrain-compatibility table as described will also have a
lot of unused entries relating to cell-cell interactions; I wonder if it
would make sense to try to apply it to determining where units can or
cannot change cell types.  (For instance, allow changing cell type only if
the sum of all the entries crossing the new type with the six it would be
adjacent to, is zero.)  There's a lot to be said for having the
map-generation stuff defined by one table and the unit-action stuff by a
different table.

> A worker would need 5 turns to add a road from plains/desert to
> anything and 10 turns from forest/mountains to anything.  The problem
> is that a worker can stockpile concrete before (or while) moving to
> the construction place.  A simple solution would be a mechanism to

Another option would be to make the consumption-per-move table behave that
way - movement will consume material if available, but lack of material
doesn't block movement.  The "lack of material blocks movement" effect
could then come from the material-to-move table.  I don't particularly
advocate that, though, because it would probably break a lot of existing
games, the AI, and other code.  If it comes to that it would probably be
better to just add another table as you describe, though I'm not happy
with even the existing two "material for movement" tables - I've already
spent a lot of time and annoyance trying to debug games that were using
one when they wanted the other, and a third seems likely to make it even
more complicated.

I wonder if this issue could be resolved instead by using the (cell)
terrain to store the material.  You can allow the terrain to store
concrete, and not allow the unit to store concrete.  When the unit is
sitting in terrain, it'll manufacture concrete which goes into the
terrain; when it tries to build a road, it should (if not, this is
probably a bug) draw the concrete from the terrain, having no concrete
storage of its own.  That would have a side effect of concrete remaining
in the cell if the engineers are called away, to be potentially used by
other engineers (maybe even enemy engineers!) who try to build in the same
spot.  You could make the unused concrete evaporate by making the terrain
consume it (then the engineers, when present, would produce it fast enough
to overcome the consumption); but it might even be more realistic that if
one group of engineers starts preparing a site to build roads, another
could come along and finish the job.

This general issue is one I've struggled with in other games; the basic
issue is that terrain alteration should usually be a very time-consuming
operation compared to stuff like movement, so it's hard to model in a game
where the terrain alteration has to eventually be considered to happen on
some specific turn; you have to give the engineers something to do to take
up their time as the terrain alteration nears completion.

Something I've tried, though it's less elegant from a user interface
perspective, is to have the engineers build a "road" unit, which cannot
move, and once built, the "road" unit actually builds the road, destroying
itself by material exhaustion in the process.  There's a lot of support
for stuff like "tooling" which can be used to handle the time delay.

> It could be possible for borders to block connections:
> * border-blocks-connection t1 t2 -> t/f
> if t, units are charged their mp-to-traverse border t1
> even if they are on connection t2
> (this should be displayed graphically by drawing
> border over connection / connection over border)

In such a case, should the connection be allowed at all?

I think there is already some official order of drawing terrain types
(probably earliest defined type has lower priority).  As far as I
know, there isn't any really well-defined rule for what happens when there
are two or more connection/border types applicable.  Would it make sense
to simply have the rule be "the highest-priority one is the one that
applies" and clarify the rule that determines which one is highest
priority?

> A cell/border terrain could affect capture on/across it:
> * capture-attack-terrain-effect u1 t -> n%
> * capture-defend-terrain-effect u2 t -> n%

I like this idea.  Should it be the attacker's terrain, the defender's
terrain, or each their own terrain?

> perhaps, if t1 and t2 are connected by ty, factor in tx effects only
> if border-blocks-connection(tx,ty) is t.

At the moment, movement seems to use whichever route allows the mover to
get there in fewest points, assuming they're allowed to use it.  I'd be
inclined to think that combat, both attack and capture, should follow the
same rule as movement - use whichever terrain maximises the chance of
success, subject to the attacker being allowed to use that route.

> (BTW, attack-terrain-effect and friends could also factor in
> border effects.)

Yes, they should.  And connection effects, too.  If possible, they should
also be able to handle *increasing* the chance of success - much easier to
fight an enemy on the other side of the river if there's a bridge in
between.

> Finally, ferry could have a per-terrain component, e.g.,
> * can-be-ferried-over u2 t1 -> t/f
> if f, u2 entering/leaving a transport u1 in cell terrain t1 is not
> ferried over the cell even if ferry-on-entry/departure would allow it,
> likewise for ferrying over a border tx.
> For sake of completness, we could also have
> * can-ferry-over u1 t1 -> t/f
> ferrying is done only if all three of
> ferry, can-be-ferried-over, and can-ferry-over allow it.

This seems very similar to the existing ferry-on-entry and
ferry-on-departure tables, which don't allow you to specify individual
terrain types but do allow you to specify whether borders in general
should be ferried over.  Is there a case where those tables aren't
adequate and you need to specify different settings for different border
types?
-- 
Matthew Skala
ms...@an...                    Embrace and defend.
http://ansuz.sooke.bc.ca/