More thoughts on AI.Up until now (Enhanced AI), it has been sorceries and creaturs which could be handled with some optimization within a relative simple "allround AI". In the future with magic cards and with more different kinds of cards and actions more must be considered.
Since in general a computer AI is not intuitve and has "good" ideas created out of thin air... an AI will (most of the time) be based upon computations. Computations in the means of ...
I try a lot of variations of my current possibilites, weight them in some way and chose one that in my weighting process wins.
As of now in JPortal there are two such processes.
Computations of creature battles
Computations of sorcery cards
Which at the moment are independend of each other.
My goal for the future "enhanced AI" is that the AI will "think" in terms of one Round, meaning the collection of all phases and substeps of one round. The AI will plan one round starting in the UNTAP phase and will lay it's path out till the ending phase.
Upon each step on it's way AI should evaluate the situation anew and thus will be able to react to the doings the other player did.
One of the main hinderences on the ways is the sheer multitude of choices available to the AI. My first goal therefor is to build a "simulation" (or actually many) which the AI will use to judge the current situation.
A brute force method here is virtually not possible to realize. You will see why, while I keep on explaining what I am up to right now.
I started of with making a "better" combat simulation (all the while I found some mistakes in the old one - which will probably NOT be corrected).
Let's assume combat situations. Player 1 has three creatures and Player 2 has 3 creatures with whih he may block.
The effective combinations the attacker may chose to attack with are A B C AB AC BC ABC
Order of attackers do not matter!
The effective combinations the blocker may block with are: A B C AB BA AC CA BC CB ABC ACB BAC BCA CAB CBA Order of blockers do matter!
All different variations put together give the amount of 105 different combat situations, which an AI may use doing a brute force attack. 105 doesn't sound like much, but just advancing to a battle of 7 attackers and 7 blockers result in 127 differnet attacker possibilities and 13699 different blocker variations. To do a calculation how many differents combat situations that give (building classes for comencing battles) gives with my computer an "out of memory error".
The old AI gives up on that stage. It just says - the largest battle I do is 4 versus 4. If any greater battle is in order I divide the attackers and blockers to equal sized chunks smaller that 5 and handle the situations by divide and conquer. Which gives acceptable results, but not the optimum.
I tried to figure out sensible reduction schemes which will generate acceptable small variations which might be simulationable.
Example. Right now I am experimenting with 5 attackers and 5 blockers. Attacker 31 variations, Blockers 325 variations → which results in 25945 uniquly different possible combat situations.
To be able to visualize the doings I created a battle simulations screen, in which I can try different settings. I can list the permutations of attackers, blockers and all combat variations.
Right now I have found 5 noteworty elemination strategies.
Only use full blockerlist (Meaning I only test battle situations where all blockers are used - "unused" blockers can be elemintated later on) This is a good one since it reduces the combinations of blockers, BEFORE I create all battle combinations. The Blocker variation with that is reduced to 120 and all combat permutaions are reduced to 6960
Blocker in defensive order In most situations it is clever to only use blocker combinations with descending order of toughness value, meaning the toughest one does the first blocking... This (in the special case of my attack list) reduces the blocker permutaions to 31 and results in combat permutations of 7775. This is also a good one since it reduces the combinations of blockers, BEFORE I create all battle combinations.
Remove unblockable attackers If there are attackers which are unblockable by all blockers, than these can be removed from the evaluation, the attackers will be added later manually, we can't do anything about them anyway This is also a good one since it reduces the combinations, BEFORE I create all battle combinations.
Remove unblockable blockers Remove blockers which can not block at all This is also a good one since it reduces the combinations of blockers, BEFORE I create all battle combinations.
+ d) Find combinations of attacker / blockers, which are not possible (flying / non flying... eg) This "bad-combination"-list can be built beforehand. While building the permutations of combat formations this can be checked and the combinations and all subsequent branches can be removed.
Remove non effective blockers This must be done during the building of all battle permutations and do a "first step" simulations of a battle on the fly. If a blocker is not effective (Meaning:
Attacker can not be killed by blockers, than only at MOST one blocker should be used
if the first n blockers killed the attacker, than all n+1 blockers are useless) the combat combination will be removed (and all subsequent "branches")
Doing all of the above, results in my test 5 versus 5 in VALID battle permutaions of " only " 24! Meaning this is only 1/1000 of the original battles to simulate!
I am still looking for further optmizations.
Right now I am thinking about:
Attacker evaluation
If simulating a "blocker" situation, find a prioratized Attacker combintaion to block. e.g.
Block power descending, meaning block most powerfull creatures first
Block preffered 1:1 kill creatures, meaning try to kill an attacker by one single blocker etc