On Mon, 5 Oct 2015 17:54:54 +0200 win...@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
pgpCOuqwqHc12.pgp
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
