John (or someone), please explain how automatic upgrades work in the fantasy game

[tobyr]

This question applies to the sci fi game as well as the ToT fantasy game. The strategy guide warns that the Wonder equivalent to Da Vinci's workshop is almost useless in the fantasy and sci fi games, and should be acquired just for the game points. DO ANY automatic upgrades happen? I would love to see a list, for each tribe.

Also, are the auto upgrades hard-coded in the game program? (I could not see them in rules.txt, but maybe I did not look hard enough.)Does the game code do the upgrades unless they don't "make sense" (create a creature this tribe can not build, or one that exists only on a different sphere, or upgrades a non-ship to a ship, etc...)?

It's a great convenience to get auto upgrades in the orignal game, but i consider this wonder too powerful; I don't mind if it soes less, I'd just like to know if it does anything.

While we're at it:
- the auto upgrades ought to be table-driven in the rules file (for scenario builders, etc.), AND there ought to be automatic DOWNGRADES as well (very useful for scenario builders).

- toby robison


------------------
toby robison
criticalpaths@mindspring.com

[John Possidente]

One of the things we asked for in our original design doc was a way to explicitly plan unit upgrades in rules.txt. Unfortunately, that was one of the new features that didin't make the cut (for various reasons).

The method the game uses to determine the automatic upgrades is one of the few things I didn't write down. (To be honest, I probably never fully understood it, anyway.) I remember that it has to do with the availability of a new unit with the same Domain and Role and better combat or movement numbers; if the existing unit is made obsolete by the same advance that makes the new unit available, that's a plus.

I'll try to get the programmers to explain it to me again, then report back.

[tobyr]

The bottom line seems to be that the developers were too clever by half in supporting upgrades. I assume the light has been seen for future versions of civ -- rules.txt should explicitly control upgrades.

Upgrading is a great GENERAL capability for scenarios, please genralize it as much as you can.

As sure as there are eggs and chickens, we should be able to upgrade to units with really different capabillities. The game should check, at the moment of upgrade, whether the new unit can exist where it is; if not, that unit misses its chance for an upgrade.

And, we should be able to downgrade as well. I hope that in the future, the @upgrade section in rules.txt will list something like this:

- the item that can be upgraded (or yes/no in its slot)
- the one or two prereqs for the upgrade
- what it becomes
- which types of tribes are allowed the upgrade
- which maps the upgrade can occur on
- whether to upgrade all such units the player has, or randomly only one of them

In some scenario, I'd love to see paladins downgraded to assassins when evil is discovered.


- toby robison


------------------
toby robison
criticalpaths@mindspring.com

[William Keenan]

from Leon Marrick's Advanced Scenario Design v1.8, which can be found on Platehead's site http://www.geocities.com/TimesSquare...iles/leon1.zip .

Unit obsolescence is not entirely controlled by the technology that the rules files says makes the unit obsolete. This is a source of problems for virtually all scenario designers, but the following should make your task far easier. See section 7e for how to confirm success in this area.

There are two ways that a unit with a movement of one can become obsolete:
1) discovering the advance that appears in the rules.txt file that makes it obsolete.
2) allowing the unit in the Musketeers position to be built. No defensive air, sea, or land unit, with a defense less than that of this unit, of any speed, can ever afterwards be built, by either a human or a computer player of that civilization.

There are four ways that a unit with a movement of two or more can become obsolete:
1) discovering the advance that appears in the rules.txt file that makes it obsolete.
2) If a better unit, in that same unit usage category (attack, defense, settle, etc.), that also moves at a speed of two or more is available. Applies only to ground units. Applies only to computer players. The computer player determines which units meeting all of these conditions to build, from among those you think it will, by looking only at attack and defense figures. Nothing else matters. A few examples (note that "5a/1d" means an attack of five and a defense of one) should make this clear:
5a/1d and 4a/1d: Only the first is built. It does not matter how much you want the AI to
build the second, or what extra capacities you grant either unit. You may only get the
second to be built by setting either unit (or both) to air or sea, making the units'
purposes different, or giving either unit (or both) a movement of one.

2a/1d and 2a/2d: Only the second is built.

5a/1d, 4a/2d, 3a/3d: works the same as 12a/1d, 3a/2d, and 1a/11d: all three are built,
as those units with lower attacks (it does not matter how much lower) have better
defenses (it does not matter how much better).

6a/2d, 7a/2d, and 7a/1d: Only the middle unit is built, because it has the defense of
the first without the poor attack, and the attack of the third without the poor defense.

3) allowing the unit in the Knights position to be built. No offensive air, sea, or land unit, with an attack equal to or less than this unit, a defense less than that of this unit, and a movement of two or more can ever afterwards be built, by either a human or a computer player of that civilization.
4) allowing the unit in the Musketeers position to be built. See above.

As you see from the above, this problem really isn't difficult to understand or avoid. Just be careful with the Musketeers and Knights positions and create similar land units with care.

To make it almost impossible for a computer player to gain a specific technology, and extremely difficult for a human takes 1 step in versions of the game later than 2.4.2:
1) set both prerequisites of that advance to "no". The tech cannot be traded or stolen.

In version 2.4.2 and earlier, it takes 7 steps:
1) either set the tech paradigm so high it becomes unfeasible (for all civs), or set the governments involved (for just a few) to fundamentalisms and change the loss of science to 100% and the maximum science rate to 0% (Section 5a).
2) This still leaves open stealing, so make certain no other civilization has anything they can steal, forbid them to make diplomats/spies, or ask the human player to respect a "house rule".
3) But, if they take a city, and you have not forbidden tech through conquest (in scenario parameters under the cheat menu), they will take any tech they like.
4) But they can still trade advances, so make certain they have nothing anyone else has any interest in (either no techs, or techs with a AI-value of zero) If you have the version with events, you can forbid them to talk with other civilizations. Humans are trickier: sometimes self-policing is the only answer.
5) They can still beg or demand advances, but you can probably fob useless techs with high AI-values off on them for the duration of the game, as long as the important techs are made undesirable (section 5b).
6) But they will happily learn new advances from goody boxes, until they gain Invention. Eliminate these.
7) Another possibility remains open: gaining advances through establishing trade routes. Either forbid them to make caravans/freight, or clear their current research project (effectively setting it to none).
The only way that remains open is a sudden advance through getting a unit in gift from a human player. This cannot be blocked, although self-regulation and adjusting attitudes works.

[John Possidente]

Sounds about right (and it seems like he's looked into it much more closely than I). Making the unit upgrades (or downgrades) an explicit part of rules.txt seems like a pretty good idea. Someone should pass it on to the Civ3 folks...