Playtesting Your Own Scenario

A guide to making sure that your scenario works as you want by giving it several 'dummy runs'.

by Cam Hills, assistance from Blackclove (May 1999)

Quality Control - A Necessary Evil!

So … you've put the finishing touches to your units, you've added a few clever events, and the technology tree contains a myriad of off-shoots and intertwining branches. Next step – post it onto the Web for everyone to enjoy!

Wrong!

Almost all but the blandest and unimaginative scenarios inevitably need some form of 'quality control'. To maximise the likelihood of presenting a high quality scenario, the next step is to play it several times, and pay heed to areas that don't work or put the game out of balance. If you have a few friends who are prepared to beta-test the game for you, so much the better – but don't rely completely on everyone else's advice – you must be your own harshest critic!

So – what to do?

Play your scenario several times

Play every tribe that you have recommended to be 'playable' or 'difficult' at the level of difficulty that you have recommended (and the first few turns on Deity to determine if this is feasible). If you have allotted tribes to be computer-only, you need not necessarily play these, however it is recommended to at least try them for a few turns to ensure they are not producing units or city improvements that they should not. Likewise, use the cheat menu to push a technology advance just to check that the A.I. tribes do not have access to technologies that they shouldn't.

Be warned, this is time consuming, however necessary, and may involve playing the game between half-a-dozen to a dozen times.

Ensure victory is possible, but not probable

As a rule of thumb, as the author of the scenario, you should through the play-testing process be able to reach (or nearly reach) the game objectives with different tribes with some difficulty. If you cannot come close to reaching the game objectives, or are regularly being decimated, perhaps the game is too arduous. Conversely, if you find that the game is 'a walk in the park' regardless of which tribe you play, then adjust the recommended difficulty level towards Deity as a first step. The game should be challenging, victory should be a formidable goal, but it should not be impossible to win or for that matter survive. Your own skill at Civ2 should be taken into account, particularly if you are not winning games at Deity level. Likewise, as the author you will be aware of the traps, the strengths, and likely winning tactics, so accommodate for this too. Most people will appreciate a scenario that is neither a hopeless cause, nor conversely an easy and effortless win.

Some tribes are usually easier than others. All that is required to 'tip the balance' is the placement of some important Wonders, some extra cash, or some agreeable terrain in the right places to put one tribe in a superior position. If there is a stand out, consider letting people know in the scenario notes or introductory text, or make further 'tweaks' to bring it back into line with the others.

Scenario authors often consider it important to add some strategic recommendations for the benefit of the 'uninitiated' player which will act to clarify the game objective or highlight key aspects of the scenario.

Common Design Slip-Ups

There are some traps that do present themselves as more prone to catching out designers than others. These tend to be either technical errors or playability imbalances. These are addressed in the next sections:

Technology

The technology rate is too liberal or too oppressive.

The rate of technological development, and the order of technology advancement will inevitably have a huge impact on the game. Further to this the attraction of certain technologies to the A.I. will add yet another dimension to the game's progress.

The rate and nature of technological development will be determined by numerous factors that include the;

Size of the empire and total 'beaker' output (potential as well as actual starting level),
Number of civilization advances already possessed,
Option of acquiring technologies through conquest,
Opportunities for developing trade routes,
Availability of diplomatic units who may steal technologies,
Ability to negotiate the exchange of technologies with other tribes,
Forms of government available,
Wonders and City Improvements that directly or indirectly affect the rate of research,
Computer tribes' capacity to receive a technological 'booster' via the game mechanism,
Technology paradigm.

Despite setting up a game expecting a slow rate of technological growth, by retaining a few inadvertent loopholes in the system, tribes may accelerate through the technology tree at an undesirably frantic rate as their nation grows. Two common resultant problems are; [a.] early access to particularly potent units, either offensively or defensively, and [b.] early access to advanced forms of government that may be suitable in the mid- to late-game of (standard) Civ2, however have a devastating impact on the balance of play in a scenario by opening the door to easy winning strategies.

In terms of 'real mess-ups', the scenario should be tested for;

Technology loops.

A loop is in this case simply two technology advances that are prerequisites for each other. The game's response is telling – "Crash!" If your scenario constantly crashes, yet your normal Civ2 works fine, this would be the #1 area of concern.

Unavailable technologies.

Special care should be taken to ensure that all technologies flagged for future research by a tribe can indeed be researched (or at least 'acquired' from another tribe). In its most apparent form, the absence of an entire branch of the technology tree may be conspicuous due to the misappropriation of prerequisite technologies. Unquestionably if obtaining certain technologies are required for obtaining game victory, it is of paramount importance that these necessary advances are prudently handled.

Available technologies.

Many scenarios are designed to quarantine certain technologies, particularly where the issue of unit creation is involved (e.g. a French Musketeer unit able to be constructed by the English). Ensure that special game mechanic technologies likewise are handled with prudence. Remember, any technology that is flagged with the prerequisites "no, no" will not be able to researched, stolen or traded – so special technologies once allocated should all be amended in the final phase of development to these 'non-prerequisites'.

This issue is compounded when multiple technology trees are developed, and care should be taken to make sure that a nation cannot leap over to another tree from which they were never intended to have access to.

This problem can be done in games that do allow spies, broad diplomacy, or tech' by conquest through using a 'give technology' event for each quarantined technology (requires Fantastic Worlds or better).

Double-check all technology slots for their effects (a few examples — Mysticism increases the effect of temples, Communism decreases the effect of cathedrals, Trade allows you to determine the demand commodities of visible cities and supply commodities of your own, Gunpowder makes some unit slots obsolete while adding to the cost of barracks). Are these all in their intended places?

Unit Slots

Special effects.

Be aware of the significance of the unit 'slots' — that is their positions in the list of units;

Engineers (can terraform land, more effective than settlers, text window)
Fanatics (convert to riflemen in mid-production once Fundamentalism is no longer the government)
Knights (may make some unit slots obsolete)
Paratrooper (text window)
Nuclear Missile (changes diplomatic message)
Spies (additional functions, more effective than diplomats)
Freight (more effective than caravans)
Guerrillas (may appear following the capture of cities)

Sounds.

n order to avoid duplication of unnecessary sound files, attempt to maximise the number of units using the same sound by allotting them to the appropriate slots. For instance, swordfgt.wav uses the Warrior, Phalanx, Pikemen, and Legion slots, so wherever practicable, units with this sound file name should be allotted to those slots, rather than an alternative approach using the user-defined slots and duplicating the sounds with the same customised noise expressed such as custom1.wav and custom2.wav (this assumes that there is no other reason for this latter approach). Also see the Sounds Map section of these Design Tips.

Due to the sheer size of including customised sound files to scenarios, authors often ignore sounds completely — if this is the case and units are non-standard, then advise in the 'read me' or introductory text that sound effects should be turned off.

Finances

Cash flow deficits

Ensure that tribes are not confronted with cash-flow deficits from the game's outset unless this is of clear intention. There is nothing more frustrating for a player than having to sell off city structures, have taxes set at maximum, employ tax collectors, and convert all unit production to trade units in order to just maintain a game's viability as measures to combat financial difficulties possibly resulting from poor scenario design. This is exacerbated when alternative government forms are denied to the player. Often this predicament may be the result of the author wanting to present realistically large cities flush with appropriate city improvements, however giving little consideration as to how these were to be paid for.

Too much money

The easy availability of cash may also have a detrimental effect on scenario balance. This may come in various guises, however [a.] access to the Fundamentalist government, [b.] ludicrous rewards through the 'changemoney' event, and [c.] an improbable starting level of funds, are three of the more likely culprits that lead to imbalance in this manner. This may materialise in the form of lots of bribery, huge swings in the tax schedule leading to massive growth through 'We Love You Days', or speedy purchases of armies or Wonders.

Wonder – Improvement Duplication

Occasionally scenarios have city improvements placed, followed by the corresponding all-encompassing Wonder being granted afterwards (such as; granaries and The Pyramids, or cathedrals and Michalangelo's Chapel). While this means that the civilization in question is not reliant on the Wonder-city being a part of the empire, there is an effective waste of finances on upkeep of unnecessary city improvements captured (depending on the maintenance costs, and Adam Smith's Trading Co.).

Level of Difficulty

Consideration as to the recommended level of difficulty should be done carefully, and playtesting should be done at that level to the point where victory is possible but not probable. There exists a truism that all scenarios should be developed at Deity level, and then switched to the desired level of difficulty as a last action if an easier level is more appropriate.

Clearly setting the levels of difficulty will not only have an impact on citizen happiness (which may be modified in the global settings), but other significant factors will be affected including the A.I.'s handling of;

Production schedules (relative number of shields required for completion of units or improvements)
Scientific development (relative number of flasks required for next civilization advance)
Growth (relative amount of food surplus required for next citizen)
Diplomatic activity
Nuclear activity
Attitude (including willingness to initiate sneak attacks)

Events

Thankfully Civilization II comes with the 'debug' facility or Event Parsing Debugger (EPD), and should be used whenever changes are made to the events file. Typically you will know when something is amiss, because when playtesting the game an 'error' window will appear if there are any problems with the events file. You can never be too careful, and it may be worth your while just running it once you believe you have finished with the events file. If you are unfamiliar with this process, simply add the line '@DEBUG' under the line '@BEGINEVENTS' at the head of the events file.

There's no more effective 'litmus test' to the productiveness or value of the scenario events than playtesting. In most cases you will be able to notice gameplay rather than technical flaws in the events file through playtesting. Some things that might slip by the EPD but become apparent in the game include;

Technologies that do not provide the intended benefits or effects once received, be that access to a unit type, city improvement, government type, or as a technology prerequisite,
Units that are never placed, or placed in an unintended area,
Technologies received by an event that should not be tradable, but are traded,
Units that do not attack that should,
Terrain that was intended to be changed occurring in the wrong place or with the wrong terrain type,
Terrain changes involving ocean that causes problems with either land or sea units,
Terrain changes that decimate cities,
Bizarre effects caused through the 'change money' event,
Tribes split into two when they should not,
Repeating events that should not occur,
Excessive frequency of text windows,
Events that occur on a turn not being the intended turn,
Sound files that do not initiate when they should, or are the wrong sound,
Tribes that negotiate when they should not,
Spelling or grammatical errors in text boxes.

Units

There are a few traps relating to units which all should become apparent in playtesting;

Image

Three stand out;

The unit's shield is concealed, or partly concealed, which makes identifying the tribe or the unit's "health bar" difficult if not impossible. Occasionally this may be deliberate, but in most cases not. For aesthetics, the unit may be technically visible but placed in a zone which does not, for whatever reason, appear to work well — such as the shield being at an extreme distance from the unit image itself.

The unit has an unusual grey 'shadow' or triangular blocks around it. This indicates that during file manipulation the background colour in units.gif has gone a little astray and these 'blocks' should be refreshed / refilled with one of the default transparent colours in the Civ2 palate (pink, lime, or plum colour).

The final possible difficulty may be that somehow through manipulation of the rules.txt file or the units.gif file, your graphics have ended up in the incorrect slots (mismatch between the two files).

Technology difficulties

Which also tend to come in one of three forms;

Firstly, the prerequisite or obsolete technology is wrong, which may result in the wrong tribes producing the unit in question (referring again to the French Musketeer being produced by the English), the unit coming much later in the game than had been intended, or incorrectly upgraded to a less potent or inappropriate alternative unit (particularly apparent should Leonardo's Workshop be a built Wonder).

Secondly, the unit has appeared in one of the 'special unit slots' (Fanatics, etc.) leading to unusual or detrimental effects. For instance, a fantasy-based scenario may erroneously have 'Demons' in the Partisan's slot, only to have half way through the game five Demons coming to the aid of the 'Forces of Light' tribe who had just lost the city of 'Elysian Fields'.

Thirdly, and least likely, the unit has been given the wrong role (settling, trade, sea transport, etc.), where you may find strange effects such as 'Patriot Missiles' building cities.

Excessive or unreasonable abilities

This problem most often occurs with specialist units in historical scenarios (such as Generals, Kings, or Popes), or large monsters in fantasy scenarios (such as Dragons and Giants), where they possess offensive or defensive statistics out of synch with the rest of the scenario.

The most compelling exception to this rule is when a tribe is deliberately set up never to be conquered, a unit with exceptional defensive characteristics may be stationed in the tribe's Capital.

In short, if a unit is supposed to be strong but fallible, do not provide it with invincible statistics, or the player will be frustrated through lack of game balance, one way or the other.

Likewise, going overboard with unit ability 'flags' can lead to balance problems that may show up clearly in playtesting. For example, by giving a ground unit both 'Alpine' and two-move ability, it can create a 'synergistically' better unit. By taking the ability to easily find a defensively strong position away from threatening areas ('Alpine') and launch an attack from a distance with no movement loss in most cases ('two movement per turn') the unit may become a veritable 'killer' given a reasonable attacking level. It can be at some range from its target one turn, yet act to strike it the next turn from three spaces with no movement penalty. The unit admittedly will be prone to the countering "x2 on defense versus horse" flag, but still it presents itself as an efficient assailant. If it were also to receive other abilities such as "negates city walls" or "ignore zones of control", this matter is compounded.

In short, take care with any units that have extraordinary attributes in terms of either strength or abilities. Playtesting will often highlight abnormalities here.

Wonders of the World

The selection and placement of Wonders of the World in scenarios is usually well considered. Scenario developers should be wary that some Wonders have far-reaching effects in scenarios, often more potent than in the standard game. Six Wonders of the World to be particularly mindful of are;

Statue of Liberty

Ensure that all government forms are relevant and appropriate. For instance, early access to Democracy tends to encourage the stockpiling of wealth and rapid technology development. Once an A.I. tribe takes up Fundamentalism, it is far more prone to engineer sneak attacks which may be counter-productive to the theme and the tribe's intended role.

Leonardo's Workshop

Consider the various upgrades that will take place if a tribe is given Leonardo's Workshop. Two criticisms of the default game's upgrades were that the conversion of Caravels to Galleons took a unit with an attack value and replaced with a transport-only craft, while a veteran Knight was of more value than a non-veteran Dragoon. Scenario authors should check that any intended upgrades through this mechanism allow units to lift a significant step in terms of potency and ability (n.b. some scenarios use this mechanism in reverse to downgrade units).

The Manhattan Project

Be very aware of the influence of nuclear warfare on the game. At higher levels of difficulty, and with A.I. access to Fundamentalism governments in particular, nuclear warfare may become the principal determining factor in the game's outcome.

The Apollo Program

Will reveal the map, even under 'bloodlust' conditions.

The Hoover Dam and The S.E.T.I. Program

Both extend global effects to a civilization that can significantly distort a tribe's relative potential strength.

Notes could be made on each of the Wonders and their likely effects on scenarios, but these six in particular should be carefully taken into account and will demonstrate their effects through playtesting.

City Improvements

Be mindful that there is a sequential order for some city improvements (such as the progression of library to university to research lab). Likewise the effectiveness of the temple and cathedral city improvements require the tribe to have the Ceremonial Burial and Monotheism advances for these to have an effect on the city in question.

Relations

Playtesting is an effective tool to double-check tribes' responses to each other and their diplomatic arrangements from the outset. A quick mechanism to ensure that things start off well is to review the Foreign Minister's Report to confirm that;

tribes that should be in contact with each other in fact are,
their attitudes (worshipful, enraged, etc.) are appropriate to the theme,
their diplomatic status (peace, war, allied, etc.) is again appropriate to the theme, and
the reputation (spotless, atrocious, etc.) is fitting.

An awareness of how the A.I. operates in this area and how as an author you may guide the direction of your scenario will be an advantage when setting up this aspect of the game. To illustrate, usually the second strongest tribe is resentful of the first, and if it has a poor reputation, a strong army, a fundamentalist government, and the game is played at the harder levels, it will probably engineer a sneak attack not long after the game begins — regardless of the intended theme. This should be borne in mind when establishing the setting and problems may become apparent under playtesting.

Barbarian Activity

During playtesting, you may gauge how effective the use of Barbarians has been in your game (if you have included them at all). Some thought should go into why the Barbarians have been added, and an evaluation of the usefulness of this role can be made. Are they too strong? Too weak? Too numerous? Too passive? Excessive presence of Barbarians can become wearing for the player, proving to be a fruitless obstacle in getting to the heart of the scenario objectives.

Barbarians generally appear in the scenario due to four mechanisms;

Goodie Huts
Random Creation
Present at the start of the Game
Created by an event

Most scenario authors opt to turn off Barbarian activity and remove all Goodie Huts from the outset, often however including Barbarian Villages or randomly creating Barbarian units via events.txt.

Care must be taken to ensure that the appropriate slots are taken into account should you choose to retain Goodie Huts or select another option in the set up other than 'Barbarian Activity > Villages Only'. The last thing you want is eight Barbarian "George Washingtons" popping up when the player enters a Goody Hut!

The usual warnings regarding excessive unit statistics or abilities apply equally, if not more so, when dealing with the 'difficult to control' Barbarian units.

Also see the Scenario League's Design Tip - Fun with Barbarians

First strike

Some scenarios feature a large number of units poised to strike at the game's opening. It may be of significant advantage in these cases to be the tribe that has the earlier turn, so you may decimate the enemy's own pending offensive before they have had the opportunity to move, or in some cases even fortify their positions.

In some games this may be deliberate (for example, allowing the Japanese to attack Pearl Harbor), however in others it may significantly and unfairly benefit one tribe over another.

Duration

Playtesting will further help to assess how sensible the game duration is — this is particularly apparent with historical scenarios where effort should be made to tie the scenario in with relevant events, rather than fictitious games where the era is imaginary.

The 'clock' may play an important strategic role in the game that intertwines with the game objective and / or the events file by adopting a considered approach to time. Alternately, a 600 turn clock is almost as effective as having a limitless game duration — which may be appropriate in some cases.

Thought should go into the extent of the technology tree and how this relates to the game's duration. Players often find that they have covered all useful research options only part-way through the game, and may choose to redirect their taxes entirely away from research. The impact of the extra income or happiness may have an unbalancing effect on the overall game.

Map

Playtesting provides a good opportunity to review the extent of the map that has been revealed to the tribes, by intent or accident, and how this disclosure integrates with the theme. Consider the effect of the Map Making advance and the opportunity for tribes to exchange maps — is there potential problems stemming from shared maps?

Additional files

'Read me' file

There is little excuse for not including a 'read me'-style file in the scenario package which offers technical elaboration, thematic reinforcement, and general observations by the author on their creation. The 'read me' file should be written, or at worst checked as one of the final tasks of the scenario's development. It may be all too easy to make reference to a 'Gunslinger' unit in the 'read me' only to later decide to change the unit yet forget to update the change in the supporting explanatory document.

References to suggested strategic approaches may deserve some rewriting after serious playtesting has occurred. What may have seemed a good line of approach may all too quickly appear to be flawed or ineffectual.

Also see the Scenario League's Design Tip on 'read me' files.

Pedia.txt

This file should be included in the zipped package, whether it is author-amended or not. This file allows players using the Fantastic Worlds version to use the Civilopedia for the scenario, rather than being referred instead to the default game's Civilopedia. This file too may be amended. Through playtesting the scenario, you may ensure that firstly the pedia.txt file has been included correctly, but also it will highlight which units and city improvements are available during the progress of the game. Any aspects that have 'snuck into' the game by mistake may be clearly seen by checking the Civilopedia.

City.txt

The inclusion of a modified city.txt file should be mandatory except for games where new cities cannot be founded (absence of 'settler' units) or games based solely on a selection from the tribes covered in the default file (including the Arabs and Incas). Test each tribe for the name of the first city that is founded once the game has commenced. Often the game will assign a name that is partially down the list and not necessarily the first name on the respective tribe's list, and therefore this should be accommodated by a technique such as inserting a number of dashes commensurate with the number of city names skipped.

Advice.txt, Labels.txt, and Game.txt

Minor modifications to these files can alter the manner in which the features of the game are referred to (e.g. changing 'Barbarians' to 'Natives') or the way text boxes articulate game messages. Rarely do changes to these areas cause real problems, however playtesting may identify some mistakes. See the Scenario League's tip on amending advice.txt.

Alternate files

The inclusion of alternate games permits the player to undertake the same scenario with some variations. This technique may be well demonstrated in games where the map is not fully revealed, and there is some opportunity for exploring and finding unusual units, cities, or terrain. Playtesting will assist in double checking-that these varying versions of the scenario have been correctly included.

Multiple files

Likewise, ensure installation of any multiple files is effective and works to the intended design. For more on this creation option, see the Scenario League's Design Tip on Multiple Files.

Old files

Backed up files such as automatically saved games from the playtest process, and backed up versions of events or rules files, or any other odd files should not be included in the zipped package once the author is satisfied that the scenario is ready for distribution.

Overall

Playtesting also provides the opportunity to assess the scenario from a more objective viewpoint. Even though there may be no technical, playability, or thematic problems with the game, it does allow the author to judge whether the game was fun or intriguing to play, and allow for a period of reflection as to how to encompass new ideas that could be injected to advance the quality of the 'gaming experience'.

Checklist

This is not an exclusive list, however may prove to be a tool that will facilitate the playtesting process:

Question	Answer		Notes
Have all tribes recommended for play been adequately playtested?	Yes	No
Have the tribes not recommended for play been playtested for a few turns?	Yes	No
Have all tribes recommended for play been played at Deity level for a few turns?	Yes	No
Are the victory conditions reasonable?	Yes	No
Is the technology tree long enough?	Yes	No
Are there any errors in the technology tree?	Yes	No
Have the technology slots with unusual characteristics been appropriately handled?	Yes	No
Are all units placed in their correct slots?	Yes	No
Are unit shields visible where visibility is appropriate?	Yes	No
Have unit prerequisite / obsolete technologies been placed accurately?	Yes	No
Have any sounds been correctly allocated?	Yes	No
Do all of the 'unusual' / 'identity' units perform as anticipated?	Yes	No
Are there any unexpected difficulties with tribe finances?	Yes	No
Have city improvements been distributed sensibly?	Yes	No
Is there duplication of City Improvements and select World Wonders?	Yes	No
Do any Wonders have an undesirable effect on the game's progress?	Yes	No
Are there any missing, erroneous, problematic, or illogical events?	Yes	No
Are inter-tribal stances rational? Do measures need to be taken?	Yes	No
Is the level of any Barbarian activity appropriate?	Yes	No
Do any tribes enjoy an unfair 'first strike' advantage?	Yes	No
Is the game duration sensible?	Yes	No
Is the extent of map disclosure reasonable?	Yes	No
Does the zipped scenario package contain only the necessary files?	Yes	No

Prepared for the Apolyton Scenario League. Please feel free to distribute this document in whole however please provide credit to the author wherever applicable.