![]()
Version 1.8 by Leon Marrick (Leon2M@aol.com) assisted by Harlan Thompson (harlant@hawaii.edu) 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 found on the "Ultimate Civ2 Page", 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 referance - 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.
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!
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:
There are four ways that a unit with a movement of two or more can become obsolete:
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.
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.
In version 2.4.2 and earlier, it takes 7 steps:
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:
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!
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:
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:
(note that similar possibilities exist with land and air forces.).
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.
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 Tolkein'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.
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 removeable 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 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 follow. We will take them in turn.
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.4.2 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.
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:
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.
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:
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!
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:
"OUR WORDS ARE BACKED WITH SMURFETTES!"
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 catagory 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.
All units requiring the second tech will appear in the on-line help. They cannot ever be built, unless you allocate either tech to any civilization while setting up the scenario.
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.4.2 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:
-Only give that civ the tech, and give that advance an AI-value of zero. Although that civilization will always be able to build the unit, other peoples will also, if they get the advance in trade or diplomacy. See section 2b for more information.
If you want to ensure that, come what may, a certain civilization cannnot ever build a special unit:
-Give it the tech that makes it obsolete, and give that advance an AI-value of zero. If, however, civilizations that can build this unit discover this advance, or get it through trade or diplomacy, they will suddenly be unable to make more of these units, and computer players will even start debanding them. See section 2b for more information.
If your players use versions of the game later than 2.4.2, 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:
Impassable terrain (available only in some game designs)
If your game has no units that can attack air units, you can include impassable terrain:
(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.
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:
See section 7b for more information on barbarians.
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:
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:
Naturally all this terrain hacking will only confuse players if you don't alert them by changing the terrain icons.
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?
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:
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.
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.
Apart from rules.txt, the cities.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 rules.txt (not the scenario itself), 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 rules.txt (not the scenario itself), 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...
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):
and plenty more possible changes...
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.
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
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 Fantasy Worlds is not capable of adding barbarian units, but you can still create them manually.
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!
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.
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 indefinately 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.
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.
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.
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:
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!
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.4.2 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:
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:
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.
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.
When you are ready to playtest your scenario, take the following steps to polish your scenario, and avoid defeating your design:
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:
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 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 an mediocre program called Paintshop 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 "Paintshop Pro" or "pspro30". 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).
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.
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.
In Icons.gif are icons for:
Editing any of these is not particularly difficult; just remember to keep them the right size.
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.
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.
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 22 Mhz.
A list of what sounds belong to each unit position and type follows:
Swordfgt for land units.
Helishot for air units with no fuel limits attacking land or sea units.
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:
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.
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.
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.
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.
YAY! YOU'RE A DESIGNER!
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.
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 truely 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.
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 proceedures are followed.
Version Stamp: Ver. 1.8
|
![]()
There's more to Glyph Web than just Civ2. Take a trip to our home page for
interactive games and quizzes, Web authoring resources and plenty more besides.
|