This post was originally made about 4 years ago at the MFO Random Map Forum, when the game was fairly new and interest was great. That forum died out a long time ago, but there are still some random map scripters here. Given the poor quality of some of the maps recently released, I am re-posting this guide here to try to help people do a better job in their map scripting.

A random map script author should always proofread or check his script over carefully for typographic errors, proper command language, and for completed /* & */ symbols around any comments, since these errors can easily produce unwanted results. But it is even more important to check the map you are creating, the end results of your script, to be sure it follows your concepts and intended commands.

Some maps are relatively straightforward and require only basic review to insure that they are fair, with land & resources placed equally. The simplest maps are land-only, without any crowding of space or objects. However, even the Arabia map might occasionally drop a stone mine, uncrowded though it is. Most maps require careful and repeated checking under different map sizes & player number. If there are random features to a map, each needs to be checked independently to be sure that there was not a mistake made in the scripting and that the map features are consistently reproducible. These tips are to help you to be sure that everything works just like you intended it to.

I suggest that when you check your map, you should keep a log of the changes you make for each revision and give each revision a new name (such as MyMap.rms, MyMap_2.rms, etc.). If you find that a revision does not improve your map, you can always go back to a previous version and retry. A log, done either on paper or in a text file, can help you remember all of your changes.

It is important to learn the RMS language for AOKTC – simple misspellings of terrains or units will give unintended results. Using a command reserved for LAND_GENERATION in the TERRAIN_GENERATION section will not work. Frequently when things don’t work out as planned, a simple command error, misspelling or a dropped symbol can be the cause.

Well, just what needs to be checked?? EVERYTHING! But if you go through the map in an orderly fashion, then you can be sure that you have not overlooked anything. First check the player start areas. Check to be sure that each player has the standard TC, correct number of villagers and a scout (assuming that you used the standard startup). If you used RMSEdit or a copy-and-paste method of writing your script, this will not likely be a problem. But if you used unusual starting units then pay close attention to these units or buildings. If placing a DOCK, for instance, then that DOCK must be scripted before the TC or one player (generally player one) does not get a DOCK (weird bug!). Other reasons for objects not showing up in the player start area include an insufficient base size, overcrowding at a certain distance from the TC (set the objects to be placed at different distances) or the use of the terrain_to_place_on command for start area objects when some of the player start area terrain has been replaced by a primary or secondary terrain patch.

Next, check the player_lands for size and location. This is really not important for simple all-land maps, but in maps where there are more unique geographic features, the player_lands may need to be precisely placed among these other land or water features in order to avoid undesired results. Especially in startups with 8 players, if the player_lands are too small or the other_zone_avoidance_distance is too great, then the last 2 player_lands and TCs to be placed will be crowded together improperly. The best way to check player_lands when they are placed on a base_terrain of the same terrain type is to temporarily change the player_lands terrain to a different type to see its placement. For example, change the player_lands to DESERT on a base_terrain of GRASS or to GRASS on a DIRT or SNOW background. Then if the lands are not fitting together properly or placing where you like, it is much easier to follow a series of changes that you make in the parameters that affect player_lands placement, such as land_percent, base_size, borders, or other_zone_avoidance_distance.

After reviewing the player start areas, I next recommend looking at any special geographic features made in the such as islands, seas or rivers. Do they look as you intended? Do they place where you wanted? Are the features repeatable in multiple starts on different sized maps with different player numbers? Do they serve the purpose that you had in mind? Are they important for gameplay? Make note of any problem to be corrected.

Next, check out terrain placement - the forests, patches, islands, ponds, ice or shallows - that you made in. Terrains are harder to control exact placement of than lands; they are randomly placed according to your instructions. In particular, forests should be evaluated for their relation to player start areas (can be too close OR too far), total forested area, ease of walling off for defense, access to and from the player start areas, and adequate space for both expansion and forward-building. Also, note if your forests and other non-patch terrains (ice, shallows, water on land, or land on water) scale properly on different sized maps, both in size and number. Patches are usually less critical, as these are done mainly for aesthetics, but they can also be made to control placement of secondary forests or objects, so review as needed.

I feel that this is a good time to also evaluate connections, if any, since these involve changing terrains. Do the shallows or land connections seem too narrow or too few? Do they work consistently each time? Have you messed up your connection commands and replaced terrains where you did not intend? Check the commands to be sure that you have included all necessary terrains in the replacement, especially BEACH, which can allow ships to travel across what was to be a land connection.

Another tip has to do with using different randomly selected terrain patterns. Many of the standard ES maps do this. Look at the Coastal map included with the RMSG, which has 6 different terrain patterns. If you are including this type of feature, then each separate pattern needs to be checked. The surest way to do this is to edit your script to select only the #define statement for one pattern (edit out all of the rest of the random statement using the /* */ symbols), then run the script and review it. Repeat for each terrain pattern. Then as in the next paragraph, also check objects for the various patterns (if they vary by pattern also). If the patterns differ only in cosmetic appearance and the forest/water/ice/shallows land_percent and the scaling of objects are the same in all patterns, then I do not think that you need to also check every pattern at all map sizes, as they should all place similarly.

Next, check out the rest of the objects on your map. Crowding of forests or other objects can eliminate important resources from being placed. Remember that objects (and terrains) are placed in the order that you have scripted them. Also remember that the min_distance_group_placement command, while useful to keep all the resources from being clumped together, does affect the placement of later objects. Remember that if the program tries to place a stone mine and finds no way to fulfill all of the commands, the program does not go back to the beginning and start all over to try to fit it in, it just drops that object. Forage bushes, player start area (or 'straggler') trees, gold and stone, deer and boar, sheep (or turkeys), wolves (or jaguars), fish, and the scattered trees all should be looked at for placement and quantity. Relics, because of the special temp_min_distance_group_placement command, are always placed if you use the standard commands. But if you change the standard ES formula for relics, you should also check these carefully for placement (easy on the mini-map). In my experience, stone (and less often gold) being dropped and lack of adequate fish are the most common disappointments when checking object placement. Here are some tips for each problem:

Missing Stone(or Gold) - try decreasing the min_distance_to_players and/or the min_distance_group_placement commands. Also, consider reducing the min_distance_group_placement value for objects placed previously which may be affecting later-placed objects.

Fish Placement - Some information on scaling will help you to understand this. It is usual to use the set_scaling_to_map_size command to be sure that there are fish (as well as other objects) appropriate for the size of map. However, this command does not always scale appropriately for every map. On maps where all water sizes are given in land_percent this command will likely work well. However if water area is created also by an other_zone_avoidance_distance command, then scaling may not be done correctly. The scaling works by assuming the AREA of water increases or decreases in direct proportion to the AREA of a map. When you use the other_zone_avoidance_distance command, only the length of the body of water changes in proportion to the map size, while the width remains the constant of your command(the command is given in # of tiles, not %). So on a larger map, the area of water does not increase by the same percent as much as the total area of the map, and on the tiny sized map there is more water than expected because the zone between lands does not decrease with the rest of the downsized dimensions. The effect is that scaling by map size, when used in a map with large bodies of water created by the other_zone_avoidance_distance, will cause more fish per area of water on the larger sized maps and less fish per area on the smallest sized map. You can try to counter this effect on this type of map by using 2 create_object commands for each type of fish placed. On the first command use the scaling command with less fish than intended, then on the second command add more of that type of fish without the scaling command. This can give more fish on a tiny map and less fish on the larger sizes than otherwise. Consider using the min_distance_group_placement command to prevent overcrowding of your fish. Another way to adjust your fish by map size is to use "if" statements and specify exactly how many you want for each map size like in the "RESORCES BY MAP" section in the standard ES script (though this seems like more work to me).

You should check to be sure that you get what you want when you create jaguars and turkeys instead of wolves and sheep.

Just a note on the use of gaia objects, such as buildings and units. These items are converted to the first player to find them and unlike sheep, do not convert back and forth between players. If intending your map to be used in single-player, do not include these type of extra gaia objects since the computer players cannot convert anything by finding it other than sheep or the monument in KOTH. Also, many players consider the inclusion of such extra gaia objects unfair, especially when not all players know to aggressively scout for them.

Next, check your elevation placement. Did you remember to use the right base_terrain for elevation? Did you use "if" statements to change the base_terrain for elevation for any different terrain patterns? Did you remember to use set_flat_terrain_only for any ponds? (water looks pretty stupid with elevation in it!)

Lastly, review your map for its aesthetic qualities. Does it look realistic or composed of square land masses or forest terrain? Do you have jungle and snow running together? Have you placed patches of terrain that break up large expanses of the base_terrain? A map with a sense of realism will be far more acceptable to players. Also, does the map randomly vary? Or is it so rigidly constructed that it looks almost identical every time? Randomization is vital for a map’s replay quality.

My thoughts on the use of eye-candy: a few scattered objects may create interest and can actually be useful to players as a sort of landmark on the map. However, "spamming" the map with lots of flags, ruins and other items with no effect on gameplay looks silly after a while, and players may abandon such a map after the novelty wears off. Note that ES did not place any of these items on their own random maps.

If you are posting the map at the AOKH Blacksmith, you should always include a good detailed write-up of your map and the reason you created it. Describe any deviation from normal starting units, any special features, any ideas on what makes the map interesting and gameplay different or exciting.

I hope these tips will be of use to you. Please let me know at by posting on this forum if you have any other recommendations for proofreading your scripts and maps. If I update this article I will include any useful suggestions and give you credit for your ideas. I will try to post this also as a utility, if that will be easier for scripters to find.