Advanced Scenario Design

Leon Marrick, assisted by Harlan Thompson and others.
Please see Credits for details

This manual is designed to assist those with both a firm understanding of the map editor and of the Cheat menu used in preparing scenarios to improve and polish their work. Novices are urged to read some of the excellent documents for beginners; and practice with a design or two before delving too deeply into this document.

This is a long essay, but not even close to being comprehensive. Additions are welcomed.

If you see a section reference - example "(Section 5a)" - that section of the document (in this case, the discussion of the rules.txt file's cosmic principles area) will have further information on the subject.

Listing of Subjects:

  1. How to tell a bad scenario
  2. A few handy tips and tricks (the quick guide)
    1. Controlling unit obsolescence
    2. Controlling technologies
    3. Controlling the civilizations that appear in your scenario
    4. Calendar reform
    5. Making pre-industrial cities look correct for all viewers
    6. Segregating civilizations into sea-going or inland nations
    7. Certain sections of the Cheat menu often confused
  3. Conceptualizing your scenario: Recreating geography, history, economy, military affairs, and politics
    1. Military, Economic, Scientific, or Diplomatic?
    2. Historical/derivative or fantasy?
    3. Length
    4. Scale
  4. Mapmaking: Getting the geography right
    1. Modifying off-the-shelf maps
    2. Making your own map
  5. The rules file: How to get what you want from it
    1. Cosmic principles
    2. Civilization advances
    3. Structures
    4. Wonders
    5. Units (including barbarians)
    6. Terrain
    7. Civilizations
    8. Miscellaneous information
  6. Brief discussion of other useful text files
    1. City.txt
    2. Labels.txt
    3. Game.txt
    4. Events.txt
  7. Creating your scenario
    1. Establishing basic rules and limitations
    2. Setting up civilizations and barbarians
    3. Creating, furnishing, destroying, and transferring cities
    4. The human landscape
    5. Mobilizing forces
    6. Science, economics, and industry
    7. International relations
    8. Polishing your scenario
    9. Playtesting
  8. Graphics
    1. Units.gif
    2. Cities.gif
    3. Icons.gif
    4. Terrain1.gif, Terrain2.gif
    5. People.gif
  9. Sound effects
    1. Units
    2. Structures and events
  10. Writing the readme and briefing
    1. The readme
    2. The briefing
  11. Packaging and distributing your work
  12. Listing of credits and citations
    1. "Advanced Scenario Making Ideas"
    2. Other sources of ideas
    3. Citations
  13. Distribution and Attribution

How to tell a bad scenario: The Seven Signs

Bad scenarios are two-a-penny; they seem to breed wherever not rigorously controlled. The following tip-offs seem like no-brainers, but how ubiquitous they are!

  1. An unfunctional scenario. The uploaded .zip file may be corrupt, or the Rules.txt file may have fatal errors. After zipping your scenario for submission, unzip it, install it exactly as your instructions say, and make certain it works.
  2. A garbled readme or scenario briefing. Nobody has any excuse for not spell-checking his work, or for not making certain his audience knows what the scenario is. Those writing documents in a second language had better make QUITE certain they are comprehensible.
  3. A map mostly consisting of grassland. Clear evidence of lazy cartography. Their efforts to plop down patches of woods, hills, plains, etc. merely amuse. Make very certain your geography makes the game either realistic (in historical scenarios), faithful (fantasy scenarios based on another's work), or amusing/fun/replayable (in your own imaginary realms).
  4. By-guess-and-by-God terrain alterations. I have seen mighty cities with wilderness hinterlands, cities with no water supply or irrigation, irrigation on swamps, mining in grasslands, city radii completely railroaded surrounded by utter wilderness, ... and so on. The terrain alterations each civilization is granted in your scenario says a lot about the economy of that culture. Properly used, you can recreate a living society for the amusement of your audience.
  5. Misspelled city names. Some people use an atlas in their native tongue when naming cities. This is good, especially in scenarios with protagonists speaking that language (There is a Catalan scenario that benefits greatly from this.). Others, whose own language may not be English, use English to attract a wider audience. This, too, is good, although extreme care is required. Some people can't seem to decide which language they are using. This is pathetic. Check out an atlas, and get a dictionary.
  6. No or inappropriate scenario limitations. I have suffered through scenarios that claimed to depict the Cuban Missile Crisis, only to get 10,000 Cubans on Alpha Centauri, scenarios based on the Pacific War that ended up with Zulus controlling Polynesia (when Tokyo fell, the empire split), and scenarios covering the establishment of the Roman Empire fought out with destroyers. Eliminate all ridiculous situations, except those you plan.
  7. Cities that riot, starve, sell off structures, etc. during the first turn. Make certain your players start out with working civilizations (unless you specifically warn them to expect otherwise). Always design in Deity level (and change at the last moment if desired).

A few handy tips and tricks

To make computer players actually make all the units you think you have allowed them:

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.42:

  1. set both prerequisites of that advance to "no". The tech cannot be traded or stolen.

In version 2.42 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.

How do I make certain the civilizations I want to appear in my scenario actually do?

  1. Go into the rules.txt file, pick the civilizations you want to appear in your scenario, change their names, leader names, attributes, titles, etc. to whatever you want.
  2. Then, make certain each civilization you want has a different color (help on this appears just above the civ list). Assign colors as desired.
  3. When setting up the game that will become your scenario, select seven civilizations (why all seven? Otherwise the colors available are chosen randomly!) and the "choose computer opponents" option under custom rules and choose the civs you altered.
  4. In making your scenario, destroy any civs not desired. Understand that they may come back into the game if an empire splits, so think about selecting the "don't restart eliminated players" option in custom rules.

You can create your own calendar (within certain limitations)

The key to calendar reform is altering the "Labels.txt" file. Near the very top of the list of words and phrases are entries for "A.D." and "B.C.". When displayed in a game, dates can read "10 B.C." or "A.D. 10".

Islamic dates are trivial: Simply change "A.D." to "A.H.", for anno hegirae.

You can create an evolutionary timescale by changing "B.C." to "million years BP". You can go back to the very beginning of life, should you desire.

Days of the month can be arranged, as long as the scenario ends before the month does ("January 45" looks odd): Change "A.D." to the month you desire.

With a little imagination, hours of the day also work. A scenario depicting Arnhem on the first day of Operation Market Garden would begin at "10 o'clock" and end at "24 o'clock" (military time).

I want to see a scenario about Revolutionary France with Years of the Republic and new-style months. That would be very cool.

Limitation of all dates

Because the largest number one can have as a starting year is 32767, the furthest one can go in the future is 32767 AD (using yearly intervals) and Dec, 2730 AD (using monthly intervals). After this point, if you use years, the calender switches to BC. and, if you use months, the calendar (months not affected) goes into reverse. See next section for a way to exploit this.

How to get months in the BC calendar

Julius Caesar died in 44 BC. You want your scenario to cover the ensuing chaos from March, 44 BC to March 43 BC, using one-month intervals. You cannot do this with normal methods, but a little number manipulation will get you what you want:

  1. Determine how many years BC (example: 44 years) your scenario began, and multiply that number by twelve (12 times 44 is 528).
  2. Bring up the cheat menu and change the starting year (in scenario parameters) to 65534 minus the number you calculated in step 1 (in our example, we would calculate that 65534 minus 528 equals 65006, and type in that number). Ignore any changes civ2 makes to the number you just entered.
  3. Set the monthly interval to -1 for one month per turn, -2 for two months per turn, etc., just as you would normally.
  4. Set the game turn (in the main Cheat menu) to 0.
  5. If you have it right, your calendar should be close to, but probably not display exactly the date you want. In our example, we now have a calendar that reads "Sept 44", but Julius Caeser got knifed in March. We have to subtract 6 months to go back to March, and therefore enter 65000 into the starting year.

As time passes, your calendar will add months normally up to Dec 44, then go to Jan 43. Welcome to the world of BC months!

You can make your pre-industrial cities look correct

As you will discover by using the "Cheat" menu to switch the human-controlled civilization, only one civilization in each game (the one initially chosen) is certain to have the correct pre-industrial city style if played by a human. You have to live with all of your cities looking like Bronze Age Monoliths if you do not play the initially chosen civilization. This can be remedied by:

  1. Making a copy of your savegame or scenario,
  2. opening up the file in Write (Do not use Word, etc.)
  3. changing the second character before each leader's name near the top of the scenario file to the ASCII character in position one for classical cities, two for far eastern cities, and three for medieval cities. Let me make this a copy-and-paste task for you by supplying you with the characters:
    • The character after this colon will yield Classical-style cities:
    • The character after this colon will yield Eastern-style cities:
    • The character after this colon will yield Medieval-style cities:
  4. saving the file in text-only format, with the "SAV" or "SCN" suffix left unchanged. Macintosh users may have to drag the resulting file to the Civ2 game, or restore the proper type and creator information.

You can segregate civilizations into those highly capable at sea and landlubbers by:

  1. granting the Lighthouse and Magellan's Expedition (with appropriate alterations to expiration dates) to favored civs.
  2. allowing favored civs the Nuclear Power advance (which can be renamed and repositioned on your tech tree) which makes ships go an extra square. A "Polynesia" scenario would give this to the seafarers, but deny it to the inland tribes.
  3. either granting the technology that permits Port Facilities to be built, or pre-building this structure in certain cities (you then even forbid more Port Facilities ever to be made, if desired). This is a powerful advantage, highly appropriate in a Napoleonic war scenario.

(note that similar possibilities exist with land and air forces.).

Certain sections of the Cheat menu often confused: What they really do

Change Terrain at Cursor

You may add any alteration to oceans that you can to land. Add the alterations first, then change the terrain itself to ocean. Although mining and irrigation never have an effect (no matter what the rules.txt file says), fortresses prevent units from dying more than one at a time, airbases still function, roads add an extra arrow for cities with the Superhighways improvement, and railroads add 50% to shields, rounded down (works with offshore platforms and King Richard's Crusade).

Edit King - Clear Patience

Makes that civ (if played by a computer player) open to diplomacy for a while.

Scenario Parameters - Calendar options

See "Calendar Reform" for further discussion.

Scenario Parameters - Toggle Total War Flag

If total war is on, the Senate is silenced.

Conceptualizing your scenario:

You have an idea. You want to make a scenario out of it. Think before you design.

Military, Economic, Scientific, or Diplomatic?

The only scenarios that should require nothing but military skill are those depicting battles. If your design permits it, and the scenario is of sufficient length, leave room for diplomacy, nation-building, and scientific/cultural changes and advances. Do this, and all sorts of players will avidly play your creation, not just conquer-the-world types.

Historical/derivative or fantasy?

There are two types of scenarios, historical and fantasy, with differing design requirements. People well-versed in history recreate a past with scenarios that seem to make it come back to life, and people with creativity do a splendid job of erecting new worlds. In between these two categories are those scenarios inspired by somebody else's creation, such as the Arthurian legends, or Tolkien's works. This distinction determines those areas of design your audience will grade your work on.

Historical scenarios must 1) show an initial situation that is true to history and 2) constrain the player in much the same way as the historical figures were. On the other hand, historical veracity should never, never get in the way of fun value or replayability. If strict fidelity is demanded, don't bother designing under CivII - it was never designed for such requirements.

Some of the most important questions you should have an answer to when creating a historical scenario are:

Scenarios recreating fantasy worlds dreamed up by another person should follow the same rules as for historical scenarios, except that it is more permissible to enhance the project with your own interpretations.

When coming up with your own world, you have complete freedom. Just make it fun to play more than once!

Length

The most important feature of any scenario is length in turns, because it determines the cardinal question any player of civ2 has to answer: Am I playing a wargame, or an empire building game? A scenario designer is in a position to decide this question for the player: There is no empire development during a battle (see the scenario "Gettysburg"), and almost none in a campaign. During a war (see the scenario "East Wind, Rain"), a certain amount may take place, and the re-enactment of a historical period (see the scenario "Imperial Pride") should allow a fair bit, but not enough to entirely alter the world. Should you want to depict the entire history of a civilization, development is central, and warfare merely among the tools of diplomacy.

Among the ways you can adjust the civ2 game to meet the needs of an expanded time frame is to:

It also should be mentioned that, the longer your scenario, the greater the chance for your audience to become bored. I have noted a fair difference between Europeans and Americans here - no guesses as to who likes what!

Scale

Few scenario designers make their maps too small. Know that large worlds:

Naturally, small worlds have the opposite effect in each case.

Mapmaking

Every good scenario starts out with a solid map. One can either adopt/revise an already existing map (I collect them for this purpose), or live dangerously and start from scratch. We will take each possibility in turn.

Modifying off-the-shelf Maps

If possible, go with a pre-existing map and save hours and hours of tedium. Don't hesitate, however, to modify it. In the scenario "Imperial Pride", an off-the-shelf map was tweaked quite a bit to meet various requirements. Among the revisions you should think about making are:

Making your own Map

You may also make your own map; a task fraught with peril, as many a sloppy effort demonstrates.

Reproducing a map (historical/alternate history scenarios that need a new map)

If you reproduce another map, use the following methods to start off right:

Drawing your map (all scenarios that need a new map)

Instead of drawing the shapes of your continents in plains or (worse) grasslands, use the most useless terrain type you can find (arctic works well in most cases). This helps you make complete maps, since it is difficult to ignore a blotch of arctic in the middle of a desert. First, get the basic coastline established, using a broad brush. Use a 1x1 brush to add islands, capes, bays, bulges, peninsulas, etc. Constantly check major coastline features against known landmarks (the first ones you will have to measure distance from are the corners of the map itself, and careful work will continually add others). Avoid simple coastlines, except when your map only covers a nation or less. It is amazing how interesting a few island chains, a peninsula or two, and some bays can make a continent. See if you have what it takes to make a second Europe; that is a deed worthy of praise! When your coastline is complete, toggle the "coastline protect" option.

Fill the map in with arctic. Add lakes. Chart rivers. Crudely establish mountain ranges/hilly masses. Once you have done all this, you have a solid skeleton to begin more detailed work.

The details

At this point, so varied are home-made maps that detailed guidelines would be worse than useless. A few regularities, however, do exist in the real world - and should occur in your renditions of it. Always keep the scale of your map in mind, since it will radically change what looks realistic to knowledgeable players.

Vary your terrain. Most mapmakers find it easy to plop down vast expanses of a single terrain type, make maps where endless plains meet great mountain ranges, and totally bore everyone who plays their creation. Design a beautiful world: add crags, fjords, buttes, pillars, fens, moors, valleys, glaciers.

Be wary of juxtaposing mountains and flatlands/ocean, and desert and arctic terrain/grasslands, except if your map covers at least a substantial portion of the world, and your terrain is very varied.

Since rivers cannot be made within the scenario itself, and are only removable there by changing the terrain to ocean and back to land again, place them with especial caution.

Unless you really want to deny water for irrigation, or do not plan for civilizations in that area to develop much, never leave too wide an expanse of map without some source of water.

This note will guide you in making terrain for nations you are fond of: The most productive terrain for a civilization is fertile (with grasslands), with patches of forest (for early industry) and some hills (to ramp up shield production). It must have plenty of sea access (including canals if possible), lots of varied resource squares (some peat or gold in the right place can do wonders) and might benefit from mountains (for protection). And some rivers (for canoe travel and increased trade), but not too many (it's hard to put bridges over the things). In short, if you want to do well by a civilization, give it a wide variety of terrain types.

Understand also that, important as terrain is for development-oriented scenarios, it is critical for wargames. It is surprising what a little rough terrain can do for a otherwise weak defense, or for units that would be too slow elsewhere. More on this in the terrain alterations section 7d.

The Rules file

The second most important file (apart from the scenario itself) to the designer is the Rules.txt file, which controls many of the variations you can make to the standard Civ2 game. For this reason, we will cover it in some detail. It is as well to have the default rules file open while reading this.

Starting at the top, we see some game and file information. Every message line begins with a semicolon, which means "ignore everything after me and before a return".

The Cosmic Principles

The cosmic principles follow. We will take them in turn.

Civilization Advances

Most scenarios benefit greatly from a customized tech tree. Not only can you control how technologically advanced a nation is, you can differentiate cultural biases and predilections. The scenario "Arabia Awakes" adds a lot of background color this way.

Basic warnings

The next section of the rules file allows you to alter certain aspects of civilization advances, and make your own technology tree. Be warned: simple errors here can take a lot of time to debug and put right (the messages the game puts out when it finds an error in the rules files are terse at best - and quite frequently nonexistent). After a while, most of my tech trees start to remind me vividly of rat's nests. On the other hand, the rewards for getting this section right are considerable. Type two/three-letter identifiers with caution and double-check each one. Do not make a technology loop (tech A needs tech B needs tech A).

General good ideas

To avoid a advance being traded or stolen (in versions after 2.42 only), appearing in the on-line help, or on the science minister's report, set its prerequisites to "no"s. To help avoid its being trading or demanded in earlier versions, give it an AI-value of zero.

Removing technologies from the tech tree

If you want to cut off technology at a level you consider reasonable, while still allowing advances, you must cut the links between techs you allow and every tech you don't want. This takes careful work. It is recommended that you back up your work at this point, consult the paper chart of technologies included with the full installation, star every tech you want removed (after the semicolon!), rename both of their prerequisites to "no", and use the in-game "Cheat Menu" option "Advance Tech" to guide a civilization, step by step, through your altered tech tree. Add the professional touch: connect your new tree to the advance "future technology".

Altering the tech tree

If you want to alter the tech tree, without necessarily truncating it, ever greater possibilities for disaster loom. It is strongly recommended that you draw your tree out on paper before hacking away at the rules file. Again, playtest using the above method. I speak from bitter experience; it took me an embarrassing amount of time to make my first in-house tech tree work properly.

The AI-value of technologies

You may alter how the computer player values advances in this section, which can be quite useful. In the scenario "Imperial Pride" the Traditionalists will ask for various useless techs, ignoring Industrialization until (I hope) long after the scenario ends. In "Arabia Awakes", computer players are made to act historically by the same method.

Special Technology Features

Take advantage of special technology features, based on the advance's position in the technology list. Apart from those allowing governments, changing pollution, changing demographic figures, or altering citizen icons (see section 8e), they are:

*NOTE: You may easily change Cathedrals and Temples so that they require different advances to construct, but I know of no way to change the technology that makes them work! Temples are useless until Ceremonial Burial and Cathedrals, until Monotheism (if Mysticism and Theology are not developed first). Oddly enough, Coliseums seem to work with no advances at all.

User Defined Advances

In addition to User Def Tech A, B, and C, plus those added in more recent versions of the game, one may use the "plumbing" slot as an additional user defined advance.

Structures

The only alterations to structures the rules.txt file allows you to make are those to the name, cost, maintenance, and prerequisite advance. Given the wide variety of effects structures have, this is quite enough to customize your scenario significantly. By controlling who can build what structures, for what price, paying what maintenance fee, you can fine-tune how expensive it is to:

  1. relocate your homeland (Palace).
  2. increase industrial production. Islands can be made great industrial powers with the help of the Offshore Platforms structure, possibly renamed to "Imported Raw Materials", or some such name.
  3. improve the economy (apart from the obvious structures, fundamentalist states can also build Temples, Cathedrals, and Coliseums to boost revenue)
  4. increase the rate of technological advance
  5. allow islands to support large cities (Harbors are extremely important in maritime scenarios, and one may sometimes desire to make them more costly.)
  6. reduce pollution (if you haven't simply eliminated it) and prevent global warming (Solar Plants).
  7. keep your citizens content
  8. allow a city to grow larger than a certain size
  9. defend cities (City walls may sometimes profitably be made more expensive, should you think a clever player would otherwise create an unconquerable empire. Be careful with SAM batteries; they make most air units obsolete.)
  10. increase food production (Supermarket), and increase the local rate of growth (granary)
  11. churn out veteran units
  12. airmail units from one side of the globe to another (airport). Be warned: clever players of your modern scenarios can get vast quantities of gold and science by airlifting freight units to distant airports, then railroading them to large foreign cities.
  13. increase arrow production (Superhighways).
  14. protect against nuclear attacks (SDI Defense).
  15. control corruption/make cities less easy to bribe (Courthouse).
Low-capacity Railroads

Since railroads allow any number of units to instantly travel to any square connected with them, I once used two airports, each renamed "Railroad Terminus", to simulate a low-capacity railroad (in the scenario "Arabia Awakes"). Note that units transported this way can be stopped by fighter planes, so (if you think it worth including the file), alter the "game.txt" messages to more appropriate statements.

Harmful structures

Is a civilization getting too rich for your liking (especially troublesome with fundamentalist states)? Give it a structure, with no other function in your scenario, that costs a ridiculous amount to maintain. AI players can't tell the difference, and human players can be warned/asked to respect a "house rule". Make certain the structure is impossible to build, or an AI player might just run its economy into the ground.

No known way to build unique structures

While units that can only be built by certain civilizations can be designed by setting the prerequisites of the technology required for them to be built to "no", this method does not work for structures, Wonders, etc., as these items require an advance on the tech tree to be built.

Wonders

Some scenario designers have gone one step further and customized their wonders. While structures take careful technology/prerequisite tweaking to yield benefits only to some civilizations, and offer the same benefits to any city (no matter how valuable or worthless you think that city should be), wonders are generally specific to a single civilization, and often to a single city. This can allow a small but industrious civilization to effectively compete. The following refresher will likely spark a brainstorm or two:

  1. make a civilization more contented (JS Bach's Cathedral, Michelangelo's Chapel, The Oracle, the Hanging Gardens, Cure for Cancer).
  2. make a civilization naturally grow faster than its competitors (the Pyramids).
  3. make a city a formidable trade producer, especially combined with high-tech structures (Colossus)
  4. make a nearly unbeatable maritime power (the Lighthouse or, to a lesser extent, Magellan's Expedition) For example, if one nation's fleets knew how to ride out storms and another's didn't, the first would be given the Lighthouse and the fleets in question made subject to loss at sea.
  5. make certain a civilization never falls too far behind in technology; useful for small empires you want to keep advanced (Great Library).
  6. make a civilization a conqueror's nightmare (Great Wall).
  7. simulate a warrior people (Sun Tzu's War Academy).
  8. create the "Workshop of the World" (King Richard's Crusade). Add this wonder to a Japanese city, for example, and the tiny island group can have a industrial presence equal to what it is in the real world.
  9. allow perfect knowledge of trade deals and wars among other civilizations, and maintain a fairly good picture of how well one is doing in the world (Marco Polo's Embassy, United Nations)
  10. allow a nation to get away with murder (Great Wall, United Nations).
  11. allow far easier establishment of new cities for a human player playing a civilization (Michelangelo's Chapel).
  12. in every city that doesn't need the normal effect, effectively permit a Democracy to field one army (two, with Woman's Suffrage), and a Republic, three, without unhappy citizens (JS Bach's Cathedral, because Wonder effects are applied after absent soldier effects) This allows you to set up a civilization with a militarily powerful, representative government.
  13. greatly increase knowledge production in a city/make that city more vital to the possessor civilization's science advance rate (In my version, 2.42, Copernicus's Observatory doubles knowledge production and Isaac Newton's College merely adds 50%. Is it the same for you?).
  14. make a city immune to disorder/allow it to field armies without happiness penalties under a representative government (Shakespeare's Theater) This is especially useful for planes and missiles.
  15. simulate a civilization that always has the finest military hardware (Leonardo's Workshop). Playtest vigorously if you change the units section of the rules file.
  16. simulate a civilization with an extraordinary cash flow (Adam Smith's Trading Co.). Note that this wonder is most useful for large civilizations, so use it carefully.
  17. recreate a sudden jump in science by a single civilization (Darwin's Voyage).
  18. allow a civilization entire governmental flexibility, if government switching is allowed (Statue of Liberty).
  19. force a sudden improvement in world opinion of a nation, or simulate unusually good diplomats (Eiffel Tower).
  20. make a representative government a far better conqueror (Woman's Suffrage).
  21. simulate the "Arsenal of Democracy" (Hoover Dam).
  22. turn your scenario into a nuclear lobbing, planet warming, all-polluting madhouse (the Manhattan Project).
  23. make a democracy much more likely to keep fighting (without using the "Total War" option) (United Nations).
  24. cause the entire map to be revealed after the beginning of the game, and (unless carefully controlled) make the primary focus of the game the space race (Apollo Program).
  25. make a civilization, especially a large one, gain advances far more quickly (SETI Program).

This list has been memorized by 90% of civ2 players, so why did I write it down? Answer: Unless you remove them from play, by either destroying them or setting their prerequisite advance to one no civilization will gain (such as "no"), your players will have to deal with the effects of any and all Wonders pre-allocated or built. I have played many a sloppy scenario that allowed all Wonders to be built, and sometimes even provided bundles of cash for the purpose. Control Wonders carefully!

Units

Most scenario designs require at least some alterations in the Units section of the rules.txt file, and many totally revamp it. Most designers seem to have made this area of their scenarios work fairly well, although some tips might help.

Effects of a unit's position in the list

Each position in the unit list is (always) associated with a icon and (in some cases) associated with a sound (see section 9a). A few also have special, unalterable features, including:

Number and type of units available

When designing units from scratch, try to give human players a reason to build each unit; the best attackers, best defenders, and fastest movers should either leave room for weaker units to compete in certain situations, or be very expensive. It is seldom necessary to give any civilization a choice of more than about eight or ten units to build at any one time. Unless you are careful, more than might confuse; players will pick favorites and build them exclusively. Units do not always have to improve or get cheaper as one advances tech. Consult the fascinating scenario "economy" for tips here.

If you want a civilization operated by the computer to build large numbers of a useful unit type, consider creating two or more units of that type with identical icons and capacities. Harlan Thompson does this to good effect in his scenario "Viking Age".

Unit Speed

See to it that units move at speeds appropriate to the length of the scenario and the scale of the map. Too fast, and the human player will stage a blitz. Too slow, and he will get frustrated. I am reminded here of a certain scenario covering the Saxon wars in 9th Century Britain. The map was big, every city had city walls, the roads were as bad as they were historically, and units moved at a snail's pace. A superb design, but dead boring. Ships (in particular) move quite rapidly in my scenarios to represent the extraordinary flexibility of sea power.

Unit Cost

Any buildable unit that costs over 300 shields can, in certain situations, be bought for negative gold. Try to avoid giving your players "money for nothing" this way.

Nuclear Units

Set the attack of the unit to 99.

Barbarian Nuclear units (plagues, famines, etc.) can also be included in your scenario, but (for some odd reason) do not function unless you set their usage category to "3".

Units that cannot move

Units that cannot move can serve as impassable terrain (with some designs), or fixed defenses (difficult-to-conquer mountains, etc). Note that any unit that cannot move can complete no action; if it is unfortified at the beginning of the game, it will stay that way. If not in a city, an AI player will immediately unfortify these units (it tries to move them), so do not give human players an advantage by fortifying them. If they start out in a city, these units can travel on ships between ports.

Submarines

Adding the submarine capacity to an air, ground, or sea unit has a number of effects - and opens up many possibilities.

Any submarine unit can be attacked by any unit that manages to find it, regardless of other limitations, except in three situations:

If you give an air unit the submarine capacity, it can attack sea and ground units over water, and no unit over land. If it has the fighter ability it can attack air units only over water. This makes it possible to make Torpedo Bombers that do a number on Battleships, but cannot influence affairs on land. Computer players do not use this unit at all well (they often end up stuck near cities). If this unit is over land, it generates a ZOC, making it easy to find with ground units.

Ground units with the submarine capacity cannot attack any ground, air, or sea unit, even when it claims it has the fighter ability, when operated by a human player. When operated by a computer player, they can. Since they generate a ZOC, they are also easy to find.

Naval submarines are more familiar. If you make all your ships submarines, you can prevent shore bombardment. Just make a lot of units able to see them and rename the "Navbttle" sound to "Torpedos".

Helicopters

Civ2 thinks all air units without fuel limits are helicopters. Regardless of unit position, these units may be attacked by ground and sea forces, can capture cities, and lose strength each turn when not in a city or airbase. If you want air units without fuel limits, but do not desire them to have all of these features, the best you can do is to set the number of turns they can fly without refueling to 250 or so.

Units that cannot be built, including unique units (generals, etc.)

Units that are only allocated at the beginning of the game and cannot be built can be implemented, by setting their prerequisite advances to one no civilization will get. There are two good ways to do this.

Do not set the advance that makes these units obsolete to anything other than "nil", unless you want the computer player to disband them when they discover that tech.

Units that can only be built by - or forbidden to - certain civilizations

In version 2.42 or earlier, because any advance can be traded or stolen, including those not on the tech tree, you have to decide what is more important to you. If you want to make certain a civilization can build a special unit:

If you want to ensure that, come what may, a certain civilization cannot ever build a special unit:

If your players use versions of the game later than 2.42, your task is far easier. Use either of the two procedures for making unique units, except that you would assign the advance needed to build the unit as you build your scenario.

If you want a civilization to have to research the advance needed to build a special unit, and you do not set their research project to this advance when setting up your scenario, then you would:

  1. insert that technology into the tech tree as you would normally
  2. give all other civilizations an advance that makes that unit obsolete.
  3. After doing this, change both prerequisites of the second tech to "no"s.
  4. Set the AI-value of the second tech to zero, so players with versions 2.42 or earlier are not too bothered by it.
Impassable terrain (available only in some game designs)

If your game has no units that can attack air units, you can include impassable terrain:

  1. create a unit similar to the following

    (name), nil, 1, 0.,0, 0a,40d, 10h,10f, 5,0, 1, (impossible tech), 000000000000000

    what this does is make an unbuildable air unit. Sadly, the computer is so deranged that any unit that can attack air units will attack any air unit, no matter how tough, blocking its way to a city. I field tested this idea with stealth fighters, only to see the AI make constant suicide runs.

  2. change its icon to that of some terrain and make its shield as inconspicuous as possible (see section 8a).
  3. place them where you want impassable terrain
  4. you may want to alter the message in the game.txt file that appears when a unit is told it cannot attack air units
Invisible units

See section 8a for more detail.

x2 defense versus horse

Is actually +50% defense against all units with a movement of two. Only seems to work using units with one strength point each (like pikemen); when I tried using units with more, I found that the attacker somehow manages to work around this ability as the battle continues.

Amphibious units

Are good to include if your scenario includes single-square islands with cities on them. The computer player uses both these and paratroopers better than it does most unit types, so adding them is AI-friendly.

Discussion of Barbarians

The only scenarios that will have no barbarians are those that allow them only for villages, then delete all the goody boxes. Otherwise, it is a good idea to know what barbarians appear when, to avoid Storm Deities or Star Destroyers from wiping out your infant civilization. The following information is adapted directly from the document "Advanced Scenario Making Ideas", by kind permission of Harlan Thompson:

Piratical Barbarians
Early Middle Late
Archers Crusaders/Knights Dragoons
Triremes Caravel Frigate
Frontier Barbarians
Early Middle Late Modern
Legion (villages only) Elephants (uprising only) Cannon Artillery
Horsemen (uprising only) Knights (villages only) Musketeers Partisans
Fanatics

See section 7b for more information on barbarians.

Altering Terrain

This section of the rules.txt file, coupled with graphics alteration if necessary, allows you to make any ten land terrain types you desire. There is only one kind of ocean; it is always impassable to land units and navigable by ships. You may control the defensive bonus of the terrain, the movement cost, and how many wheat, shield, and arrow icons the terrain produces before improvement, the difficulty and effect of land improvements, mining, transformation, and the most primitive government under which the computer player will perform any land alteration command. You may not (as far as I know) change how long it takes to build roads/railroads, whether roads adds arrows or not, and how interested the AI players are in making roads/railroads. Although ocean terrain may be altered to land, irrigating and mining it never have an effect.

Several Possible Terrain Types - to demonstrate the possibilities

A tactical-level depiction of Flanders, 1917 might do very well to include shell craters. Since there are no deserts in Flanders, we would change the desert terrain to:

Shell Crater, 3,1, 0,0,0, no, 0, 0, 0, no, 0, 0, 0, no, ; Drt

We now have a terrain useless for development, that cannot be improved, difficult to move through (cost: 3), and dangerous for defenders (1 => defensive strength is halved).

Head east to Russia, and Germans in April, 1942 would have to contend with mud. Since mud ruins roads, use a terrain that takes a long time to put a road over (Mountains or Glaciers would do nicely), and change it to the following (assuming we use Glaciers).

Mud, 2,2, 2,0,0, yes, 1, 5, 1, no, 0, 0, 0, no, ; Gla

This terrain is similar to grasslands without shields, but is a bit more difficult to wade through.

Allowing players of your scenarios to change coastlines

You have an idea: "What if I made a Dutch scenario that included reclaiming land from the sea?" or "What if I wanted to recreate the North Sea oil bonanza of the 1970s?" You can do this (although AI players will not take advantage of these opportunities) by:

  1. making it possible to change oceans to another terrain by some command (mining, irrigation, or transformation)
  2. In the scenario itself, putting a settler/engineer on a transport, and issuing the appropriate order every turn until the job is done. You can also make your engineers fly, or swim.

This method can also be made an effective way to simulate the release of pent-up forces, without using events. Although computer players will not initiate any changes to ocean terrain, they will continue actions that you start, if you make it reasonable for them to do so. So, twenty turns into a hard-fought war, an island full of reinforcements could suddenly develop a bridge...

This is followed by twenty land resources, two for each terrain type, and two ocean resources. You may tweak the defensive bonus of the terrain, the movement cost, and how many wheat, shield, and arrow icons the terrain produces before improvement individually. You may not (as far as I know) give Grasslands special resources.

Exact control of resource placement

Are you frustrated by the placement of resources on your map? One way to place resources as close together or as far apart as you like is to:

  1. remove all the resources of the terrain(s) you want to alter, by renaming it and reducing its bonuses to that of the standard terrain, and changing graphics accordingly.
  2. Give each of the resources you deleted their own terrain type. Clearly, there are early limits on how many resources you can afford to treat this way...
Creating unique resources

How would you simulate the towers of Barad-dur (Tolkien's work), the Al-Gawar field (among the biggest oil fields ever found on Earth), the Mountain of Silver (the fabulous Peruvian silver source that fed Spanish coffers for centuries), or the Cornucopia (the legendary, ever-abundant goat's horn)?

Rename a resource, alter its attributes as desired, place only one in the world, change its icon to something suitable, and make certain no settler/engineer can irrigate, mine, or transform any terrain into it. If appropriate, place a city taking advantage of the resource, or let explorers find it. How's that for an exciting exploration scenario?

Naturally all this terrain hacking will only confuse players if you don't alert them by changing the terrain icons.

Avoiding a Civ2 bug

If you want to forbid the transformation of terrain, do not set the terrain type that that terrain is altered to to "no". Have the terrain change into itself instead. See section 7b, "Adding rivers after you start designing your scenario" for why.

Civilizations

Many of the changes possible in this section of the rules.txt file can also be adjusted within the scenario itself. Some, however, can not.

The first section covers generic titles for the leaders of the seven government types. This is followed by instructions, then the actual civilization list appears. We will take each alterable feature in turn:

Miscellaneous tweaks

Good scenarios makers take care of the details. Altering the default trade goods to commodities more appropriate to your world helps convince your audience that they are playing a game worth keeping. The same applies to changes in orders, difficulty levels, and attitudes. Limit your names to roughly the length of the longest default one of that type.

Other useful text files

Although the most important, the rules.txt file is not the only useful text file for scenario makers. Others include "Labels.txt", "Game.txt", and "Events.txt". Some scenarios use other files; one could even change the menu text to be more consistent with one's design.

The versions of the game shipped with the "Conflicts in Civilization" and "Fantasy Realms" CDs make a number of changes to how certain text files are treated. Always include a copy of "pedia.txt" in your .zip file, because newer versions of the game use it to update the online information about units, Wonders, etc.

City.txt

Apart from rules.txt, the city.txt file is the most frequently found text file included with uploaded scenarios. Although safe and easy to modify, this file has a few quirks which are as well to cover:

The listing of civilizations is the same in Cities as it is in Rules. You change the city names for a civilization by scrolling to that civ's position, insuring that the noun form of the people's name is the same in this file as it is in the scenario (not the rules.txt file), and renaming the cities (as mentioned at the top of the file, count the number of characters you type carefully). Do not type certain characters, such as "&". Do not delete civilizations completely.

Unless the noun form of a people's name is the same in this file as it is in the scenario (not the rules.txt file), new cities will not be named properly.

After you have done that, and once your scenario is complete, you should then build a new city for each civilization and confirm that it is given the correct name. Odd how complicated that can be...

Labels.txt

NOTE: Lables.txt and Game.txt must be manually replaced in the Civ2 directory for those using the Conflicts in Civilization CD. Those using the Fantastic Worlds CD must remove them from the scenario directory before the scenario will run. Make certain you warn your players about this.

Open up the "Labels" file and scan down it. Among the items I can see a use for changing are (from top to bottom):

  1. "B.C" and "A.D". See section 2d for more detail.
  2. "Attila", the leader of the barbarians
  3. "River". One might conceivably change this to "Lava Flow".
  4. Various land improvements
  5. "Village", "City", and "Zoom to City". At least one scenario I know of (Aliens versus Predators) has changed these to "Colony" and "Zoom to Colony", etc.
  6. "wise men" - why not "wise women"?
  7. names of commands
  8. "Tithes". The Fascism Patch has altered this to "seizings".
  9. Various diplomatic messages and states. Some may not be appropriate.
  10. Names for ship parts. No one I know of has explored the possibility of building something other than a spaceship out of various parts...
  11. Words describing relative power and honor
  12. names of governments. I find it often helpful to alter these.
  13. "Top Five Cities" might be renamed "Top Five Colonies"
  14. "Ign. City Walls" and "x2 versus horse" are often not quite accurate

and plenty more possible changes...

Game.txt

This file controls most of the messages you will see throughout the game, from starvation notices to offers of gold and knowledge for peace. If you make extensive changes to structures and advances, you might consider issuing the "find and replace" command to replace all occurrences of a changed item. You can add a lot of realism to your scenario with a bit of imagination.

Events.txt

Sounds neat, but since I lack the Conflicts in Civilization CD, I know nothing about it. It sounds as though it'd be great for adding historical color and retaining game balance. I do, however, offer the following information about bugs and methods directly adopted from Harlan Thompson and Aleksei Andrievski's document "Advanced Scenario Making Ideas", or from further information by Harlan Thompson.

The length of the events.txt file is limited

After a given number of lines, the computer ignores all further instructions.

Be careful when subtracting money

The computer thinks that $100 minus $150 equals roughly thirty thousand.

The Command MoveUnit

Harlan Thompson knows of no example of this working.

JustOnce and random turns don't mix

You can make an event happen only once. You can make an event happen randomly. You cannot do both with the same event.

TurnInterval

Appears to be buggy.

Making Caravan Units

Not possible through events.txt

Ensuring that two civilizations remain forever at war

First, set the two civs you want to be at war, at war. Then prevent them from ever talking with this:

@IF
negotiation
talker=bloods
talkertype=humanorcomputer
lister=crips
listertype=humanorcomputer
@THEN

@ENDIF

And repeat with the two civs reversed (talker and listener)

Do not forget the blank line between @THEN and @ENDIF

Adding barbarian units

The events editor in Fantastic Worlds is not capable of adding barbarian units, but you can still create them manually.

Creating your scenario

Establishing basic rules and limitations

You have come up with a neat idea, made your map, and edited various text files. Now it's time to actually create the scenario itself. As you open the Civ2 program, and run through the various screens to customize your game, be aware that some of the decisions you make now cannot ever be undone, save by starting over with a blank slate. In general, choose the "Deity" level to build your scenario in - doing so makes you far more likely to make a functional civilization at any level of difficulty. As mentioned in section 2c, always choose seven starting civilizations to retain absolute control over which ones are included in the scenario. Barbarian activity should be non-existent for a Gettysburg scenario, but commonplace in a post-nuclear war scenario. Always customize your rules; these cannot be changed later, so choose wisely! In virtually all scenarios you will want to select the other civilizations, and often you would not allow spaceships to be built. If you wish to avoid civil wars (empires spitting up into factions), you would make certain that eliminated players cannot be resurrected. Scenarios using flat worlds are far more common than those with round ones. When the next screen pops up, in order to avoid the computer player building cities you do not want them to, always choose a civilization at the top of one of the three listings of civilizations - Romans, Russians, and Celts with the standard rules. This means you get to take your turn before any of the computer players can build cities in awkward locations.

Let's reveal the entire map and get busy!

Setting up civilizations and barbarians

Basic tips

Your scenario will require your players either to become generals, nation-builders, or both. This fundamental division decides whether you should focus on relative military or economic power. The best scenarios allow the player to choose several carefully thought-out civilizations, each requiring different skills to win with. If one is found too easy, another will then challenge and amuse.

As you make your scenario, you will often change the human player. Make certain the "Always wait at end of turn" option under the Game menu item "Game Options" is checked. Save constantly, always under a new name (I created 31 savefiles making "Imperial Pride".). It is amazing how much time one press of the Return key can waste...

If your scenario is lengthy, use the "Demographics" and "Tax Rate" screens extensively to make each civilization as powerful, progressive, populous, and prosperous as your design calls for.

Control real estate

The more opportunity your scenario allows for empire development, the more important it is to control uninhabited/undefended areas. If you give your players more than about a hundred game turns before the scenario ends, and permit them to make settlers/engineers, account for every square inch of real estate.

Goody boxes

Be careful with goody boxes. They can very quickly become the driving force in a scenario.

Exploration

If you do not reveal the world at the beginning of the scenario, you are faced with the lengthy task of establishing what areas each civilization has explored. If you must reveal large areas, create a temporary rules file with a unit similar to Helicopters, but with an enormous speed. To keep your civilization's casualty list accurate, prevent units from crashing during this process. Ensure that all cities, including barbarian ones, can see enough of their hinterland to feed themselves.

Setting up governments

Two schools of thought governing what governments should be assigned to civilizations compete for your consideration. The first requires you to give them whatever governmental type they had in reality. The other requires that you assign the civ2 government that corresponds most closely to your reading of that nation's economic, diplomatic, and military capacities. I recommend adopting the latter. If you do so, however, alter the "labels.txt" file (see section 6b), and the rules.txt file (see section 5f) to ensure accurate government names and leader titles.

Making certain that new Wonders can be built

Insure that Wonders are not counted as objectives.

A way to make sure that a specific city cannot produce Partisans when taken

Have it change hands as you build the scenario, since a city does not produce partisans when conquered a second time by a given civilization.

Adding rivers after you start designing your scenario

It has long been thought that rivers could only be created in the map editor. Now, thanks to LeMay and Harlan Thompson, this is revealed not to be the case. To create rivers:

  1. Open up the rules.txt file and change the base time for engineers to transform terrain in the cosmic principles section to zero (0). Also in the rules.txt file, temporarily change the terrain that all the terrains you plan to alter are transformed into to "no". After you have finished making rivers, change them back.
  2. Create three (or more on other terrain types. For example, mountains take eight) engineers on each of the squares you want rivers to appear. Lastly, create any unit of that civilization off to one side (see next step for why).
  3. Select the unit off to one side, and give it any order. This "initializes" the method, and tells the program that all future sets of engineers will be making funky terrain. Without using the mouse, issue the "o" (transform) command to engineers on the squares you want rivers to appear on as they start blinking in turn. As the third engineer on a desert, plains, or grassland square (or more on any other terrain) receives the transform command, the terrain will turn into a odd river/coal/desert combination.
  4. To restore the proper terrain type, simply use the cheat menu to alter terrain. All the funny-looking graphics will disappear, but the river will remain.

*NOTE: For a happy moment, I thought that this method could be exploited to create resource squares in any location I wanted. Sadly, my hopes were dashed (by various limitations and mismatched or missing graphics).

Barbarians

Because barbarian cities and units are a superb way to simulate minor powers and limit the undefended territory in your game, a few notes about them are in order. All this information is provided by Harlan Thompson.

If you're not careful, barbarians and their cities can be cheaply bribed. You have three ways to make them more resistant. Build Courthouses, Palaces (set these structures' prerequisites to "nil", then cheat-build them) to up the cost of bribing a city. Add money to the barbarian treasury (build and sell off structures) to make all cities and units more costly to bribe. Because barbarians throw their money around, use the events available with more recent versions of the game to top off their funds every so often. You can also raise the shield cost of barbarian-only units.

Barbarian cities can only make the unit that conquered them. If the barbarians own enough cities in your scenario, they will stop producing units to raid their neighbors. If this is a problem in your scenario, use the events.txt file (if your version has it) to make them appear every so often.

Barbarian units obey simple rules. Barbarian settlers found no cities and eventually disappear. Other land units wander around, searching for units to kill and cities to sack, whether wounded or not. If it finds a fortification, it will occupy it indefinitely and, if it is an attack unit, charging at all units that end their turn next to it. Sea units will never attack other ships unless they are carrying troops, or perform shore bombardment unless they have no other way to land their cargo.

See section 5d for a table of what barbarians appear when.

Creating, furnishing, destroying, and transferring cities.

Cities are the center of all scenarios other than those depicting a single battle. They are easy to create, and almost as trivial to destroy or hand over to another civ.

Creating Cities

Those unsure how to create cities are referred to a beginner's guide.

Furnishing Cities

Cities (even barbarian or primitive ones) can be quickly furnished with structures by using the "copy other city's improvements" under the "edit city" option and selecting a city you have previously set up. You may manually add improvements the civilization cannot construct normally by either setting the tech to build of the improvement to "nil", or temporarily giving the civilization the tech. Think about giving barbarian cities Courthouses or even Palaces, since they are easy targets for purchase otherwise.

You may give a civilization as many palaces at the beginning of the game as you like; this permits you to fine-tune corruption and waste, especially in far-flung empires.

In short scenarios, be very careful what improvements you give an empire that might be controlled by a human player; anything not both urgent and vital will be sold for cash. It is particularly inappropriate to give cities every possible structure.

Be stingy with airports on large maps, miserly with pollutant-reducing structures in scenarios that forbid pollution, tight with temples and the like to Fundamentalisms, and chintzy with Police Stations in cities controlled by non-representative governments.

Make certain you account for each and every Wonder. Either destroy it, allocate it (with or without making it obsolete), forbid its ever being made, or playtest games to see who reaps advantages from in practice. Try setting the prerequisite advance of Wonders you want to exclude to "no", rather than irreversibly destroying them.

Destroying Cities

A city may be destroyed by 1) reducing its size to one, 2) putting a weak defender in it (you can even get very clever and use a barbarian, to avoid cluttering up the casualty list), 3) switching the human-controlled civilization, 4) creating a attack unit of the second civilization and, 5) attacking the city. This is really helpful if you want to change the terrain under a city.

Transferring cities

Transferring a city to another civilization merely involves moving a unit of that civilization into the empty city. Make certain the city size is not zero or negative.

Creating barbarian cities, however, requires you to take at least two game turns to design your scenario (which means shields accumulate, civilizations interact unpredictably, etc.). Create the city and leave it empty. Create a barbarian unit of the type you want the city to produce next to it. When you are certain you are ready to end the game turn, do so and watch the city get conquered. Try not to have too many barbarians running around - it gets tedious.

Special notes on port cities

You can create a coastal city unable to make ships or sea improvements. You can create inland cities that think they are ports. How? The only time the game can realize a city is a port or not is when that city is created.

Special notes on cities of size zero

Unless you own it, or the entire map is revealed, cities of size zero are invisible. Units in such cities still generate a ZOC. Moving one of your units into such a town will generate an error message, but clicking "ignore" will allow the game to continue.

Creating the human landscape

This is an area often skimped on, yet it is of cardinal importance in every scenario.

In scenarios depicting a battle, campaign, or war, railroad links between cities should be thought about carefully. When you connect point A and B by rail, you essentially reduce the distance between them to zero. It's the equivalent of setting up a transporter room in each burg ("Beam me up, Scotty!"). Use roads, put units in fortresses, make barriers: in short, do something to prevent a skilled human player from romping all over his computer opponents. Same story with city hinterlands: Railroads make it easy to suppress partisans.

Apart from railroads, most scenarios would do well to add more alterations to terrain, simply in order to let the player know how prosperous, industrious, and advanced a civilization he commands. A cluster of cities surrounded by intricately worked homesteads sends a powerful message: so does a desolate, wilderness landscape. If the cities of a single nation are widely separated, you may have made your map too big.

The cost of changing the landscape should be carefully considered; you may raise it by increasing the cost of settlers/engineers and the amount of food they consume, and upping the time required to irrigate, mine, and transform.

Mobilizing forces

Number of Units

How many units you gave each civilization at the beginning of the game, and where they are located, can make a great difference to the pleasure your audience derives from playing your work. Playtesting is crucial here, since you may sometimes want to recreate Pearl Harbor - or create an initial balance of power. Since you can control the order in which nations move (see "Tidying your Scenario", below), there is no excuse for unplanned massacres on the first turn.

Be wary of creating too many units, for two reasons: Firstly, a skilled human player, given a critical mass of offensive units, can conquer any opposition. Secondly, excessive initial units leads to bloody stalemates between AI powers which, given that the computer is blissfully innocent of any offensive tactic other than "kill everything between me and my target city", does not make for exciting scenarios.

Fine-tuning Offensive Capacity

You may fine-tune the ability of an army to take the offensive in the first turn of the game by moving units off roads/rails, placing them far away from the action so they appear as reinforcements, and hitting the space bar to end that unit's turn (cannot move or attack first turn). If going first would otherwise be too great an advantage (no genuine tactical/operational surprise is intended), this last method makes for a far smoother, more realistic opening to a war. For example, if the Japanese go first at Pearl Harbor, most/all of their units should move. If the Americans get to go first (they have ten minutes to brace for disaster), very few of their units should move (a destroyer or two to kill the midget subs, perhaps, but no planes).

Pre-Set Go To Locations

You might often find it helpful to give units pre-set locations towards which they are to travel. I am, however, not certain that this is an effective way to get the AI to attack a certain city.

Confirming that computer players will build the units you want them to

In the Hints and Tips section, we covered how to make computer players actually make the units that you have given them the tech to. You find errors and confirm that you have solved this problem by:

  1. revealing the entire map (command found on the main cheat menu)
  2. ensuring that the human player is currently operating another civilization than the one you wish to inspect
  3. opening up a city window for that civilization, and confirming that the computer recognizes all the build options you think it should.
Unit Cost

And a last note: I know from bitter experience (correcting the first version of "Imperial Pride", playing bunches and bunches of other scenarios) that the most powerful/versatile units at sea, on land, and in the air are seldom made sufficiently expensive. Don't make this easy mistake!

Science, Economic, and Industry

Technology

This is among the most time-consuming areas of scenario design to get right. It is as well to think clearly from the beginning.

You can start off right.

With proper editing of the rules.txt file, you have all the tools you need to create civilizations with the exact mix of technologies you desire. When assigning advances to civilizations, avoid giving cultures you wish to keep relatively primitive technologies that advanced nations don't have. A human player can quickly defeat the scenario design this way. If you want to give primitive civilizations units advanced ones cannot build, set these units' advance-to-build to one all parties have, and the advance that makes them obsolete to one only some civilizations have. You may also give civilizations advances not on the tech tree, force them to develop a delaying tech, or set their research project to one they ordinarily would not be able to do.

Good luck staying that way... (only applies to those with version 2.42 or earlier)

However, you do not have any cost-free ways to keep civilizations from getting advances you do not want them to have. Any technology may be traded, stolen, or demanded, including those not on the tech tree. A list of suggestions to ameliorate the problems this game limitation may cause - and their costs - follows:

Money and Trade links

The majority of scenario designers shaft their hapless players with nearly unfunctional economies (some that could not even pay the bills, no matter how high one set taxes), then lurch over to the opposite extreme and give them a ridiculous sum of money to start out with. Given enough time, a human player in a modern scenario can totally transform his economy by massive investments in trade links.

By taking fifteen or twenty minutes to set a trade network, you can:

  1. Improve historical veracity, or make a fantasy world more full-fledged
  2. Give your players an economy that works, right out of the box, and
  3. If you calculate science advances and the cost of items based on this improved economy, make it less trivial for a human player to jump-start his empire.

Never neglect food caravans. For example, a scenario depicting the Atlantic in 1500 might have a city, representing the rich fishing off Newfoundland, supplying both Portugal and England with food. But there are downsides; not only do food caravans take food away from donor cities, they also use up valuable trade routes (I personally find this rather frustrating). The only positive feature of food and trade routes using the same slots is that you can deliberately crowd out new trade routes for provincial-minded peoples.

Sometimes, though, you just want to add food to a city's larder without setting up a food route (maybe you want it to grow rapidly). This can be done:

  1. Set up a temporary city of any civilization and set the human player to that civ.
  2. Make trade units next to cities to want to have full larders, set their home city to your temporary city and their load to food, and move them into the burg.
  3. To remove all the trade routes you set up, destroy the temporary city.
Industry

When designing a scenario of any length, careful attention both to the initial shield production - and the potential for growth - of each civilization will yield a balanced scenario that effectively accomplishes your original plan.

There are many ways to improve the relative industrial production of a small, concentrated civilization, including carefully placed resources, unique structures, certain Wonders, and a more highly developed hinterland.

Many scenario designers prohibit pollution, especially in tactical-level scenarios. This is not appropriate for most lengthy games, because it tames even a skilled human player, putting the computer players back in competition.

Note also that wealth is vital for both human and AI players' industry. Humans perform rush jobs by buying units or structures, AI players add extra shields every turn if (among other factors) they have money to spend.

International relations

If it is one area in which the computer players truly have minds of their own, it is in international relations. For a short game depicting a battle or invasion, it is generally appropriate to set the parties' treaty relations to "War" and "Vendetta" (which makes a player think the other has mounted a sneak attack). As time passes, though, only scripting events will keep them fighting. Hard as it is to get them to fight the foe intended, it is quite impossible (again, without events) to keep the computer players at peace with each other. I have frequently seen an alliance broken on the first turn, and a shooting war break out by the second. Even attitudes can change very quickly. Do your best; I have no silver bullets to offer (except possibly those available through events.txt).

Adjust reputations like the important things they are. The lower a civilization's reputation, the more difficult it is for a human player to accomplish any diplomatic goal. Throw realism out the window here, because this area is too important to gameplay to compromise. A reputation of zero is "spotless" and one of seven is "Atrocious".

Human player access to diplomats - and especially spies - must be considered, since they can guide forces around enemy ZOCs, investigate cities, steal tech, ruin city walls, and (the most devastating move of all) capture cities and every unit in it intact. Pre-allocate, price, and place these units with caution.

Polishing your scenario

When you are ready to playtest your scenario, take the following steps to polish your scenario, and avoid defeating your design:

  1. Make certain that all the players have the treaties and attitudes towards each other that they should. If you have made them engage in combat of any kind, or even allowed them to meet, your original settings may have changed (use the diplomatic advisor).
  2. Set the funds on hand to a reasonable quantity. Amazing how easy it is to forget this.
  3. Make certain that the rate of taxation covers the budget for all civilizations. Raise or lower as needed.
  4. See to it that no cities are undergoing riots (use F4). Check cities only when human-controlled - the computer player has very different rules governing unhappiness.
  5. Set the accumulated lightbulbs to zero, or another appropriate number (if you have created any trade links).
  6. Change city production to something reasonable (to lighten the load on your players), and make certain that no city can be easily conquered on the first turn, unless the scenario design dictates otherwise. See to it that no city has been ignored (so many scenarios I have played have size 1 cities that should be much larger, that the designer apparently forgot). Insure that computer players can build what you think they should.
  7. Set the map view to "No special view". No matter what civilization a player plays, he will then be certain to get the appropriate view.
  8. Set the human player to the nation you want to go first when the scenario begins. In a WW2 scenario in Europe, for example, the Germans should always attack the Poles, not the other way around.
  9. If your scenario has a fully revealed map, go into scenario parameters and select "Reveal whole map". This avoids the unsightly lapses in intelligence common to beginners' scenarios. If your scenario does not show the entire world at the beginning, update the display as appropriate by moving temporary units around.
  10. Double-check your calendar and your scenario parameters, save the game as a savefile (always do this, and use it when you want to make changes), then save the game as a scenario (you should never need to alter the scenario file once made. Just junk it if you don't like it and make another).

Playtesting

How long and how thoroughly you test your scenario depends on how proud you are of your work. The more effort you put into making the design a reality, and the more unusual/interesting features your scenario includes, the more time you should spend debugging. Search for the following common problems:

  1. AI or human player expansion into areas you think should be off-limits, or excessive empire development in a wargame.
  2. Rogue Wonders.
  3. Weird techs being developed
  4. Over-powerful units
  5. Any civilization with an economy, science base, industrial potential, or military strength that is too weak or powerful to fit your design. This is common with civilizations of widely varying sizes; tame the strong and enhance the weak, unless you plan for human players to try and win with the weaker power.
  6. A simple, brutally effective tactic that wins the scenario easily
  7. Excessive slaughter of units on the first few turns, or excessive capture of cities early in the scenario (or the opposite: a defense that exacts too high a toll in units and player fortitude).
  8. A game pace that seem to you too fast or slow
  9. the possibility of getting too much money through trade, selling infrastructure, conquest, or tribute

Always look for opportunities to add fantasy or historical color to your project. Expect to go through several rounds of scenario neatening, playtesting, and further alterations. Always keep your savefile (I call it a "template" file, because I can spawn off scenario files from it) up-to-date.

Graphics

Graphics really help involve your players in your creation. If you can, do your best to alter those that need changing, even if you cannot make them from scratch. Many, indeed most, people are not graphic artists; the following information is designed to help you get the job done with a minimum of fuss (if not always with the cleverest or most flexible methods). When playing with graphics, I use a mediocre program called Paint Shop Pro. I don't like it, I wouldn't dream of promoting it, but it does eventually give me the .GIF graphics I want. One may download a shareware version, good for 30 days before registration, from any number of locations; issue a search command for "Paint Shop Pro". If you are not capable of making decent pictures from scratch (I am not), don't despair. You can accomplish an amazing amount with a large graphics library, plus recoloring/cutting and pasting. Among the Photoshop features many find helpful, and would well repay learning about in the online help, are "resize", "color replacer", and the "magic wand" section tool with various tolerances.

When using other people's graphics, I strongly urge not merely retaining any signature present (most designers do this), but mentioning each and every source in your readme (so many neglect this responsibility).

Units.gif

After the scenario file and Rules.txt, Units.gif is the most frequently altered file that actually changes some aspect of the game. Open the standard file, and one will see 54 unit icons associated with a position in the unit list (of which the first 51 appear in the unaltered game), followed by the barbarian leader figure, some blank boxes, and two oddball unit pictures. Inside each light green-bordered box are magenta and grey (sometimes also appears purplish) backgrounds, and a unit icon. Bring up the palette, and you will discover that green, magenta, and grey(purple) are the last three colors shown; CivII automatically makes them transparent when displaying units on screen. The unit itself is positioned above the two lower edges of the magenta diamond in the center of the box; any parts of your icons that drool below them will be chopped off.

Be careful when editing the grey(purple) background, because Photoshop has a tendency to mistake it for straight grey, which is not transparent. Use the Copy and Paste commands, or simply use magenta for transparent areas (Photoshop never mistakes this color when using the standard palette). If you alter cities, use the foreign minister to quickly see if you have made a mistake in this area.

It is strongly recommended that you always alter a copy of the units.gif file, rather than trying to make your own graphics file from scratch. Avoids palette complications, for one thing.

Cutting and pasting icons is straightforward - except for one problem. Many collections of units have grainy purple backgrounds that were formed when one palette didn't quite match another. You have to manually replace any such areas with any of the last three palette colors, or get a odd-looking haze around any affected units when playing the game.

The blue dots in the green border lines above and to the left of each unit control the position of the top-left corner of the ownership shield. Make certain that the shield does not extend below the lower edges of the center magenta diamond. Confirm, as you play the scenario, that you can see enough of the shield damage line and the ownership color to easily determine the status of both (some custom units violate this rule, make certain yours don't). Keep the shield far away (five pixels minimum) from each edge to produce pretty unit movement and stacking displays. When selecting unit pictures for moving or copying, never include the bottom or right green border lines in your selection - you will mess up the shield positions of the unit's new neighbors.

Cities.gif

Most of the rules outlined above also work here, with the single exception that each city box has two dots, one orange, one blue, in both the top and the left borders. The blue dots control the location of the base of the flagstaff, and the orange dots the top-left corner of the number box that indicates city size. When using the variant modern city icons, try not to let too much of the population size indicator extend below the magenta diamond; a cropped number box looks awfully tacky when playing a scenario.

At the bottom of this file appear ownership flags (barbarians, then each civilization color in turn), icons for fortified units, fortresses, empty and occupied airbases, and two variant cities. You may alter the colors of civilizations by adjusting flag colors. Change the fifth pixel from the top and the fourth pixel in from the left on the top (large) flag to alter shield colors and the number box on cities, and the colored line above the top flag to change the color of city names and their display on the "world" window.

Icons.gif

In Icons.gif are icons for:

Editing any of these is not particularly difficult; just remember to keep them the right size.

Terrain1.gif, Terrain2.gif

Terrain1.gif, since it controls the appearance of all terrain except the foreground of mountains, hills, and forests, and all resources, is often altered. The left side of the file is taken up by four columns of icons, each controlling some aspect of every terrain; going from left to right, they depict one or two variations of the terrain in their row, and the two possible resources associated with that terrain (grassland has no special resources). Note that magenta becomes transparent. Some terrains' (forest, hills, and mountains) primary icons are located elsewhere; each of these has a background diamond shown instead.

You may alter how the appearance of terrain alters when it is irrigated, farmed, mined, polluted, railroads, has goody boxes or roads on it, or has a resource shield (for grassland). Modern scenarios, in particular, demand a rather different appearance for roads. All other icons are variants, included to expand your options.

Terrain2.gif controls the appearance of tile connections, rivers, forests, mountains, hills, river mouths, and the "softening" of coastlines.

People.gif

Controls the appearance of city dwellers in ancient times, after one's discovery of Invention and Philosophy (requires both), after one's discovery of Industrialization, and after one's discovery of Electronics. From left to right they represent joyous men and women, content men and women, unhappy men and women, angry men and women, entertainers, tax collectors, and scientists.

Sound Effects

Do your best to edit the unit list in the rules.txt file so as to require the smallest possible number of new sounds - they take a lot of time to download. All sound files are .wav 8 bit mono, at 22050 Hz.

Unit Sounds

A list of what sounds belong to each unit position and type follows:

Sound Unit's standard name, type, or event
(sounds have stars after them if they are associated with certain positions in the unit listing)
Aircombt Air units (not stealth) attacking other air units
Biggun Shore bombardment and naval battles, first part (played more than once if the battle lasts a while) for all units other than Destroyers, Cruisers, Aegis Cruisers, and Battleships
Boatsink a Trireme-type ship lost at sea
Catapult* Catapult
Cavalry* Cavalry, Dragoons
Custom1, 2, and 3* Unique sounds for extra units 1, 2, and 3
Diesel* Freight units
Divcrash A Fighter or Bomber shot down
Divebomb Fighter or bomber (not stealth) unit making a ground attack
Elephant* Elephant
Engnsput A fighter or bomber (not stealth) crashing through lack of fuel
Fire---* First part of sound for Cannon, Artillery, Howitzers
Helishot Helicopter
Infantry* Musketeers, Riflemen, Partisans, Alpine Troops, Paratroopers
Jetbomb Stealth Fighter or Stealth Bomber making a ground attack
Jetcombt Stealth Fighters attacking air units
Jetcrash Stealth Fighter or Stealth Bomber lost in combat
Jetsputr Stealth Fighter or Stealth Bomber crashing through lack of fuel
Largexpl Ship attacks, second part (if either side won easily, this sound plays instead of the second repetition of Navbttle or Biggun) and end of Armor, Cannon, Artillery, Howitzer sound effects
Mchnguns* Fanatics, Marines, Paratroopers, Mech Inf.
Medexpl Structure destroyed by diplomat or spy
Medgun* Second part of Cannon, Artillery, or Howitzer sound. First part of Armor sound. Repeats to end of battle.
Missile Any non-nuclear missile
Navbttle* Shore bombardment and naval battles, first part (played more than once if the battle lasts a while) for Destroyers, Cruisers, Aegis Cruisers, and Battleships
Nukexplo Nuclear weapon strike
Spysound Most successful diplomat or spy actions
Swordfgt* Warriors, Phalanxes, Pikemen, Legions
Swrdhors* Horsemen, Chariots, Knights, Crusaders
Torpedos All naval submarine attacks (land or air units not effected).

If a unit has its movement domain changed, the default sounds are:

Structure and Event Sounds

Sound Structure's standard name, type, or event
Aqueduct Aqueduct built
barracks Barracks built
bldcity New city built
bldspcsh Spaceship part built
cathedrl Cathedral built
cheers1, 2, and 3 All structures without a specific sound built
civdisor Civil disorder
druma0 to drumcy Various responses during negotiations
fanfare1-8 Starting diplomatic negotiations
guillotn Guillotine (when you conquer the world)
movpiece.wav Move a unit
neg1.wav Invalid choice (such as selling the Palace)
newbank.wav Bank built
newgovt.wav New government
newonder.wav Wonder built
pos1.wav Buying production
sell.wav Improvement sold
stkmarkt.wav Stock Exchange built

Writing the Readme and Briefing

The Readme

Every scenario should come with documentation, if only to prevent a player new to scenarios overwriting his original game files. If you write in a second language, take extra time to make certain you are clear. Do not write in Word format - use RTF if you want pretty effects. Readmes should contain the following information:

  1. installation instructions
  2. A brief description of the scenario theme and of the world the player is about to enter. You may write a short, effective blurb, then provide one or even several paragraphs of background information.
  3. A list and brief descriptions of changed units, structures, technologies, terrain types, science advances, and parameters
  4. Information on strange or unusual situations that might arise and frustrate the player (events intended to be surprises, obviously, need not be mentioned).
  5. Credits for pictures, sounds, ideas (if explained to you in, say, a readme or FAQ), and maps. Cite your sources!

Effective add-ons include design notes and scoring instructions.

You may also include a listing of the contents of the .zip file, if sufficiently complex.

The Briefing

A text file with the same name as the scenario will be loaded with it. Clearly and concisely written, it may whet your player's appetite. Anything above a paragraph (or blurbs on individual civilizations) should go in the readme. How to format this file so as to make it show up well on screen is not immediately obvious, so a few notes might be useful:

To insert spaces:

Add underscores "_".

To insert a return:

Press return, followed by a carat "^".

To center a line:

Add two carats "^^"

To bullet all text lines that follow:

Press two returns.

To add a unit picture

Select the unit type you want - with the left mouse button - and immediately save the scenario. Only works in the version of the game included with the "Conflicts in Civilization" CD.

To save time, modify a pre-existing briefing file.

Packaging and distributing your work

For PCs: These steps get the job done, but are intended for novice zippers only. Experienced people may want more control. Winzip is sufficiently simple as to require no explanation.

  1. Obtain a zipping utility. Pkzip and pkunzip can be located on the Internet by issuing a find command for either name in your Internet browser. You may also try Winzip.
  2. Rename all your text, sound, graphic, etc. files to prevent players unzipping your scenario into their main civ2 directory and overwriting all their standard files. DO NOT include a line in your readme that says in effect "Oh, now that you have already overwritten everything, know that you should have moved your files before unzipping this readme.". Outrageous!

  3. Collect all the files you want to bundle into a separate folder (I assume in the following command that you name it "newscen"), move that folder to the C: drive, and issue the DOS command:

    pkzip C:\newscen.zip c:\newscen\*.*

    Where you replace "newscen.zip" with whatever name (eight chars or less) you desire, plus ".zip". You now have a .zip file ready for testing and uploading.

  4. Test your zip file and documentation; do not skip this step. Set your civ2 game up as originally installed from the CD, move your zip file to either the Civ2 directory or your decompression folder and unzip your file (go back and repeat steps 2 and 3 if it doesn't work perfectly). Read your directions, and attempt to install and play your scenario by following them to the letter.
  5. If all this works, upload. Always include a one-or-two line description for the convenience of the site manager.

YAY! YOU'RE A DESIGNER!

Credits and Citations

While many of the concepts presented above have been collated through playing scenarios that made them work, or painful trial and error on my part whilst trying to implement a design, other ideas I learned directly from reading other people's works or by getting e-mail suggestions.

"Advanced Scenario Making Ideas" and Harlan Thompson's suggestions

Harlan Thompson and Aleksei Andrievski's document "Advanced Scenario Making Ideas" is the most valuable reference work I draw upon. The following topics include thoughts first found in, are inspired by, or are directly adapted from, sections in that document, or from extra tips provided by Harlan Thompson:

Other Sources of Ideas

Submarines

Michael Daumen's suggestions made it possible to comprehensively discuss their limitations, advantages, and effects. The scenario "Honor, Blood, and Steel" taught me about torpedo bombers, and Harlan Thompson warned me about them.

Impassable Terrain:

The scenario "Dagor Bragollach", written by Brian Reynolds, includes them, and my information on how to make them comes directly from the background file included with the game.

Briefing File Editing:

The scenario "Tokugawa" taught me most of what I present, and Allard Höfelt contributed the information on adding unit pictures.

Shield Placement:

Again, the scenario "Dagor Bragollach", whose creator mentioned that Harlan Thompson taught him the trick.

Several neat tricks with text files:

The scenario "Aliens versus Predators", created by Paul Heron.

Adding rivers once you have started making the scenario/how to avoid creating unnatural terrain

A post by LeMay on the Ultimate Civ2 message board explained how to create rivers and avoid the creation of unnatural terrain. Harlan Thompson turned this knowledge into a practical method and made it known to me.

Citations

"Dagor Bragollach", filename Dagor402 - The Battle of Sudden Flame - probably the most extensively rewritten scenario ever uploaded, this game is state-of-the-art in several ways
"Economy", filename economy - an highly inventive take on the modern business world.
"Aliens and Predators", filename avp20 - I know of no scenario/modpack that alters the CivII game quite so much, nor any designer with a better understanding of text files.
"Heptarchy", filename Heptrchy - A detailed but slow-paced scenario covering the conquest of Saxon England by Egbert of Wessex
"Catalan Scenario", filename Catars - an extremely effective depiction of the western Med in the 14th Century
"Honor, Blood, and Steel", filename hbs - Its map has the ugliest shorelines I have ever seen, but I owe what I know about torpedo bombers to it.
"Gettysburg", filename Gettysburg - this is about as good as it gets for Civ2 tactical warfare
"East Wind, Rain", filename ewind120 - a superb scenario that truly sets an example
"20th Century", filename 20thcent - an effective tour of our own century
"Viking Age", filename vikings - lets you truly understand what "preserve us from the Norsemen" really means.
"Imperial Pride", filename ImpPride - Leon Marrick's own scenario.
"Arabia Awakes", filename Arabia - Another of Leon Marrick's scenarios.

Distribution and Attribution

This file may be distributed gratis or at the cost of materials and distribution, in either text or hard copy, as long as it is left unaltered, and transmitted in its entirety.

Upon receiving the permission of the author, interested parties may convert this document into HTML format, add URLs linking to files on their site or any other, or add "editors' notes".

Any section of this document may be freely drawn upon or quoted, as long as standard attribution limitations and procedures are followed.

Version Stamp: Ver. 1.9
Edited by Mercator