(Last Revised Mar 23, 2013)
Here are some of my programming notes about Albert's use of press. This might be helpful to players or other AI authors that are trying to understand some of Albert's communications. Some of the press listed below may not be available in the most recent downloaded version, but are in progress in the lab.
Links to the first ever DAIDE press game.
Daide Complete Log file - Example from the first DAIDE press game between all humans
Daide Message only Log file - shows DAIDE message syntax from the first game.
Press that Albert Understands
- Peace Agreements (PCE) and NOT(PCE)
- (PCE) is considered the basic start to a relationship.
- makes proposals for single paired powers. ex:PRP(PCE(ENG FRA))
- will consider proposals for multi-power agreements. ex:PRP(PCE(ENG FRA GER))
- will consider 2-way NOT(PCE). ex:PRP(NOT(PCE(ENG FRA))
Breach:
- breach of (PCE) is an act of war, and cancels all other agreements.
- breach occurs when the other power:
- Alliance Agreements (ALY)
- An alliance is an extension of a PCE relationship against a common enemy.
- makes proposals for single paired powers against a single enemy. ex:PRP(ALY(ENG FRA)VSS(GER))
- will consider proposals for multi-power agreements. ex:PRP(PCE(ENG FRA RUS) VSS(GER ITA))
Breach:
- there is currently no required activity to keep the alliance active.
- DMZ Agreements (DMZ) and NOT(DMZ)
- makes proposals for two sided DMZ agreements. ex:PRP(DMZ(ENG FRA)(ECH))
- makes proposals for single sided DMZ agreements. ex:PRP(DMZ(GER)(NTH))
- will consider proposals for multi-power and multi-province (DMZ) agreements.
- will consider proposals for multi-power and multi-province NOT(DMZ) agreements.
- will consider 1 and 2-way NOT(DMZ) freely. ex:PRP(NOT(DMZ(ENG FRA)(ECH)))
- will consider multipower NOT(DMZ) under specific sender requirements. ex:PRP(NOT(DMZ(ENG GER FRA)(ECH)))
- It keeps track per turn and accross turns what has been offered. Provinces will only be offered 2 times as a DMZ.
Breach:
- breach of (DMZ) is an act of war, and cancels all other agreements.
- breach occurs when the other power:
- Order Agreements (XDO) and NOT(XDO)
- makes proposals for support agreements. ex:PRP(XDO ( ( ITA AMY PIE ) SUP ( GER AMY BUR ) MTO MAR)
- will offer support and request support
- will consider proposals for NOT(XDO) arrangements
- will consider proposals for multi-power (XDO) arrangements
- will not consider orders during adjustment phases
Breach:
- breach occurs when the other power doesn't do what it says it will do.
- No Arrangement Agreements (NAR)
- will not make NAR proposals for a draw.
- will consider and usually accept NAR proposals.
- Draw Agreements (DRW)
- will not make proposals for a draw.
- will consider proposals and respond based on its current draw flag setting.
- Solo Agreements (SLO)
- will not make proposals for a solo.
- will consider proposals and respond using very basic logic.
- If the identified power is the recipient, he will accept. Otherwise he will reject.
- Replies, YES, NO and I'm not telling (YES)(REJ)(BWX)
- (BWX) is treated as a reject to a proposal.
- And/Or (AND)(ORR)
- Albert currently will consider these tokens, but will not produce messages with them.
- Other AIs Capabilities (TRY)
- Albert keeps track of the most recent TRY message sent to it, and will only send press tokens that the other AI can understand.
- Reply (HUH)
- Albert treats a HUH as a reject to a proposal. It does not search out the ERR to identify what the problem may have been.
Arrangements
- 'Arrangement' is the word given to the subject of DAIDE discussions. Arrangements can be proposed, insisted on, queried about, stated as fact etc...
- Arrangements that are proposed and agreed upon, such as PCE are for a long duration, or for (XDO) are for the turn. Each arrangement has a different duration.
- new arrangements of equal (or greater) duration that conflict with existing ones, are considered to overwrite and replace the previous ones. Upon removal of the latest arrangement, there does not exist any remnants of the original arrangement.
- new arrangements of lesser duration that conflict with existing arrangements are considered to be 'exceptions'. Upon removal of an 'exception', the full original arrangement remains intact.
- arrangements are simply a sum of there parts.
Example:
ENG->FRA: PRP(SCD((ENG HOL DEN)(FRA BEL MUN)))
FRA->ENG: YES(PRP(SCD((ENG HOL DEN)(FRA BEL MUN))))
FRA->ENG: PRP(SCD((FRA HOL)))
ENG->FRA: YES(PRP(SCD((FRA HOL)))
ENG->FRA: PRP(NAR(SCD((FRA HOL)))
ENG->FRA: YES(PRP(NAR(SCD((FRA HOL)))
At this point there is no arrangement to how HOL will be shared out.
Deceitfulness
Albert starts the game with a random predisposition for being deceitful. This is combined with a random number each time it responds to a piece of press to a player that it has identified as an enemy. If Albert's honest answer to a proposal would be to REJ it, this can possibly be overriden to respond as a YES. It currently is honest with allies and neutrals. It also does not generate deceitful proposals yet.
Press Message Flow-Control
Albert uses a simple method of 'furthering negotiations' with a specific power. Only when no outstanding proposals concerning that power are in play, will it consider sending new proposals to that power. Hopefully this is adequate enough to ensure Albert doesn't bombard a human with multiple proposals at the same time. Seems to work.
Albert will delay messages to 'appear' to be human, I expect to modify its current delays at some point in the future. The can be disabled by the '-t' paramater, just like other delays.
General Press Issues to be resolved:
DAIDE ISSUE: (unsolicited replies)
How to treat incoming replies that are not associated with any outstanding press. This would include unsolicited replies, or multiple consequtive replies to the same press. This is a higher priority for me as it seems that unsolicited replies are easily generated by the AImapper.
example:
x sends PRP(PCE(x y))
y sends YES(PRP(PCE(x y)))
y sends REJ(PRP(PCE(x y)))
ALBERT CODING:
I expect that I will code Albert to just ignore replies that don't match any press for the turn. I am not sure whether you can HUH(reply).
As for consecutive replies. I expect to ignore the second reply. There is no mechanism for cancelling, and Albert is based on the principle that a 'new' proposal must be made.
DAIDE ISSUE: (End of Turn Control)
There is no server protection against a message being deployed to a AI client, and the turn processing before the receiving power is able to send a NOT(GOF). This would result in the message not being considered.
ALBERT CODING:
Albert resolves this by currently not setting its GOF until all outstanding proposals (PRP) have been responded to, or a 25 second delay has passed. In combination, Albert will always respond to a proposal with YES,REJ or BWX.