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

[Massimo C. <Mas...@df...>]

ms...@an... writes:

> On Tue, 20 Mar 2007, Eric McDonald wrote:
> > (You may want to discuss connection/border things with Matthew Skala,
> > since he did some work with them a while back, IIRC.)
> 
> Yes.  It's been a while since I looked at that, but I'd certainly be
> interested to hear what you have in mind.  It's possible that some of it
> may already be covered by existing tables and just not documented - I know
> I added a couple of tables already dealing with what kinds of terrain can
> and cannot appear together, though I'd probably have to go back and look
> at the changelogs to figure out what I actually did.

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.

Trenches work pretty well: setting coating-depth-min to 0 you prevent
digging trenches in sea, swamp and ice; combat and movement effects
are modeled by defend-terrain-effect, fire-defend-terrain-effect,
mp-to-enter-terrain, and mp-to-leave-terrain.

I would like to have barbed wire as an impassable barrier which has to
be removed before it can be crossed, but I have problems: there is no
naturay way to prevent adding barbed wire in unwanted terrain (like
sea), it doesn't interrupt roads, cities will ferry over barbed wire
(or they will not ferry over rivers, there is no terrain-dependant
ferry-on-xxx table).

I am also experimenting with road construction.  With some material
trick we can restrict the cell terrain where the builder sits, but not
the cell terrain where the new road will end.  Multi-turn road
construction is also not easy to achieve.

Some proposals:

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

example:
(table adjacent-terrain-dislikes 
   (road (sea shallows swamp desert plains forest mountains ice) 
         (100       90    50      0      0      0         0  90)))
would allow to build stretches of roads of length 1 through shallows
(bridges) and ice (tunnels) but not through sea.

Using material-to-add-terrain / consumption-per-add-terrain to slow
down add-terrain, with a "counter" material which must be accumulated
slowly before the add-terrain action is possible, is "almost" working:

(material-type concrete)
(unit-type worker)
(table material-to-add-terrain (worker concrete 10))
(table consumption-per-add-terrain (road concrete 10))
(table unit-storage-x (worker concrete 10))
(table base-production (worker concrete 2))
(table productivity 
   (worker (sea shallows swamp desert plains forest mountains ice) 
           (  0        0     0    100    100     50        50   0)))
(table in-length (worker concrete -1)) ; don't get concrete from other units

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
burn a material when either a unit or its transport moves;
base-consumption + consumption-as-occupant is not quite right, because
I would like to accumulate a material while sitting in a standing
transport (building a road starting from a city); consumption-per-move
is not right either, because movement should be possible even without
this material.  I propose

* material-lost-in-movement u m -> n
(amount of material lost if either the unit or its transport moves,
movement is possible even without the material)

(table material-lost-in-movement (worker concrete 10))

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)

A cell/border terrain could affect capture on/across it:
* capture-attack-terrain-effect u1 t -> n% 
* capture-defend-terrain-effect u2 t -> n%
If u1 on cell t1 tries to capture u2 on cell t2 across a border tx,
capture-attack-terrain-effect(u1,t1)*capture-attack-terrain-effect(u1,tx)*
capture-defend-terrain-effect(u2,t2)*capture-defend-terrain-effect(u2,tx)
are factored in the capture chance;
perhaps, if t1 and t2 are connected by ty, factor in tx effects only
if border-blocks-connection(tx,ty) is t.
(BTW, attack-terrain-effect and friends could also factor in
border effects.)

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.

I hope I explained this well enough...

Ciao,
        Massimo Campostrini