Re: [Freeciv-Dev] How much is missing to make C:CTP clone

[Greg Wooledge <wooledge@xxxxxxxxxxx>]

Jules Bean (jules@xxxxxxxxxxxxxxx) wrote:

> Could someone perhaps outline how these work, for those of us who've
> never seen CTP?

That could take quite a bit of text....

> Stealth units are pretty straight-forward,

Sort of.  There are actually multiple groups of units.  Most units are
in the first (default) group, which can be seen by anybody.  Then there
are "subversive" units (slaver, cleric, abolitionist) which can only
be seen by units which have an appropriate flag.  The same goes for
"terror" units (spy, cyber ninja, ecoterrorist, infector, eco ranger);
"trade" units (lawyer, corporate branch, subneural ad); and the Submarine,
Stealth Submarine and Sea Engineer (which are in an unnamed "invisible
boats" group).

Subversive units can be seen by all subversive and terror units, and
by Diplomats.  Terror units can only be seen by terror units, and trade
units can only be seen by trade units.  The submarine family can only
be seen by other submarine-family units and by the destroyer family.

Basically, it's a lot of flags and code to check which units have the
right flags.

> but how do
> the the stacking and trading rules work?

Stacking:

Each tile can only have 9 units on it at any time.  Attempts to move
a tenth unit onto a tile will fail.  Units can be moved in groups (a
group moves only as quickly as its slowest unit, and must follow the
least permissive movement rules -- e.g., a stack of tanks and machine
gunners can't enter a mountain tile because tanks can't climb mountains).

This also means that a city may only have 9 defenders in it!
(Plan accordingly....)

Units have three combat strength numbers (or four, depending on where
you look).  The three primary numbers are attack, defense and ranged.
Machine gunners are analogous to Civ2's Rifleman unit -- they have good
attack and defense, but no ranged.  Cannons have good ranged attack and
lousy attack and defense.

All the units in a tile that gets attacked fight as though they
were stacked, regardless of whether you've explicitly stacked them.
In order to attack with a stack, though, you have to explicitly stack
units together and move them as a stack.

Combat between groups involves several steps:

 1) Units are divided into rows.  There may be up to three rows.
    The game tries to put as many units as possible in the rear rows,
    subject to the limitations described below.

    A) The first row may have up to 5 units.  The second row may have
       up to 4 units.  The third row may have up to 8 units.

    B) The second row cannot have more units than the first row.

    C) Non-military units will be placed in the third row, if there are
       military units in the stack.  Otherwise they'll be in the first
       two rows.

    D) By preference, the game tries to optimize the strength of the
       ranged combat strength of the second row.

    Example: if a stack contains 3 Cannons, 2 Musketeers and 1 Slaver,
    it will be divided as follows:

      First row: 2 Musketeers, 1 Cannon
      Second row: 2 Cannons
      Third row: 1 Slaver

    The slaver is a non-military unit in the presence of military units,
    so it hides in the third row (out of combat).  The remaining 5
    military units must be divided up.  These units all have ranged
    capability, with the Cannons being the better ranged attackers, so the
    game will put as many units (preferably Cannons) as possible in row 2.
    However, it can only put 2 units there, because of rule B above.

 2) The second row of each side fires at the enemy's first row, if it
    has ranged combat capability.  This may kill or injure units.

 3) The first rows fight each other until one side is devoid of first-row
    units.  (If one side lost all its first-row units during the ranged
    fire in step 2, step 3 is skipped.)

    This is somewhat subtle.  I haven't figured out all of the steps yet.

    This step appears to be resolved as a series of unit-vs-unit single
    combats.  However, this is unclear because sometimes multiple "hit
    icons" are shown on multiple units simultaneously.

    There are clear attacker and defender roles.  The units of the
    attacker initiate combat against units of the defender.  This means
    the attacker's attack strength is computed vs. the defender's defense
    strength, with appropriate modifiers (unclear).

    In a many-attack-one scenario, each of the attacking units fights
    against the single defender in turn, until the defender is killed,
    or all the attackers are killed.  (If the defender is killed by the
    first attacking unit, then no other attacking units enter combat
    during this step.)

    In a many-attack-many scenario, with equal numbers on each side,
    each attacking unit will face one defending unit, with one unit from
    each side dying in each of the mini-battles.

    Step 3 iterates in some way which is not clearly defined to the end
    user, until only one side has front-row units remaining.

 4) If one side is completely wiped out, stop.  Otherwise go to 1.

 Example: The attackers have 3 Cannons, 2 Musketeers and 1 Slaver as above.
 The defenders have 2 Pikemen and 1 Archer.

 In step 1, the attackers line up as above (first: 2M + 1C, second: 2C).
 The defenders line up with (front: 2P, second: 1A).

 In step 2, the 2 Cannons fire at the 2 Pikemen, and the Archer fires at
 one of the units in the attacker's front row (most likely a Musketeer).
 This should injure each of the three targeted units, but is unlikely
 to cause a death.  (The Pikemen will be more severely wounded than
 the Musketeer.)

 In step 3, the 2 Musketeers and the Cannon attack the 2 Pikemen.  If the
 defenders aren't fortified behind a city wall, this is likely to cause
 the death of the two Pikemen.  For the sake of argument, we'll suppose
 that one of the Musketeers (previously wounded by the Archer) also
 dies, which means the Cannon may have attacked and suffered injury.
 The defenders have lost their front row, but not their back rows,
 so we go back to step 1.

 Now we have (1 Slaver, 1 Musketeer, 3 Cannons) attacking (1 Archer).

 The attackers now line up with (first: 1M(wounded) + 1C(wounded),
 second: 2C).

 The 2 Cannons fire at the Archer.  This will probably kill it.

 Now that the defenders are all dead, the combat is over.  Some or all of
 the surviving units may be promoted to veteran status (the odds are 10%
 for each unit, independently).

 Since the surviving army contains a Slaver unit, a slave is generated
 and placed in a nearby city (rules omitted).

Trade:

Most tile types can have 1 or 2 different trade goods.  Trade goods are
scattered randomly around the map, just like the special tile resources
in Civ1/Civ2.

Trade goods never give anything but gold -- no food or production
bonuses.  All trade goods are worth 10 gold apiece.  (Tile output --
food, production, gold -- is generally inflated by a factor of 5 in CTP
compared to Civ1/Civ2.)

However, CTP uses a "monopoly" trade system.  If two or more of the
same trade good are collected in a city, the value of the second and
subsequent goods of that type increases linearly.  The first trade good
of a given type is worth 10; the second, 20; the third, 30; etc.

Thus, a city with 2 Crab trade units in its city radius being worked by
workers/slaves will bring in 30 gold per turn from the Crabs alone.

By building Caravans (pseudo-units), you can establish trade routes
between cities.  Trade routes are directional, with a source and a
destination.  They are drawn on the map as blue lines (with an optional
animation which I turn off).  The lines follow some "optimal" travel
route between the two cities, favoring water squares in the absence of
overland roads/rails/maglevs.

By sending a trade good from one city to another, the game acts as though
the trade good were being worked in the destination city instead of the
source city.  If Babylon is sending a Crab to Nineveh, and Nineveh already
has two Crabs from its own tiles, then Babylon generates no gold at all
from Crabs (unless it has a second one), and Nineveh generates 60 gold
(10 + 20 + 30) from the 3 Crabs it now "has".

Trade good income is treated just like raw tile output.  It's
multiplied by city improvements and the government gold coefficient,
for example.  (I've written about this in some detail, over at
http://apolyton.net/forums, but I'd have to search around to find the
messages.  I'm Gregurabi there, in case you couldn't figure it out. ;-)

When you build a Caravan, you simply add one to an integer which holds
your "number of Caravans".  No actual unit is created.  You use a special
popup window to create trade routes -- each trade route subtracts a
Caravan from your pool and is created instantaneously.

You may also establish a trade route with a foreign civilization.  I don't
know whether this requires a Caravan, and if so, whose.  The foreign
civilization must agree to it.  A state of war prohibits the formation
of trade routes between civilizations and also disbands all existing
trade routes between them (possibly returning Caravans to your pool).
Trade routes between civilizations always exchange a trade good for a
fixed amount of gold per turn -- the seller sets the price, which no
doubt influences the decision whether to purchase.  The typical asking
price is 20 or 30 gold.

Trade routes may be "pirated".  Military units standing on one of the blue
lines may click a special "pirate trade route" icon.  This destroys the
trade route (and usually the Caravan as well).  The identity of the pirate
may or may not be revealed to the player whose trade route was pirated.
(Remember, due to fog of war, you may not be able to see all the squares
through which your trade route passes.)  Pirating a trade route awards
some gold to the player doing the pirating (about 20 or 30, I think --
I don't even know whether it's variable or constant), and may take this
gold from the pirated civilization's treasury (again, I don't know).



(There.  Now you know everything I know about these two game features.
This is much, much more detail than the manual and the online help
provide.... :-( )

-- 
Greg Wooledge                    | Distributed.NET http://www.distributed.net/
wooledge@xxxxxxxxxxx             | because a CPU is a terrible thing to waste.
the articlehttp://www.kellnet.com/wooledge/ |