Frankly, having written a bunch of formal AIs before, I'm frustrated with a lot of the decisions made in this function. I'll likely make an attempt at a total re-write, with the hope that it will make the code simpler and more effective.
Once more: FFH and the AI
- Thread starter Bringa
- Start date
Frankly, having written a bunch of formal AIs before, I'm frustrated with a lot of the decisions made in this function. I'll likely make an attempt at a total re-write, with the hope that it will make the code simpler and more effective.
Long term, I think it would be more valuable to get the AI to have a magical strategy, and try to implement it with its tech choices. That will take a while though; I'd be happy if We get to that by the end of the year.
Short term, we can directly de-value the techs through XML.
Medium term, we can at least get the AI to recognize that it can't multiply improve a mana node (as for as tech decisions are concerned).
I'm not familiar with Blake's AI, but this is another major target for me.
Spoiler :
1) We can change the base values of each technology.
2) We can change those base weights by one or more factors, based on each leader. (flavor)
My suggestion would be to scrap the current flavors altogether. The most important variable factor that isn't dynamic throughout a game for a leader is their civilization. If you're Ljosalfar, you'll favor different techs than Grigori, who will favor different techs than Kuriotates.
So these are the flavors I'd reccomend as a first pass:
- Bannor
- Malakim
- Elohim
- Mercurians
- Luchuirp
- Kuriotates
- Ljosalfar
- Khazad
- Sidar
- Lanun
- Grigori
- Hippus
- Amurites
- Doviello
- Balseraphs
- Clan of Embers
- Svartalfar
- Calabim
- Sheaim
- Infernal
- Illians
I agree. Working on getting the AI to use summon spells effectively should be a major goal, partially because the summon spell is the most common spell, so getting the AI to use it will will give us more for our efforts than most other spells (save, perhaps, Spring). However, I'll note that it's one of the harder things we've listed yet.
True, although assuming that we don't work on all AIs simultaneously, it may be better in the long run to get the tech tree balanced as if a human were using it, and worry about the use of magic as a separate issue. I'll have more on this later.
xanaqui, would that re-write from scratch be your first prio or would you first try to modify what we have? To speak from a very meta point of view, I've noticed that projects which do not immediately produce results quickly lose impetus. The risk is that re-writing the AI (even if only the tech selection) might take too long and you'd get too frustrated along the way...
Btw, the Microsoft Platform SDK has been installing for two hours here now. WTH? There IS progress, always new files, new sizes etc, but it's slooow. Is it downloading the stuff it's installing? I'd guess so.
I think from a project management point of view, we should probably take a step back next and come up with a list of problems and how we'd like to solve them, before we even get very far into trying out things.
I'll throw out a few random things right away. Maybe let's also number issues, for easier referencing:
1) The AI doesn't understand race specific mechanisms; for instance, 1a) the Kuriotates will found settlements that do not give him new resources or important territory; it will set these settlements to "research", even though the research rate will always be 0. 1b) The Khazad doesn't make a good attempt at balancing number of cities/money in treasury to keep the vaults full enough. The fact that the Khazad leaders have gold flavor does help somewhat.
2) The AI sometimes settles in very, VERY bad places. 2a) Settling when in danger. It's happened to me very often that I had a large stack of units about to move into AI territory when along came a settler and a warrior and the AI built a city. Which I razed. It should probably consider things like "are there enemies nearby?" and "is this considerably closer to the enemy's cities than to my other cities? If the latter is yes, at least it should protect the city better. 2b) Settling in the worst place possible when there's no more good spots left. Now I understand that the AI wants to settle as much as possible. However, sometimes this gets very stupid. Best example so far: a ONE-TILE island which had in its fat cross four tiles of ice and three tiles of tundra (on the continent beyond a channel of coast tiles). There should be already in place a settle spot evaluation function; I have a feeling like there's no lower limit below which the AI *won't* settle. That might be a good idea.
3) Combat. 3a) The AI does not consider what position it will be in AFTER combat. Most famous example: Kiting an AI hero by offering him an easy target. You take a stack of units two tiles away from an AI hero, you take one single weak unit and put it in between your stack and the hero. The hero will attack, ending his movement right in front of your stack (and probably wounded as well). 3b) The AI doesn't understand HOW important heroes are. A simple solution could be a function that forbids the AI to use its hero unless it has at least 95% combat odds.
4) And then of course there's magic. Someone else should try and enumerate the issues with magic because I'm going to bed now
Btw, the Microsoft Platform SDK has been installing for two hours here now. WTH? There IS progress, always new files, new sizes etc, but it's slooow. Is it downloading the stuff it's installing? I'd guess so.
I think from a project management point of view, we should probably take a step back next and come up with a list of problems and how we'd like to solve them, before we even get very far into trying out things.
I'll throw out a few random things right away. Maybe let's also number issues, for easier referencing:
1) The AI doesn't understand race specific mechanisms; for instance, 1a) the Kuriotates will found settlements that do not give him new resources or important territory; it will set these settlements to "research", even though the research rate will always be 0. 1b) The Khazad doesn't make a good attempt at balancing number of cities/money in treasury to keep the vaults full enough. The fact that the Khazad leaders have gold flavor does help somewhat.
2) The AI sometimes settles in very, VERY bad places. 2a) Settling when in danger. It's happened to me very often that I had a large stack of units about to move into AI territory when along came a settler and a warrior and the AI built a city. Which I razed. It should probably consider things like "are there enemies nearby?" and "is this considerably closer to the enemy's cities than to my other cities? If the latter is yes, at least it should protect the city better. 2b) Settling in the worst place possible when there's no more good spots left. Now I understand that the AI wants to settle as much as possible. However, sometimes this gets very stupid. Best example so far: a ONE-TILE island which had in its fat cross four tiles of ice and three tiles of tundra (on the continent beyond a channel of coast tiles). There should be already in place a settle spot evaluation function; I have a feeling like there's no lower limit below which the AI *won't* settle. That might be a good idea.
3) Combat. 3a) The AI does not consider what position it will be in AFTER combat. Most famous example: Kiting an AI hero by offering him an easy target. You take a stack of units two tiles away from an AI hero, you take one single weak unit and put it in between your stack and the hero. The hero will attack, ending his movement right in front of your stack (and probably wounded as well). 3b) The AI doesn't understand HOW important heroes are. A simple solution could be a function that forbids the AI to use its hero unless it has at least 95% combat odds.
4) And then of course there's magic. Someone else should try and enumerate the issues with magic because I'm going to bed now
cool, I can edit that, no problem.
In case you change your mind, here's an editor, and here's instructions on how to read it.
It's not too bad if you are familiar with another object-oriented programing language (or even a procedural language), but if you find python difficult to edit, you might want to play with that more, first.
EDIT - oops! I see you're fine with C++.
I don't know. A complete re-write would take longer, but it's highly tempting. The present function breaks all kinds of rules (too large of a range, open-ended range, bad function for things in order, lack of acknowledging interdependencies, weights that aren't controllable via XML, poor functionalization, poor efficiency, linear "jackpotting", improperly used random variables,...). I'm highly suspicious that I can write far better, and instead of having all the internal weights hidden, I could expose most of them to XML, and give them discrete ranges (so, say 0 is bad, 9 is wonderful).
And in the short term, we can make do with weighing via XML.
Spoiler :
Listing problems are useful to debug present AI behavior. I think that in many cases, the present behavior should be scrapped, and replaced with better design, so it's easier to give the AI good behavior. I'll write a bit on the topic.
We should definitely have a look at Better AI; I'm sure that we'll still need to come up with our own stuff for spells, but there might be a lot of good stuff in this already that we can use.
Kael (if you're still reading this thread), what's the current policy on merging Better AI stuff into FFH? Will Fire have anything?
(BetterAI was originally blake's AI, but from the looks of it they've really grown)
Kael (if you're still reading this thread
), what's the current policy on merging Better AI stuff into FFH? Will Fire have anything?(BetterAI was originally blake's AI, but from the looks of it they've really grown)
Chandrasekhar
Determined
Hm... any chance that the AI autoplay mod could be incorperated into FfH? Might make things a bit more convenient for people looking to see how the AI performs.
Much of the present AI appears to be a bunch of separate expert systems. The Tech choosing AI is a good example of this. It essentially attempts to emulate the choices that an expert would make about the possible tech choices by weighing each alternative, then selecting the best of the alternatives (yes, there are problems, but that's poor implementation (and quite possibly a bad expert), not necessarily poor design).
The "standard" process to design an expert system ad initio is to interview an expert other than yourself on the subject, to find out how they make their decisions. (Why can't you use yourself? because you'll make hidden assumptions that you'll forget) Here's a rough start on some questions I might ask on the tech tree to an expert:
1) What is the first Technology you attempt to get? Why? Does this choice vary? If so, what does it vary on? When it varies, what is your first choice for technology?
(ask similar questions for probably the next 4 or so technologies)
2) What is your favorite technology for (choose one of the variances above)?
(ask for each variant).
3) For one of the variances above, what is your full technology strategy? (getting multiple saved games from that expert may be of assistance here)
(repeat for each variance; ask questions about why they go for X before Y)
Once you have these answers, you can then turn towards encoding this decision making process, and weighing the branches.
Of course, one could replace these expert systems with other types of AI, but expert systems are fast, relatively easy to code, and tend to fail gracefully. Plus, a lot of advantages of, say Genetic AI or neural nets are that they can find (and account for) hidden algorithms; I don't think that that is needed here.
The "standard" process to design an expert system ad initio is to interview an expert other than yourself on the subject, to find out how they make their decisions. (Why can't you use yourself? because you'll make hidden assumptions that you'll forget) Here's a rough start on some questions I might ask on the tech tree to an expert:
1) What is the first Technology you attempt to get? Why? Does this choice vary? If so, what does it vary on? When it varies, what is your first choice for technology?
(ask similar questions for probably the next 4 or so technologies)
2) What is your favorite technology for (choose one of the variances above)?
(ask for each variant).
3) For one of the variances above, what is your full technology strategy? (getting multiple saved games from that expert may be of assistance here)
(repeat for each variance; ask questions about why they go for X before Y)
Once you have these answers, you can then turn towards encoding this decision making process, and weighing the branches.
Of course, one could replace these expert systems with other types of AI, but expert systems are fast, relatively easy to code, and tend to fail gracefully. Plus, a lot of advantages of, say Genetic AI or neural nets are that they can find (and account for) hidden algorithms; I don't think that that is needed here.
Kael
Deity
We should definitely have a look at Better AI; I'm sure that we'll still need to come up with our own stuff for spells, but there might be a lot of good stuff in this already that we can use.
Kael (if you're still reading this thread
(BetterAI was originally blake's AI, but from the looks of it they've really grown)
We have already added a few of Blakes changes into "Light". We don't have any plans to add any more, I'm basically watching and waiting for it to get some more testing and tweaking.
But if there was a fairly consise change with significant benifit I would consider adding it.
Im not to worried about the vanilla functions, its the magic ones that we should concentrate on.
Kael
Deity
There is an additional challenge here in that we are changing the game in process. As such an expert decision on version 0.21a may not be the same on 0.21b. Its a moving target and a lot of the reason we haven't concentrated to heavily on the AI.
I still think that there is a huge value in what you are doing, but I would emphasize low hanging fruit at this point. Look for glaring issues, going to specific will hurt us down the road.
If we make the systems generic enough, and more reliant on the underlying information (as opposed to the present value of a particular item), the changes should be less of a problem.
I take it no one tried my code yet? Was hoping Bringa would as he already messed around with this. I know my code is simple, but I wouldn't be surprised if that is all it takes to get the AI to use fireballs more effectively.. Anyways, I'll see if I can't get this compiled and test it.
EDIT -- Ok, got it compiled.. I'll try to figure out how to create that 2 island scenario to see how agressive the new Fireball AI is.
EDIT EDIT --- Bah, runtime error, CTD... bah. Guess I'll have to relook at my simplistic code and see where the logic fails.
EDIT EDIT EDIT -- LOL, duh - guess changing the DLL breaks savegames; was trying to quickly load up a save game where I knew that I had access to fireballs - just to quickly test them out.. and it was crashing.. spent a while looking at the code before I realized that the crash may have been from trying to load up a save game dependent upon the other DLL file. Back to testing.
Was hoping Bringa would as he already messed around with this. I know my code is simple, but I wouldn't be surprised if that is all it takes to get the AI to use fireballs more effectively.. Anyways, I'll see if I can't get this compiled and test it.EDIT -- Ok, got it compiled.. I'll try to figure out how to create that 2 island scenario to see how agressive the new Fireball AI is.
EDIT EDIT --- Bah, runtime error, CTD... bah. Guess I'll have to relook at my simplistic code and see where the logic fails.
EDIT EDIT EDIT -- LOL, duh - guess changing the DLL breaks savegames; was trying to quickly load up a save game where I knew that I had access to fireballs - just to quickly test them out.. and it was crashing.. spent a while looking at the code before I realized that the crash may have been from trying to load up a save game dependent upon the other DLL file. Back to testing.
Maniac
Apolyton Sage
Is it possible to add new flavours without the SDK?
Anyway, if new flavours could be added, instead of one for each civ, I'd suggest one for each tech branch. So...
1) mounted
2) melee
3) recon
4) archery
5) magic
6) religion
7) medicine
...
Ok, here is what I did for a 2 island challenge to test my modification of the fireball AI.
.. 1 1x1 square island with 4 Archmages, each of which could cast fireball with varying other promotions as well.
vs. about 20 archers placed on the main land in various locations so that they were different ranges from the island and so I could move them into and out of range.
The winner? Definately the Archmages. I won't say that they cast fireballs as often as I would have liked (1 per turn) - but none of the fireballs went to waste, which is good news; because I modified the fireball behavior and not the archmage behavior. I saw absolutely no wandering fireballs, and though they weren't all lethal - they did all shoot straight for an archer and after a number of turns (maybe 6-7) all of the archers in range were wiped out, and as soon as I move an archer into range - it was toasted.
EDIT -- one thing though - the fireballs will only go after a target which it has an ok chance of killing. So it will go after the archers, but if I put anything tougher up there then the fireballs choose not to take flight. I may be able to improve this - but I dunno that I'll ever convince them that they are supposed to suicide. Maybe if I compare them to a catapult, give them 100% retreat - that might get them to suicide since they'll expect to live through the attack..
Fireball A: There is the target! Attack!!
Fireball B: This Swordsman is a lot toughter than he looks!
Loki: Ruuun-a-Waaaay!!
.. 1 1x1 square island with 4 Archmages, each of which could cast fireball with varying other promotions as well.
vs. about 20 archers placed on the main land in various locations so that they were different ranges from the island and so I could move them into and out of range.
The winner? Definately the Archmages. I won't say that they cast fireballs as often as I would have liked (1 per turn) - but none of the fireballs went to waste, which is good news; because I modified the fireball behavior and not the archmage behavior. I saw absolutely no wandering fireballs, and though they weren't all lethal - they did all shoot straight for an archer and after a number of turns (maybe 6-7) all of the archers in range were wiped out, and as soon as I move an archer into range - it was toasted.
EDIT -- one thing though - the fireballs will only go after a target which it has an ok chance of killing. So it will go after the archers, but if I put anything tougher up there then the fireballs choose not to take flight. I may be able to improve this - but I dunno that I'll ever convince them that they are supposed to suicide. Maybe if I compare them to a catapult, give them 100% retreat - that might get them to suicide since they'll expect to live through the attack..
Fireball A: There is the target! Attack!!
Fireball B: This Swordsman is a lot toughter than he looks!
Loki: Ruuun-a-Waaaay!!
I don't know if it would be a good idea to program the AI to suicide its fireballs in every situation, anyway - otherwise a human player could just park a sufficiently strong unit next to a group of enemy mages, let them hurl useless fireballs at it, and watch the experience counter go up by each battle.
Maybe, but mostly I'm concerned with getting the AI to actually use fireballs against me. I'll worry about whether the fireballs should suicide or not once I see the results in a game of suicidal fireballs. Besides - I'm mostly doing this to see if it can be done.. the FFH team will need to decide upon what direction they want to go in - and that is what the majority of players will get.
That isn't a bad alternate. Frankly, we could do all of the above (although I'd start with one way of organizing flavors first).
I don't see any reason why flavors couldn't be an XML-only change. The list is in XML (GlobalTypes.xml); just change the list (or add the new ones) and use it instead of the present list. Then seed the numbers with reasonable values, and balance them until they work well.
Note that the present areas use flavors:
Units
Buildings
Technology
There's no particular reason why we'd need to use the same set of flavors for each, so we could organize buildings differently than Technology.
Maniac
Apolyton Sage
Aargh, I got cloned!
