Hi, > Gesendet: Dienstag, 06. Oktober 2015 um 12:10 Uhr > Von: "Michael T. Pope" <mp...@computer.org> > > On Mon, 5 Oct 2015 17:54:54 +0200 > win...@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 ------------------------------------------------------------------------------ _______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
