[freeciv-ai] Re: improve diplomat logging + bugfix
[Top] [All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
On Tue, 6 May 2003, Per I. Mathisen wrote:
> > Huh? Why do you want to penalise city which is 2 moves away more than a
> > city 2 (sic!) moves away. If the only difference is that in the second
> > city the diplomat would have some moves left. But if it does the bribing
> > he would have no moves left anyway!And would probably be dead too!
> Look at the larger picture.
> In this function, the desired result isn't some kind of exact value which
> is valid for each and every situation. We don't really need micro-level
> correctness here. We're just trying to come up with an algorithm which
> gives us diplomat production in just about the right number of cities, and
> preferably in cities close to the action.
> The previous code meant that cities if different players close to each
> other produced too many diplomats overall. The fix changes this slightly
> to the better (giving a better supply curve to use a term from economics).
Don't try befuddle me with economics! I had my share of economics
and passed two exams in my time. ;)
To summarize your actions, (1) you saw AI produce diplomats in what you
judged to be excessive way. Then you proceeded to (2) fix the code to
compensate for it.
My problems with it are:
In (1) I felt that AI is perfectly justified to build these diplomats. I
would do the same in a similar situation.
If the number of diplomats is visually displeasing it doesn't mean it's
not economically justified. Trust your code, for it is good.
In (2), you chose to fix the least questionable part of your code. You
could have chosen to tweak the gain_incite calculation. You could have
removed 2 from time_to_dest *= (time_to_dest/2);
But now the result is that _equally_ diplomatable cities (cities that have
equal production and that are equally easy/hard to bribe) have different
want. I don't think it's right.
P.S. Jason is absolutely right, the original code is buggy because of
integer arithmetic! Well spotted, Jason!