[Freecol-developers] Things the game still needs

[w***@genial.ms]

Hi,

I was thinking about what FreeCol is missing still, besides that
long list of tiny incompatibilities with Col1 (most of which I somehow
are not missing much).


The biggest issue imho is weak AI. Except the REF AI, which really
wants to destroy you, the AIs have no real goal, they just passively
manage what they have and focus on single colonies/units when deciding
what to do, rarely checking from a global view.

I feel a good step to get it more competitive would be allowing to
set a different difficulty level for AI and Humans or even for each
individual player. For example, in Alpha Centauri the AI plays on an
easier level when you play the highest, to avoid crippling it from
not being able to cope with low tile production, drones, harder
response from the planet and other things. I know Civ games also do
that and I suspect Col1 might have done similar. Is there some
knowledge about if it was like that in Col1?

The AI code could profit from restructuring it a bit and there are a
number of IRs for improving AI which might get easier through that.
If there was some MetaAI class, which could (depending on game progress
and other conditions like peace/war) delegate to a different normal AI,
it could help the AI adapt better to the current game and it would be
easier to write smaller, more focused AIs (for startup, fast growth,
defensive preparations, defensive war, offensive preparations,
offensive war, ...).
It might also help on comparing strength of different AIs when testing?
Alternatively or additionally, it may also be useful to move most code
into goals and subgoals, to cut down on code in the main AI classes.


I'd also think before 1.0 the production/consumption of Natives, prices
they pay and also price fluctuations in Europe need to be rebalanced.

Did you have a look at my comment for BR#793?
I feel like its deprioritization should be reversed, considering
how long it exists already and its imho a must have for 1.0.

A useful bit of polish for 1.0 would be adding a dialog with the king
sending you out to the new world when starting a new game, IR#94.

One of the missing battle-sounds for BR#2043 could be taken from SVN,
and there was another which was sounding like it could replace one
we already have in some cases, depending on the battle outcome.

Some issues I find useful to get done fast, as they can be repeatedly
annoying people with little things, would be PF#14/77, PF#30 (the randomization),
BR#2730, IR#172, and some ship should be activated if in Europe and opening
the Europe panel.


We once mailed about how the logfile is cluttered already, but still
missing some useful data like which panels or dialogs get opened:
I changed the command line processing to allow setting different
log-levels for some parts of the game, to filter out uninteresting
things or only activate interesting messages.
For example, you could do something like:
$ java -Xmx256M -jar FreeCol.jar --log-level warning common:finest common.option:warning --debug
or
$ java -Xmx256M -jar FreeCol.jar --log-level warning --log-level common:finest --log-level common.option:warning --debug
Its in my fork at https://sourceforge.net/u/wintertime/freecol/ci/loglevels/tree/
and I'd like you to try it out. Then maybe after the release push it
to the FreeCol git?
I did not bother to update the cli help messages, as this is mostly
a developer feature, though that may be useful.
While implementing this I found we are still using commons-cli 1.1.
I'd think we should upgrade to 1.3.1, as there have been some bugfixes,
probably after the release.

Btw., there is another branch in my fork at
https://sourceforge.net/u/wintertime/freecol/ci/tileneighbours/tree/
where I wanted to simplify code calling Tile.getNeighbourOrNull repeatedly
in RoadPainter and TileViewer, by adding a getNeighbours method, but there
the direction is reused after getting the tile, so I could not use it there.
But there are other places, for example, SimpleMapGenerator, where you could
use it (but those are all parts of the code I'm not familiar with).


Greetings,

wintertime

------------------------------------------------------------------------------

[Michael T. Pope]

On Mon, 5 Oct 2015 17:54:54 +0200
***@genial.ms wrote:
> The biggest issue imho is weak AI. Except the REF AI, which really
> wants to destroy you, the AIs have no real goal, they just passively
> manage what they have and focus on single colonies/units when deciding
> what to do, rarely checking from a global view.

Quite so.

> I feel a good step to get it more competitive would be allowing to
> set a different difficulty level for AI and Humans or even for each
> individual player.

I am not convinced. I think that would just complicate matters
further. What is most needed is what you mention above--- improve the
AI's global coordination.

> For example, in Alpha Centauri the AI plays on an
> easier level when you play the highest, to avoid crippling it from
> not being able to cope with low tile production, drones, harder
> response from the planet and other things. I know Civ games also do
> that and I suspect Col1 might have done similar. Is there some
> knowledge about if it was like that in Col1?

Not to my knowledge.

> The AI code could profit from restructuring it a bit and there are a
> number of IRs for improving AI which might get easier through that.
> If there was some MetaAI class, which could (depending on game progress
> and other conditions like peace/war) delegate to a different normal AI,
> it could help the AI adapt better to the current game and it would be
> easier to write smaller, more focused AIs (for startup, fast growth,
> defensive preparations, defensive war, offensive preparations,
> offensive war, ...).

I disagree that a meta-AI class is needed. Just a
current-operating-mode for EuropeanAIPlayer would suffice for the
adaptability you describe. I also doubt "smaller" AIs are useful or
even achievable without introducing serious flaws. What specifically
would you leave out?

> It might also help on comparing strength of different AIs when testing?

It is not difficult to compare AIs. I effectively do that at the
moment in my regression tests, albeit the only difference between them
is the minimal changes due to national advantages. If you really
wanted to measure significant differences it would be slow though ---
you would have to run a lot of games because the variance is high.

Indeed, some time back we had two AI implementations, but one had many
less bugs and performed much better so we dropped the other.

> Alternatively or additionally, it may also be useful to move most code
> into goals and subgoals, to cut down on code in the main AI classes.

Again, what specifically would you remove? There is already a lot of
goal-oriented code in the *Mission classes. Do not underestimate how
easy it is to break the AI!

> I'd also think before 1.0 the production/consumption of Natives, prices
> they pay and also price fluctuations in Europe need to be rebalanced.

That would be nice, but if it comes down to us being ready to release
1.0 except for Col1-compatibility issues that require quantitative
data that we do not have, I do not intend to block the release.

> Did you have a look at my comment for BR#793?

Of course. I read everything:-). However I am puzzled that you think
I have anything useful to say about a Windows issue:-).

> A useful bit of polish for 1.0 would be adding a dialog with the king
> sending you out to the new world when starting a new game, IR#94.

Should be straightforward. Turn the initial message into a special
MonarchAction that is auto-generated for the first turn.

> One of the missing battle-sounds for BR#2043 could be taken from SVN,
> and there was another which was sounding like it could replace one
> we already have in some cases, depending on the battle outcome.

Go ahead, although it would be good to stick to the current sound format.

> Some issues I find useful to get done fast, as they can be repeatedly
> annoying people with little things, would be PF#14/77,

PF#77 is high priority as it is not that hard and we now have some
numbers. PF#14 is much harder and remains in WWC1D-space. OTOH,
since it was reported, many bugs in diplomacy have been fixed and
FreeCol is far less likely to outright reject a reasonable peace
attempt, so things are nowhere near as bad as described in the PF, and
hence I would not rush there.

> PF#30 (the randomization),

Er, what? PF#30 is "Transfer of movement points" and looks pretty
dubious whether it is even true or not.

> BR#2730,

Low priority IMHO, see the last comment there for how to proceed.

> IR#172,

Should be straightforward.

> and some ship should be activated if in Europe and opening
> the Europe panel.

This should already be happening. If it is not, we probably need to
push some code in ColonyPanel up to a common class.

>[logfile clutter fork]

I put this on the todo list to look at properly post release.

> While implementing this I found we are still using commons-cli 1.1.
> I'd think we should upgrade to 1.3.1, as there have been some bugfixes,
> probably after the release.

Agreed.

> Btw., there is another branch in my fork at
> https://sourceforge.net/u/wintertime/freecol/ci/tileneighbours/tree/
> where I wanted to simplify code calling Tile.getNeighbourOrNull repeatedly
> in RoadPainter and TileViewer,

I do not see any calls to getNeighbourOrNull in trunk RoadPainter ---
you killed it off quite neatly in git.a88f507c! Pre-Java8 I would
have used getSurroundingTiles for the calls in TileViewer, albeit that
is not code I work on. Now that we have streams, there are *heaps* of
places in FreeCol where IMHO it is clearer and/or more concise to use
them instead of explicit iteration and/or passing collections around.
The problem I have is deciding where to start, which is why I have
thus far only added in the obvious simple uses, with the intent of
building upwards in complexity. I do think we need to be a bit
cautious though as streams are new code and there are grumbles about
poor performance (I assure you I have been keeping an eye on the
impact on turn speed of my patches so far). A get-adjacent-tile-stream
routine is a good idea, as is get-*-players-stream,
get-*-work-locations-stream, get-*-units-stream etc etc. Expect them
to appear over time.

Cheers,
Mike Pope

[w***@genial.ms]

Hi,

> Gesendet: Dienstag, 06. Oktober 2015 um 12:10 Uhr
> Von: "Michael T. Pope" <***@computer.org>
>
> On Mon, 5 Oct 2015 17:54:54 +0200
> ***@genial.ms wrote:
> > The AI code could profit from restructuring it a bit and there are a
> > number of IRs for improving AI which might get easier through that.
> > If there was some MetaAI class, which could (depending on game progress
> > and other conditions like peace/war) delegate to a different normal AI,
> > it could help the AI adapt better to the current game and it would be
> > easier to write smaller, more focused AIs (for startup, fast growth,
> > defensive preparations, defensive war, offensive preparations,
> > offensive war, ...).
>
> I disagree that a meta-AI class is needed. Just a
> current-operating-mode for EuropeanAIPlayer would suffice for the
> adaptability you describe. I also doubt "smaller" AIs are useful or
> even achievable without introducing serious flaws. What specifically
> would you leave out?

The idea was to not so much leaving things out as having more focused AI
for different situations. For example, a war AI which gets activated when
a war is opened and a large enough threat appears (armed units spotted)
or before declaring independence, which then changes unit allocation,
arms all expert soldiers except a few for teaching, depending on situation
arms even more colonists and changes production to mainly produce
muskets/horses/artillery/warships.
And a peacetime AI which focuses on growth, bells, export/import, scouts,
missionaries, pioneers (basically the current AI with even leaner military,
but only active when no wars are anticipated).
A dedicated AI for starting the game might also be useful. It could be
choosing from some known good setups, ensure all useful/necessary buildings
are set up asap and some wagon trains get built, exporting to gain start
money, bring in scouts and collect experts, ensuring fast growth.

> It is not difficult to compare AIs. I effectively do that at the
> moment in my regression tests, albeit the only difference between them
> is the minimal changes due to national advantages. If you really
> wanted to measure significant differences it would be slow though ---
> you would have to run a lot of games because the variance is high.

I'd be interested in reading a bit more about your test setup.

> Indeed, some time back we had two AI implementations, but one had many
> less bugs and performed much better so we dropped the other.

I discovered goals are unused atm, I guess they remained from the second AI.

> > Alternatively or additionally, it may also be useful to move most code
> > into goals and subgoals, to cut down on code in the main AI classes.
>
> Again, what specifically would you remove? There is already a lot of
> goal-oriented code in the *Mission classes. Do not underestimate how
> easy it is to break the AI!

It looks like missions are just helpers for moving single units to their
destination, without regard to other units. Goals seem to be useful for
intermediate sized parts of the AI, which can coordinate groups of units
and may be easier to handle when some related parts of the code get moved
there, than having all higher level tasks inside single EuropeanAI class.
This needs more time though, for me to find out what to do exactly, as I
was already thinking much about the possibilities of breaking stuff. ;)

> > One of the missing battle-sounds for BR#2043 could be taken from SVN,
> > and there was another which was sounding like it could replace one
> > we already have in some cases, depending on the battle outcome.
>
> Go ahead, although it would be good to stick to the current sound format.

Do you happen to have a good program for encoding ogg from wav?
I prepared the necessary changes to the resource keys.
We need attack.wav and attack_dragoon.wav from SVN at
https://sourceforge.net/p/freecol/code/HEAD/tree/audio/trunk/sfx/
converted to ogg and put into
data/rules/classic/resources/sound/attack/ .

I also added a bit of code to reuse the old dragoon sound for when a
mounted unit is killed. I'm unsure if its correct and it is untested.

Both commits are in attacksounds branch in my fork:
https://sourceforge.net/u/wintertime/freecol/ci/attacksounds/tree/

> > PF#30 (the randomization),
>
> Er, what? PF#30 is "Transfer of movement points" and looks pretty
> dubious whether it is even true or not.

There had been a post telling the original theory is wrong and
affirming my theory. I know more research is necessary, but I thought
the basics could be implemented already.


Greetings,

wintertime

------------------------------------------------------------------------------

[Michael T. Pope]

On Thu, 8 Oct 2015 16:21:00 +0200
***@genial.ms wrote:
>>[meta-AI]
> The idea was to not so much leaving things out as having more focused AI
> for different situations.

I take the point of having AI that is aimed at particular stages of the
game. I just do not think you can easily break out that functionality.
Whatever you do, you need to implement the abstract routines of AIPlayer.
What we have in EuropeanAIPlayer is pretty minimal in most places ---
the only place with any depth is support for AIColony/s doing the best they
can with their and some limited global resources, and some attempt to
globally allocate units. As it stands if you want a "war AI", I would
recommend just a big "switch (getAIOperatingMode()) { case WAR: ... }" in
the main EuropeanAI routine:-).

>>[Comparing AIs]
> I'd be interested in reading a bit more about your test setup.

I have two ugly scripts. bigtest.sh runs <game> <N> times to 1700,
collects the results (with bin/fclogscore.sh and bin/fsgscore.sh) and
prints a summary. lots.sh runs bigtest with a standard 8-player very hard
game on a moderate sized auto-generated map 10 times, then a standard
medium difficulty 8-player game on the Caribbean map (to increase
competition for resources) 10 times, then repeats the two games but
playing one turn then save-quit-reload (so as to *really* exercise the
serialization). This takes my decent-but-old 4-core PC about 13 hours. I
like to do this before committing any non-obviously-correct patch, as the
AI is quite sensitive to mistakes --- if you can see that while the
average number of transports per game was 1000 the day before but now it
is 500, something is amiss. One day soon I will put up some pretty graphs
of how the tests have performed over time.

> > Indeed, some time back we had two AI implementations, but one had many
> > less bugs and performed much better so we dropped the other.
>
> I discovered goals are unused atm, I guess they remained from the second AI.

Actually no, that is incomplete code that Michael was working on. It
might have become a third AI:-). I still hope he will one day get back to
it.

>>[sounds]
> Do you happen to have a good program for encoding ogg from wav?

According to my notes I used oggenc:

oggenc -r -R 48000 --managed -b 112 -o <ogg> /tmp/raw

> Both commits are in attacksounds branch in my fork:
> https://sourceforge.net/u/wintertime/freecol/ci/attacksounds/tree/

Will get to it soon.

> > Er, what? PF#30 is "Transfer of movement points" and looks pretty
> > dubious whether it is even true or not.
>
> There had been a post telling the original theory is wrong and
> affirming my theory. I know more research is necessary, but I thought
> the basics could be implemented already.

If you wish. However I remain unconvinced that one is real, so I am
concerned that any effort on it is misplaced. The recent play through from
Mark Jackson did not find any supporting evidence.

Meanwhile, it turns out that I am spending this weekend demolishing our
patio, which is probably going to delay the release again. Hope no one is
holding their breath.

Cheers,
Mike Pope

[w***@genial.ms]

Hi,

> Gesendet: Samstag, 10. Oktober 2015 um 06:23 Uhr
> Von: "Michael T. Pope" <***@computer.org>
>
> I take the point of having AI that is aimed at particular stages of the
> game. I just do not think you can easily break out that functionality.
> Whatever you do, you need to implement the abstract routines of AIPlayer.
> What we have in EuropeanAIPlayer is pretty minimal in most places ---
> the only place with any depth is support for AIColony/s doing the best they
> can with their and some limited global resources, and some attempt to
> globally allocate units. As it stands if you want a "war AI", I would
> recommend just a big "switch (getAIOperatingMode()) { case WAR: ... }" in
> the main EuropeanAI routine:-).

I did a little experimentation and could significantly cut down on the code,
I'd just have to reimplement choosing/buying/moving/using goods/units in some
other way. :p

I read up on how Behavior Trees and I think they are a promising way of
structuring AI:
http://www.gamasutra.com/blogs/ChrisSimpson/20140717/221339/Behavior_trees_for_AI_How_they_work.php
I started by implementing the basic node types for one. I still need to try
reimplementing parts of the AI with these, which will take some time.

> >>[Comparing AIs]
>
> I have two ugly scripts. bigtest.sh runs <game> <N> times to 1700,
> collects the results (with bin/fclogscore.sh and bin/fsgscore.sh) and
> prints a summary. lots.sh runs bigtest with a standard 8-player very hard
> game on a moderate sized auto-generated map 10 times, then a standard
> medium difficulty 8-player game on the Caribbean map (to increase
> competition for resources) 10 times, then repeats the two games but
> playing one turn then save-quit-reload (so as to *really* exercise the
> serialization). This takes my decent-but-old 4-core PC about 13 hours. I
> like to do this before committing any non-obviously-correct patch, as the
> AI is quite sensitive to mistakes --- if you can see that while the
> average number of transports per game was 1000 the day before but now it
> is 500, something is amiss. One day soon I will put up some pretty graphs
> of how the tests have performed over time.

Interesting. I saw some of the script files are in bin directory in git.
Considering I found when normally running the game a large part of the used
time is from drawcalls and you run headless, 13h is a pretty long time.
Might be worth profiling + optimizing some parts?

> > > Indeed, some time back we had two AI implementations, but one had many
> > > less bugs and performed much better so we dropped the other.
> >
> > I discovered goals are unused atm, I guess they remained from the second AI.
>
> Actually no, that is incomplete code that Michael was working on. It
> might have become a third AI:-). I still hope he will one day get back to
> it.

I did look through the history and goals are not from Michael, the are a part
of an ExperimentalAI, which got written by abartels in 2009 and remained when
that AI was incompletely deleted shortly after, then forgotten.

Michael added server.ai.ProductionCache and CacheEntryComparator in git.7541ed01
for future use, which got never used, because little later they were forgotten
already and common.model.ProductionCache got added and used.
I think, these 2 can be deleted?

There is even more dead code in common.model.mission, which may be what you
were thinking of what Micheal started with and IR#200 is referring to.
These got activated once, then shortly after deactivated without deletion,
until some unspecified problems with the missions would be fixed.
Are these worth keeping for the moment?


Greetings,

wintertime

------------------------------------------------------------------------------