Custom maps the AI can function on

[MikeLynch]

I read somewhere in one of these threads (I think the "Water as Space" one) that certain custom maps confuse the AI due to various factors.

Has anyone ever written up a guide to how to make custom maps for regular Civ2 playing (i.e., not space-style) such that the AI will function as normally as it would with a computer-generated map?

Or are there just a couple of key guidelines we mapmakers need to be aware of? What all throws off the AI?

[kobayashi]

The most important thing that comes to mind is the continent numbers, as the AI is more aggressive on enemy deployments in its home continent and it also affects the pay-off for caravans. Typically the way to do this is to make the continents in the map editor and start as a new scenario, then fill in the ocean canals with land manually.

The other thing to keep in mind is the type of terrain that AI will mostly build cities on, being grassland and plains. There are also some terrains hardwired so that the AI never builds on them - I think mountain, arctic and swamp if I am not mistaken.

[Mercator]

Just make sure that you use the Map Editor's "Analyze Map" option ("n"). I think most of the AI problems would have to do with there being more than 63 continents/oceans (or maybe 62 for oceans).

The only things the analyzer looks for are that there is enough land, enough "arable" land (i.e. grassland and plains) and at most 63 bodies of land/water.

Civ2 only counts the continents when loading the map though. If your map has more islands/lakes than that, you could temporarily connect lakes into one big lake or connect islands to one bigger island in the map editor until the analyzer is happy. Once you've started your game you can remove those connections again with the Cheat menu's "Change Terrain" option... Then again, I have no idea how that affects the AI. It might make the AI think a group of islands is actually one big island, for instance.


The terrains the AI builds its cities on are not hard-coded. The AI depends on "fertility" values stored in the savegame (as part of the map for each individual square). These fertility values are unrelated to Rules.txt terrain definitions.
By default, only grassland and plains will ever have high enough values for the AI to consider building cities. But since this is all stored in a savegame it can be hex-edited. Also, the MapCopy utility can be used to adjust them. MapCopy doesn't work with ToT, however.

[kobayashi]

Originally Posted by Mercator

The terrains the AI builds its cities on are not hard-coded. The AI depends on "fertility" values stored in the savegame (as part of the map for each individual square). These fertility values are unrelated to Rules.txt terrain definitions.
By default, only grassland and plains will ever have high enough values for the AI to consider building cities. But since this is all stored in a savegame it can be hex-edited. Also, the MapCopy utility can be used to adjust them. MapCopy doesn't work with ToT, however.

I used to believe in the grass/plain rule too but experiences from non-standard maps like StarGate SG1 now leads to the inescapable conclusion that there somehow are exceptions. As to what the exceptions are - i have no idea.

[Boco]

Merc, has any hex wizard figured out a fertility formula?

[Mercator]

Originally Posted by kobayashi

I used to believe in the grass/plain rule too but experiences from non-standard maps like StarGate SG1 now leads to the inescapable conclusion that there somehow are exceptions. As to what the exceptions are - i have no idea.

I'm not familiar with that scenario (no MGE)... What things happen that don't fit in with the grass/plains rule? Does the AI build cities on terrain that isn't in the grass/plains slots? And if so, are you sure you didn't edit those squares with the cheat menu? The initial fertility values are only created when the map is loaded. E.g. if you change a grassland square to desert using the cheat menu, the AI will still build cities on it.

Originally Posted by Boco

Merc, has any hex wizard figured out a fertility formula?

Not that I know. And actually, since those values make a tile more or less desirable to build a city, it could even be an essential part of the AI. Things like irrigation affect the fertility of one square, I think, but something like building a city seems to affect many more squares. It's rather complicated or seems to be at first glance anyway. I haven't looked at it in a long time.

Perhaps someone could write some sort of program that monitors the changes to the map throughout the game, including added irrigation, built cities and the fertility values and display that in a nice animation...

But that requires... effort.

[kobayashi]

[QUOTE=Mercator]:. if you change a grassland square to desert using the cheat menu, the AI will still build cities on it.[QUOTE]

I think that's the exact explanation I was looking for. Unfortunately it also means fixing it would be to tedious. sigh!

and what do you mean you're not familiar with the Stargate SG1 scenario? Can that be true???

[Mercator]

I hardly play any scenarios, all I usually do is open them to see what they look like, nose around and then delete them again. (so it's not just yours either)

In fact, the last time I played one (or any Civ2 for that matter, except for testing) is well over a year ago.

But MapCopy would likely be able to fix your problem. It can copy fertility data from a map to a savegame/scenario. Open your scenario in the map editor, edit it so that only the squares where you want the AI to build cities are Grassland/Plains, save the map. Then execute mapcopy on the command-line like this (assuming map/scenario and mapcopy are all in the same directory):

mapcopy source.mp destination.scn -s -t -bc +f:ADJUST

[Catfish]

Originally Posted by Mercator

It might make the AI think a group of islands is actually one big island, for instance.

From my experience that does seem to be the case. When you use impassable terrain or ocean to separate areas with the same land mass index (as described in the multi-mapping thread), it causes problems with the AI pathing.

Originally Posted by Mercator

Things like irrigation affect the fertility of one square, I think, but something like building a city seems to affect many more squares. It's rather complicated or seems to be at first glance anyway. I haven't looked at it in a long time.

The initial values for each grassland and plains tile appear to be influenced by the fertility of the surrounding 8 tiles. It's most noticeable if you create an all-grassland or all-plains map; the tiles around the edges of the map will have lower fertility values. I suspect all of the fertile terrain tiles are given identical values before adjustments are later calculated row by row. Resource seeding also appears to be a factor. All of this occurs during the 'build world' phase. IIRC, rivers and grassland shields each add 2 to the value; a resource on plains seems to drop the value by 1. Whatever the case, the range is always 8-15, assuming there are no cities (accelerated startup), which dock 8 points.

Originally Posted by Mercator

I hardly play any scenarios, all I usually do is open them to see what they look like, nose around and then delete them again.

I'm guilty of the same. I spend more time playing other games. When it comes to Civ2, I spend more time fiddling with the game than I do playing. It's bizarre.

Originally Posted by kobayashi

and what do you mean you're not familiar with the Stargate SG1 scenario? Can that be true???

I'm not familiar with it, either – but if you made a ToT version, I'd consider rummaging around in it for a bit.

Originally Posted by Mercator

Then execute mapcopy on the command-line like this (assuming map/scenario and mapcopy are all in the same directory):

mapcopy source.mp destination.scn -s -t -bc +f:ADJUST

That won't do it. The map file doesn't contain any fertility values. If you copy values from a map file, the entire scenario will end up with fertility values of zero. Someone at Apolyton recently had this problem. Here's part of my response (paraphrased):

1. Open up your saved game in Civ2's Map Editor.
2. For all those grassland/plains tiles on which you don't want the AI to build, replace them with a zero-fertility terrain type. For any remaining tiles on which you do want the AI to build, do the reverse.
3. When you're done editing the map, save it.
4. Start a new normal game with this new map. Pick Romans. Civ2 will set new fertility values. Don't build. Save the game as NewFert.sav.
5. Type the following command line for MapCopy:

mapcopy NewFert.sav Scenario.sav –s –t –bc

This will copy the fertility data only, using the ADJUST option (by default) to lower the values of tiles which fall within city radii.
6. Done.

[Mercator]

Originally Posted by Wobbegong

From my experience that does seem to be the case. When you use impassable terrain or ocean to separate areas with the same land mass index (as described in the multi-mapping thread), it causes problems with the AI pathing.

Ah... As if the pathfinding didn't have enough problems already.

The initial values for each grassland and plains tile appear to be influenced by the fertility of the surrounding 8 tiles. It's most noticeable if you create an all-grassland or all-plains map; the tiles around the edges of the map will have lower fertility values. I suspect all of the fertile terrain tiles are given identical values before adjustments are later calculated row by row.

Maybe it isn't just the surrounding 8, but 20 surrounding squares (i.e. city radius size). That would make sense, because the values are used for city building after all. And if that's the case, building a city can use the same algorithm to recalculate.

Resource seeding also appears to be a factor. All of this occurs during the 'build world' phase. IIRC, rivers and grassland shields each add 2 to the value; a resource on plains seems to drop the value by 1. Whatever the case, the range is always 8-15, assuming there are no cities (accelerated startup), which dock 8 points.

Interesting... I'm really going to have to look into this...

I'm guilty of the same. I spend more time playing other games. When it comes to Civ2, I spend more time fiddling with the game than I do playing. It's bizarre.

That won't do it. The map file doesn't contain any fertility values.

[Catfish]

Originally Posted by Mercator

Ah... As if the pathfinding didn't have enough problems already.

You're not wrong. The AI's stupidity (in this area in particular) has got to be the single biggest deterrent for me working on my scenario.

Originally Posted by Mercator

Maybe it isn't just the surrounding 8, but 20 surrounding squares (i.e. city radius size). That would make sense, because the values are used for city building after all. And if that's the case, building a city can use the same algorithm to recalculate.

That could very well be the case. I didn't investigate the situation very scientifically - I was defeated by laziness.

Originally Posted by Mercator

Actually, if you added one more line, you'd be OK.

Mapcopy source.mp +f:CALC
Mapcopy source.mp destination.sav –s –t –bc +f:ADJUST

But this would give you Dusty's fertility algorithm instead of Civ2's.

[Mercator]

Originally Posted by Wobbegong

That could very well be the case. I didn't investigate the situation very scientifically - I was defeated by laziness.

... Which is keeping me from even starting on it.

Actually, if you added one more line, you'd be OK.

Mapcopy source.mp +f:CALC
Mapcopy source.mp destination.sav –s –t –bc +f:ADJUST

But this would give you Dusty's fertility algorithm instead of Civ2's.

Hmm yes, but I prefer playing safe and going for the Civ2 one... That reminds me, I should still mail Dusty about some code additions.

[yoshi]

Originally Posted by Mercator

...MapCopy doesn't work with ToT, however.

Aw crap! How am I supposed to prevent the AI Settling in my ToT WW2 scen (aside form just not giving it settlers)?

Fertility exceptions: I've done experiments where I create an AI Settler on a square with Mountain terrain and it settles the square immediatley. This may be a result of the Settler being spawned far away from the nearest friendly city, it could just be because the AI is already set to settle (e.g. once pop. reaches x size, x # of turns from start) so it will do so anywhere at that point--only it would usually be built in a city and thus move to settle somewhere closer and on higher fertility terrain.

...but something like building a city seems to affect many more squares.

You mean when a city is built (or once certain # of cities built?), the AI treats fertile terrain differently? Don't understand.

In fact, the last time I played one (or any Civ2 for that matter, except for testing) is well over a year ago.

Heh, I haven't played vanilla Civ2 for like 3 years! (I do play scens now and then though--also like to check out their guts for innvative design ideas, esp. in Events.txt.)

[I think someone should re-design the vanilla game to make it play better--probably on an Earth map with a fixed set of civs so you can use events without resorting to wildcards to much...it's just that I don't have time to do it. ]

If the limit is 63, what happens when you use a space map (i.e. land as planetoids, water as space) and the single land tiles exceed 63?

[Mercator]

Originally Posted by yoshi

Aw crap! How am I supposed to prevent the AI Settling in my ToT WW2 scen (aside form just not giving it settlers)?

Bugger it... If I e-mail Dusty and can get him to add my suggestions he could make it support ToT. Though that might only be the first map in a multi-map game.

Do you have any spare terrain types? If you're not using at least 2 terrain types, you can swap them for grassland/plains so there isn't any terrain the AI will naturally build cities on...

But you can only do that when you create a new scenario. You obviously can't do that with an existing one, because, well, you'd need MapCopy to do that.

Fertility exceptions: I've done experiments where I create an AI Settler on a square with Mountain terrain and it settles the square immediatley.

Did that involve any terrain editing? If the mountain was grassland before and you edited it to become a mountain, the AI would still treat it as grassland.

You mean when a city is built (or once certain # of cities built?), the AI treats fertile terrain differently? Don't understand.

In one "experiment" I did a long time ago, it seemed fertility values across the map slowly increased. Perhaps the fertility values are used to implement the AI's expansion. I.e. fertility values increase so AI settlers are more likely to build cities.

The fertility values change during a game. It's not just fertile/not fertile, there are 16 different possible values (0-15).

If the limit is 63, what happens when you use a space map (i.e. land as planetoids, water as space) and the single land tiles exceed 63?

I don't know, but that's exactly the thing that confuses the AI... In fact, that's the thing Mike started this thread for in the first place! Read the thread he referred to in the opening post to see what he meant.

[Catfish]

Originally Posted by yoshi

Aw crap! How am I supposed to prevent the AI Settling in my ToT WW2 scen (aside form just not giving it settlers)?

It can be done using MapCopy, but it requires some hex-editing. It involves using an .mp file (which MapCopy can read and write to) as a temporary host for the scenario's map data - a copy and paste job with a hex-editor. After running MapCopy, you then copy the altered map data from the host file back to the original scenario file. I remember doing it for Curt Sibling's Bitterfrost scenario a long time ago when he wanted something like 3 or 4 fertile terrain types instead of the standard two. It's ugly, but it's possible.

Originally Posted by yoshi

You mean when a city is built (or once certain # of cities built?), the AI treats fertile terrain differently? Don't understand.

When a new city is founded, the fertility values of nearby tiles drop by 8 points. Supposedly the AI will not build on a tile with a value of less than 8.

Originally Posted by Mercator

Maybe it isn't just the surrounding 8, but 20 surrounding squares (i.e. city radius size). That would make sense, because the values are used for city building after all. And if that's the case, building a city can use the same algorithm to recalculate.

Actually, I just took a look at the effect of cities on the fertility of neighbouring tiles and found that the surrounding 44 tiles are affected. I loaded up an all-grassland map and tested it out. All of the tiles in the first screenshot have values of 15. When the settler founded the new city, all of the tiles in the darkened area of the second screenshot dropped to 7. At this stage, there's clearly no fancy algorithm for recalculating the values of affected tiles; merely a -8 blanket is cast over the city's immediate area.

[Mercator]

Originally Posted by Wobbegong

Actually, I just took a look at the effect of cities on the fertility of neighbouring tiles and found that the surrounding 44 tiles are affected. I loaded up an all-grassland map and tested it out. All of the tiles in the first screenshot have values of 15. When the settler founded the new city, all of the tiles in the darkened area of the second screenshot dropped to 7. At this stage, there's clearly no fancy algorithm for recalculating the values of affected tiles; merely a -8 blanket is cast over the city's immediate area.

Great! But I don't think that's how it works in all cases. E.g. what happens if the same civ builds another city just inside or just outside of this area. What happens if another civ builds that city. Is there a difference between AI/human? If no other cities are built nor any tile improvements, will the fertility remain like this forever, or will it gradually change? What happens if more cities are built, but nowhere near that city? What happens if the entire city radius is roaded and irrigated? Or what if the tiles just outside the city radius are irrigated? And what happens when tile improvements are pillaged? etc. etc.
Not that I'm asking you to test all this of course, unless you have nothing better to do.

I actually got off my ass too though (well, just a bit ). I just mailed Dusty about MapCopy. I've also done something else that's rather interesting, but not directly related to this. Do you have Hex Workshop, Catfish?

Oh, and how did you do that testing? Was it as tedious as I think it was, or have you found a way to easily see those values?

[Catfish]

Originally Posted by Mercator

Great! But I don't think that's how it works in all cases.

Well, that's why I said, "at this stage". However, based on the results of a few more tests (see below), it would appear that fertility values are only calculated during the 'build world' phase, with tile improvements, within or beyond city radii, having no effect. The game then applies a mask to the entire map, subtracting 8 points for tiles that lie near cities.

BTW, I checked the effect of Dusty's ADJUST algorithm and discovered that it only modifies the city's 21-tile zone, not the 45-tile zone. As a result, you may find the AI building new cities close to ones that existed prior to running MapCopy.

Originally Posted by Mercator

Not that I'm asking you to test all this of course, unless you have nothing better to do.

Of course not, but being an idiot I decided to take a look at some of those issues anyway. Great way to spend a Saturday afternoon. The following should answer a few questions:

Using the same example as my previous post, I constructed a second city within the first's 45-tile zone. The results are shown in the screenshot. All tiles within the new city zone took an 8-point hit, except those within the region of overlap, which experienced no further decrease.



Whether the city was built by an AI- or human-controlled civ, or belonged to the same civ or a rival one made no difference.

I then looked at the effect of irrigation on fertility. Again using the same example, tiles within the city's 21-tile zone were irrigated (conventionally, not via Cheat menu). It made no immediate difference – values remained at 7. To test the effect of irrigation on tiles which are unaffected by cities, I used a random map. The tested tiles had initial fertility values in the range 12-14. There was no change there, either.



To test possible changes over a period of time, I started up an Original game at King level. Initial fertility values were as shown below. Unmarked tiles have zero values.



Two turns later the settler moved to a value-15 tile and constructed Thebes. As expected, the fertility values of all the tiles within the 45-tile zone dropped by 8 points.



I let the AI do its thing and by AD 1600 the map looked like this:



The values of some of the outer tiles dropped due to the presence of new cities, but those within Thebes' 45-tile zone remained unchanged, despite the presence of tile improvements. By AD 1950 the map looked like this:



There was no change at all in the fertility values from the previous 'snapshot' of the game. There are a couple of things worth pointing out: the tile immediately SE of Thebes has been transformed to plains by an engineer – its value however remained zero. Another city was created just south of the screenshot (you can see the second orange flag). It was founded on a tile with a fertility value of 5 – the pressures of overcrowding I guess. BTW, the Egyptians are getting the tripe beaten out of them in this game.

One last point: when a city is destroyed, either by an attack or disbanding via the Cheat menu, the 8 points are restored.

[Catfish]

I had to split my post into two - too many images, apparently.

Originally Posted by Mercator

I actually got off my ass too though (well, just a bit ).

Gee, don't kill yourself, now.

Originally Posted by Mercator

Do you have Hex Workshop, Catfish?

No, I don't. I've got Axe and frhed.

Originally Posted by Mercator

Oh, and how did you do that testing? Was it as tedious as I think it was, or have you found a way to easily see those values?

Well, yes it's tedious, but I've made it less so than you might imagine. I use a spreadsheet to enter the x- and y-coordinates of the map tiles. It spits out the tile offset (1st of 6) in map block 2. I started using it when I was working on WotR and found that I was continually hex-editing the damned thing. It's saved me a lot of time.

[Mercator]

That's brilliant!

I guess most of the apparent randomness is due to the initial assignment, and the fact that the affected radius is bigger than just the city radius.

Originally Posted by Wobbegong

Gee, don't kill yourself, now.

No, I don't. I've got Axe and frhed.

Hmmm... Hex Workshop has a structure viewer, and I found out a few weeks ago that it's more powerful than I thought. I've managed to create a structure for the entire map section. You just have to "attach" the structure to the map header offset and it will read the entire map, putting it in the different blocks and in multidimensional arrays. It might even be possible to arrange the entire savegame in such a structure. It takes rather a while for the structure to load though since it's so big.

Note: Bloody hell! it's been trying to load the map structure for the Midgard scenario for over half an hour now... Maybe this isn't such a good idea after all.

I could, um, help you *cough* "acquire" it, though.

Well, yes it's tedious, but I've made it less so than you might imagine. I use a spreadsheet to enter the x- and y-coordinates of the map tiles. It spits out the tile offset (1st of 6) in map block 2. I started using it when I was working on WotR and found that I was continually hex-editing the damned thing. It's saved me a lot of time.

Ah, I see... When I checked the fertility (that was a long time ago), I used a combination of AXE and PSP to extract a map view quickly: (1) Use the graphical view in AXE, align the view to the start of the map, zoom out until each byte is 1 pixel and change the line width to match the map width x 6. (2) Take a screenshot and load it in PSP, do a pixel resize to 1/6 of the width. That way you'd end up with an image of all the first bytes of the map. To get the last byte instead, change the canvas size first, removing 5 pixels from the left, I believe. A pixel resize to 1/6 will take one pixel and skip the next 5, so you'll end up with an image of just the 6th bytes... That still leaves the other half of the same byte though, I guess I got rid of that with one of the arithmetic operations in AXE, doing a binary AND with 0F.

[Catfish]

Originally Posted by Wobbegong

The game then applies a mask to the entire map, subtracting 8 points for tiles that lie near cities.

BTW, I checked the effect of Dusty's ADJUST algorithm and discovered that it only modifies the city's 21-tile zone, not the 45-tile zone. As a result, you may find the AI building new cities close to ones that existed prior to running MapCopy.

These comments of mine made me curious. If one assumes that the game applies a "mask" to the entire map, then Dusty's ADJUST algorithm would only apply at the beginning of the game or at least only until another city is built or destroyed somewhere. I tested it. Without direct interference from neighbouring cities (see below), the 21-tile zone created by MapCopy lasts the lifetime of the city, ie, it is not recalculated. It turns out that the fertility value for a specified tile is only recalculated when it lies within the 45-tile zone of a city that is created or destroyed. I can ditch the "mask" nonsense then.

It's really very simple. For each tile within a city's 45-tile zone:

City Created: If Fertility > 7 then Fertility = Fertility – 8, else Fertility = Fertility
City Destroyed: If Fertility < 8 then Fertility = Fertility + 8, else Fertility = Fertility

It explains why when two or more cities have overlapping zones, the tiles within the region of overlap are not devalued more than once. It produces an absurd situation when you have two or more cities with overlapping zones and one of them is destroyed. Same 2-city example as before:



BTW, I forgot to mention the effect of farmland on fertility. It makes no difference, either.

Originally Posted by Mercator

Hmmm... Hex Workshop has a structure viewer, and I found out a few weeks ago that it's more powerful than I thought. (...)

Axe has one, too (I'm using version 3.4.1), although creating structures is unchartered waters for me.

Originally Posted by Mercator

Ah, I see... When I checked the fertility (that was a long time ago), I used a combination of AXE and PSP to extract a map view quickly (...)

Interesting, but it sounds like at least as much work as the method I'm using. With the spreadsheet I can effortlessly switch between maps, too. If I need to find a row of tiles, I just plug in the co-ordinates of the leftmost tile, get my offset and move along the row in the hex-editor. If I want to move to a tile in the next row, I can use Jump (6 x map width). BTW, this is the formula I use in Excel (for ToT 1.1 only):

Offset = 29910 + 14*T + 7*W*H*(Z+1) + (6*W*H+2)*Z + 6*(Y*W+ROUNDUP((X+1)/2,0))

W = Map width (number of tiles)
H = Map height (number of tiles)
X = X-coordinate of tile (game, not map editor)
Y = Y-coordinate of tile
Z = Map number of tile (0-3)
T = Number of transporters in game (byte 29896 will tell you this)

It returns the offset for the 1st byte of 6 for each map tile. Offsets start at 0.