[Freeciv-Dev] Re: AI, diplomacy and borders

[Ross Wetmore <rwetmore@xxxxxxxxxxxx>]

Again, I like the idea of a cumulative weight variable associated with
something like "love/hate" level. Any code that might impact this would
make a call to an update method that bumped it. On end-of-turn or when
engaging in activities like treaty negotiations, this value can be made
part of the is_*() checks defined for that element. While each of these
sort of personality or other (e.g. FoW) subsystems would have its own
code, types of methods, policies/rules etc, the general framework for
such things would be very similar, even to the point of sharing a lot of
utility-level code.

In the specific case of borders, moving into and remaining in someone
else's territory should result in an appropriately calculated bump.
Thus not every move, but only ones that "change ownership" plus an
end-of-turn update would mark code that had this extra step. A more
sophisticated "calculated bump" might involve the cultural weight at
that point as a measure of strength of the effect vs just a simple count.

Bumps could be done: when 2 units meet, when a unit enters a city
radius, when a unit pillages, etc. The idea is that there is an ongoing
collection of data during the turn, separate from the actual use of
the data during activities or at end-of-turn.

If the way it is done is common across lots of "what do I update after
a move", then one would make a single call to a single system method or
small set of methods like "update{,Pre,Post}Move()" that would walk a
list of policies in effect executing the instance update for each type.
The core framework would be used for AI actions, display activities,
and other seemingly unrelated updates. This is because the code split
is between common code (updating) and the specific instance type of
the update, rather than every new (functional) subsystem trying to
reinvent its own way of doing this like you are here.

Some implications ...
1)  Since the list is dynamically updated, one never has to worry about
which routines have hardcoded sets of such checks and calls, and
maintaining them in a consistent way throughout the codebase. The list is
basically an "orders-packet"/"policy-action"/"update-callback"/"transaction"
or whatever descriptive way one wants to refer to the code-block that
one would see in a functional program.
2)  One does not need to define a comprehensive list of things that
"might" be used some day, but only what one is using today.
3)  The execution is  efficient in that only elements of the active list
are executed, not (even the initial check for) a full set of things that
may or may not be turned on in the rules for this game.
4)  Some of the PF callback code and subsystems serve as examples of how
this might work, although parts of PF are still hardcoded inflexible
functional programming and the ideas above are meant to be split along
common-utility/instance callback lines.

Cheers,
RossW
=====

Per I. Mathisen wrote:

> I want some opinions on what effect borders should have on diplomacy (or
> the other way around), and how the AI should react to other players having
> units inside its borders.
>
> One idea is to give warnings and reduce 'AI love' when
> neutral/peace/ceasefire treatied players are within our borders. This is
> the simple way to implement something, I guess.
>
> Also, I'll be looking more closely at the AI diplomacy soon, so any
> opinion on how AI diplomacy is doing these days, and suggestions for
> improvements, are highly welcome.
>
>   - Per