Internal AI
The moment mentioned in above chapter is over. There is a third AI - I like to call it Enhanced AI.
This AI is internal - meaning it is not implemented as a script, but rather in Java and loaded by a classloader mechanism.
Internal AI's can nonetheless added by a configurational approach. The criteria such an AI mus fullfill are:
it must implement the interface:
AISituationHandler
it must be set in the configuration
Actually, since only one known implementation of that interface exists, right now the configuration of the AI is heavily linked to the provided code of JPortal. This might / might not change in future, this depends if there ever is another programmer willing to add an additional AI :-)!
Internal AI
To configure an internal AI, you have to:
check the checkBox Internal AI
provide the classname
Inspite of the EAI being a class that can be loaded "on the fly" - the configuration TAB is hardcoded. That is - from a programmers point of view - inconstistent. I will propbably change that in the future.
Anyway
You can switch to the Tab called Internal AI and see:
Internal AI Config 1
... many checkboxes.
The default ones should be ok for most needs. Here a short explanation of each setting (tooltips also show a small help!).
Most options that can be selected here influence the speed / memory consumption / number of choices the EAI (Enhanced Artifical Inteligence).
If you change settings here to "bad" values it might possibly result in JPortal running out of memory and or taken lots and lots of time for an EAI-turn.
Be sure you understand what a setting means befor you change anything.
Max EAI depth
How many phases the EAI simulates befor it choses the best path.
This used to be just a "hard" number (of phases) but shifted to being a "soft" describtion of target phase. Following values can be chosen:
One Phase
Till end of Combat
Till just befor opponents turn (complete players turn!)
Resolve of opponents combat turn
(not an option right now / but implemented: Resolve of NEXT player combat turn)
The last not open option is closed due to the facts:
many many more choices must be made (but that is not the worst)
in the combat phase of the opponent, the "worst" scenario is taken, which usually means that the opponent does an all out attack
while using THAT scenario to evaluate our own combat is good, it is a bad scenario for our own NEXT attack, since most opponents crearures are than tapped, which quite possible makes EAI's own next attack quite possible a (dumb) all out attack... etc
therefor in order to do a really smart opponents attack (which we still can not be certain it will do) takes again much computational power and does (IMHO) not really much good
till someone (or I myself) gets an idea how to handle that
sensible
efficiently
I will skip that particular option. . .
Note:
The actual phases simulated is not fixed.
Meaning, if you chose "Till just befor opponents turn" and EAI plays out the card "Temporal Manipulation" than the actual phase count doubles! This means cards can actually influence the amount of phases EAI uses to find a good move!
Max EAI width
How many choices per phase are taken into account. Only the top local scores are taken into account.
What this means:
In each phase the EAI generates moves it can make. The possible choices made for one phase are (inetrnally) represented in one branch of a "choice"-Tree. Each of these branches can be scored locally. Locally here means scored befor evaluating the next phases.
With this option you can limit the choices that are taken into account for further evaluation to only the TOP #number# of scores.
This might lead to non-optimal choices!
Since EAI can possibly not properly evaluate MAIN Phase 2 choices. (sometimes it is better to play certain cards in Main 2 instead of Main 1. If limitted - than possibly these options drop out of the scheme)
Note:
0 (zero) means - take no width reduction (recomended)!
Reduce library chosing to
How many targetting choices per phase are taken into account - the top X scores are taken.
This optimizes library access. "Chose a card from library" would in a dumb sense explode permutations to library size... (0 is unlimted, default 5)
Note:
The #number of cards taken into considertaion are not random, or tops. An algorithmic apporach is taken to insure sensible chosing of cards!
If land can be played, force Main 1, played first
If checked the decision tree is optimized in that
if a land is on hand and can be played - it is played as first action, and only in Main 1
also same type of lands on hand are reduced to 1 land this is a very easy way to reduce the decision permutations - and should not effect scoring in any relevant way.
Scoring collection active & Internal Scoring
either select internal scoring, than the hardcoded scoring and weighting is used (faster, FASTER!).
or select a custom scoring / weighting (see second Tab)
Only leaf scoring
If checked not all nodes in the decision tree are scored (branch count in tree), but only the leafs of the tree. In my example this reduces scoring to about 1/4 (from over 4000 to about 1000).
This should not make any difference in play (except slower/faster). If debugging a branch scoring might be interesting! (default is nonetheless off - since I debug a lot!)
Try to decide between good /bad
Try to estimate if a card is a "good" or a "bad" card.
good: heal, buf, generate mana etc
bad: damage, debuf, move to grave
neither: there are cards which might be both - under circumstances
If estimated a good card → evaluate targets only from player.
If estimated a bad card → evaluate targets only from opponent.
If neither good/bad → evaluate all choices.
If not checked, all variations are allways scored.
Maximise target selection
If a range of target selection is possible, say 1-3, allways try to maximize target selection. If not checked, all possible choices (all permutations of these too) are evaluated.
Do forceable attack on no blockers
If opponent has no creature → force an attack (within limits - meaning: if EAI has low life, it might decide for a blocker to remain). If not checked, all possible attack variations (permutations) are built and scored.
Do quick reblock analyze
If checked, the algorithm for attack generations does a quick scan of blocking possiblities (and re-attack). This reduces permutations built. If not checked all attacker combinations (permutations) are build and scored.
Note:
Not implemented!
Try simple attack
If checked, it will be tried (if many attackers) if attacker / blocker can be reduced by each other so that a # of attackers remain with no blockers left. After that a simple attack may be initiated - only meaningfull together with:
Do forcable attack on no blockers.
Try extreme testing
(only atacking for now)
If checked, AI will try if many attacking choices can be made, to evaluate extremes:
no attacker (+1)
all attacker (-1)
non blockable attackers
sorted attack power / toughness increase and decrease
If one of these extremes evaluates to a higher score than all others, it is assumed, that this one is the best.
Reduced activation evaluation
If checked, activations of any kind that are possible in ALL phases are tested only in Main1, Main2 or in opponents attack→block phase.
The combat system of EAI has two different entities.
Being the usuall - try all out that may happen. This strategy (within configuration limits, see above) is used for attacking!
Blocking is a different matter. Evaluation of blocking is using an entity called "CombatSimulator", which can be fine tuned much more efficiently than the "brute force" EAI approach.
Settings under "Combat smulation settings" (as the name suggests) relate to the second entity!
Note:
You can NOT see the blocking variations in the EAI-Debug Window! The Debug Window only displays choices made in entity 1!
See also: Battles
These setting influence the CombatSimulation built by the Enhanced AI. The amount of permutations of blockers is greatly reduced, if these schemes are enabled. Disabling some or all of them might result in very lengthy operations and/or out of memory errors.
Only full blockerlist
Meaning I only test battle situations where all blockers are used - "unused" blockers can be elemintated later on.
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...
Remove non effective Blockers
A blocker is not effective when:
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
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
Remove unblockable blockers
Remove blockers which can not block at all
Try simple block
If checked, on blocking it is checked if "simple" blocking mechanisms can be taken. Such as block without loss and kill / block all attackers.
Use scoring in block evaluation
If checked, AI tries to evaluate blocking with additional scoring information, rather than try every possible combination.
This is not implemented yet!
An EAI strategy for own blocking is not "really" implemented yet. The EAI uses the setting found under this section as well.