City-States Influence rates; Wary status; Proximity calculations

[SimonCeder]

Part of #4602
This PR implements proper influence resting points, decay and regrowth rates.
It also implements the Wary Of mechanic where city states have a chance to grow wary of you after you've attacked at least two, this lowers their influence resting point by 20.

To do this I also had to implement proximity calculations where civs are graded as being Neighbors, Close, Far, or Distant to each other. I'm sure we'll find more uses for the in AI later, so it needed to be implemented anyway.

To do this I also had to implement a way to figure out if two cities are on the same continent. I decided to add a continent field to TileInfo which is assigned at map generation. Two tiles are on the same continent if their continent numbers are the same. Again I'm sure this will be useful down the line.

So quite a bit of code for a small functionality at this time.

A note about Permanent War: In some sources you can read about city-states banding together in Permanent War against attackers. This is only true for vanilla Civ V, in G&K and later this was removed in favor of the Wary Of mechanic.

[SimonCeder]

yep, I don't get why this is failing.

[SomeTroglodyte]

same continent

Refactored around that landTilesInBigEnoughGroup variable like I mentioned somewhere?

How do you not get complaints about getContinent, setContinent, continent and JVM signatures?

throw java.lang

This is kotlin. Do not use Java min, use kotlin min. Likewise...

runAndMeasure

Remind me to throw these functions out, kotlin has premade ones in Duration...

[SomeTroglodyte]

Could not GET 'https://jitpack.io/com/github/anuken/packr/-SNAPSHOT/maven-metadata.xml'.

Bad luck, the action VM didn't have healthy internet or jitpack.io was down...

[SomeTroglodyte]

private fun assignContinents

So, no, you copied it so now the costly cr.. ahem, runs three times instead of one. You know, I've meant to optimize that as it can waste around 25% of GameStarter time, but never got around to it? If you want, do it now. Move the assignContinents call to before addCivStartingUnits, produce both the continent numbers and that landTilesInBigEnoughGroup in one go, cache it and reuse in getStartingLocations. Don't forget to baseline properly so you can document the improvement here.

BTW, jitpack is still down.

[SomeTroglodyte]

No, jitpack just takes over a minute to deliver a 300 byte file. I've retriggered the check though chances aren't good that the VM has a long enough timeout.

[ajustsomebody]

so this implements landmasses?

[SimonCeder]

Depends on what you mean. We will end up with a bunch of landmass IDs that are saved

[SimonCeder]

BFS is now only run once. The performance gain is actually slim:

Master:
getStartingLocations BFS took 1.99ms
getStartingLocations BFS took 1.83ms

Intial PR:
MapGenerator.assignContinents took 2.45ms
getStartingLocations BFS took 1.58ms
getStartingLocations BFS took 1.39ms

Reviewed PR:
MapGenerator.assignContinents took 2.96ms

(When generating a huge pangaea, standard settings, seed 1111111111111)
While spreadResources takes 500-ish ms.

Each TileInfo now has a continent field for continent ID, and the MapInfo has a continentSizes<Int, Int> map that holds the number of tiles for each continent. Again this is potentially useful information. I'm using it in this PR to figure out if we are on a water map by checking if continents with more than 20 tiles > number of players.

[SomeTroglodyte]

This is what Mt. Fuji and Sri Pada placement could use 👍 (#5204)

[SomeTroglodyte]

slim

Indeed. I remember baselining a monster map totaling 10 seconds where resources and rivers were 60-70% and a big chunk of the rest was those landmass-big-enough runs, so I assumed a total gain of at least 10% of the entire GameStarter should be possible. Maybe I measured wrongly.

[SimonCeder]

Also assignContinents should probably go in GameStarter instead of MapGenerator since we want pre-made maps to work as well.
EDIT: wait, no we need it in mapgen for natural wonders. Hmm.

[SimonCeder]

Here's what I came up with. assignContinents goes back into MapGenerator so the data's avaliable for natural wonders. We have three possible scenarios:

• A freshly generated map. assignContinents is called from MapGenerator, we have a cached landTilesInBigEnoughGroup. All's well.
• A pre-made map without saved continent data (because it's old). assignContinents is called from GameStarter, we have a cached landTilesInBigEnoughGroup. Also works fine.
• A pre-made map with saved continent data. We don't have a landTilesInBigEnoughGroup cached. For this instance, the old BFS in getStartingLocations makes a return. Still only one BFS called per map!

[yairm210]

This looks good!
The proximity calculation in particular will probably be useful in many future AI-related improvements, so kudos for that :)
I only have one minor point, which is - "random" outcomes should be seeded by something (tile location, turn number, etc) so players don't save-scum to get the optimal random result.