Extended Etiquette

Home > Diplomacy >  Extended Etiquette

BlabBotBase for AI in the Game of Diplomacy: Extended Etiquette

Introduction

Here are the rules of Etiquette that I would apply within my TinKing project; BlabBotBase (BBB) compliant bots would try to obey them and expect them in return. I would recommend them for more general use too. They incorporate the DAIDE Standard Etiquette Rules, slightly modified where noted. They apply to all formal games, and most other games, but exceptions may be agreed for experiment or fun.

Where applicable, BBB Etiquette is the default BBB Press Protocol (PP) Rule. Etiquette defines a code of  behaviour, that is assumed to have a immutable  (supra-game) consensus between all players. Etiquette Rules are intended to help make games more interesting, playable, practicable, and in keeping with aims of the TinKing.project.

A breach of Etiquette is rude: if considered serious enough by those it affects, it may be grounds for the culprit to be subject to sanctions, such as disqualification from the current game or tournament, and even exclusion from some or all future ones and generally shunning if ongoing. Such a breach will tend to spoil the game as a whole, albeit may sometimes make some immediate gain for the offender. Unfortunately, such breaches are generally not absolutely provable; usually a matter of opinion and normal practice.

In contrast, a breach of Press Protocol may only tend to degrade the performance of the offender, and maybe those who would profit from good communication with him. Such But others would tend to have a net gain, in the long run, if they do not accurately follow a commonly used, high quality, protocol – so they have no cause to complain. However, until a firm consensus about a Press Protocol has formed, between active bot producers, breaches will tend to be common. Unlike Etiquette (official or otherwise), no stigma attaches to any breach.

The order of rules is not significant; their numbering is not immutable. The bullet points after a Rule are mere notes, with no formal significance. Formally defined terms, defined in BBB Press Protocol, as well as critical points, are italicized.

• It is also important not to attempt to identify other players; they might be close kin, who, similarly to clones, could also be unfairly allied with; they might be champions who could then be unfairly allied against. (BlabBotBase (BBB) will have command-line options to inform the bot of team assignments – but not identities – which could acceptable in some games.)

• DAIDE rules, in general and here, are designed to avoid excessive complication and intelligence for bots for a given level of play.
• Server cannot reveal illegal orders that are sometimes used for signalling.
• Players should try to avoid specifying an order in a more complex form that  necessary, such as specifying a Hold  nit as a plain Hold, but as, say, a hold or convoy where he has not also submitted any necessary orders for his associated units. Such orders look silly at best; at worst they look like secret signals.
• A player need not consider whether necessary orders for associated units of other players is plausible; only possible. So, for instance, a support or convoy for a unit of another player is acceptable as long as any necessary orders for his associated units are possible of each individual order to succeed, no matter how implausible. (Players are not required to be intelligent enough to realize what is and is not plausible.) Nevertheless, although an order that seems silly if not a secret signal is not banned, it should still not be a secret signal. However, advanced players are advised to avoid requiring implausible orders, to avoid suspicion, because such a silly or over embellished play may then seem implausible.
• It is acceptable to submit orders that other players could not simultaneously execute, such as supporting a given unit of another player into more than one destination, as long as each separately is possible. (A player may reasonably try to cover each possibility, even if all are simultaneously impossible.)
• Some special, publicized, conventions may be appropriate, even essential, as in the use of DRW in the BBB Press Protocol.
• As far as possible, any conventions should be as natural as possible, avoiding totally artificial ones (analogous to some recognised Bridge Conventions.)

• The other side of Rule 2.

• Ideally, a bot author should publish such details of his bots
• Secret languages must not be used, but any public variation is permissible if mutually agreed, (In that way, potential future enhancements can be checked out. Botchi makes this possible – which necessarily uses Free Text, where, syntactically, anything goes!)
• Any interpretation should be consistent with the Diplomacy AI Development Environment Message Syntax (the [DAIDE] Syntax Document for short) document unless there are strong reasons to diverge; normally no more than a clarification would be required.
• There should also be an official document to define recommended sequence of  use, that is, the rest of the official protocol. It could all be in the same document, but would better contain "Protocol" or "Language", rather than "Syntax", in the title.

• Note the reversal of "not try" to "try not", compared with the official Etiquette. Certainly a player should not deliberately try to swamp other players with press, but nor should he send even small amounts of press that are likely to be irritating and not useful. (Humans are particularly likely to be annoyed and unduly distracted by unwanted, or fairly useless press, unless they have excellent tools for organizing it, including filtering and ordering facilities.)
• Messages should not be unreasonably long. (The official Etiquette might seem only to constrain the number of messages. And AND, say, has no fundamental limit, but eventually becomes unmanageable, to human or bot.)

Rule 7: A client shall not deliberately waste or consume computer resources in order to deprive other bots.

• The main resource may be CPU time, but other resources, such as memory, network throughput or disk access, are included.
• Reasonable efficiency makes the bot more useable (as well tending to improve its performance).
• Especially important if the bot is sharing the same resources. It is desirable to be able to run games as fast as possible. Without this rule there could be a pointless arms race to claim huge number of pointlessly looping CPU-intensive threads, say, just to lock out bots that really need CPU time.

• For instance, a bot may reasonably run as many CPU-intensive threads as there are CPU cores, and maybe a very few more to allow for idleness while assigning new work to threads, to avoid leaving any idle. But any such additional CPU-intensive threads should run at lower priority to avoid disrupting other bots. A bot running an excessive number of CPU-intensive threads merely deprives other bots – or other threads of its own – rather than usefully utilizing spare CPU time. Without this rule, there could be a pointless arms race to claim huge number of CPU-intensive threads.

• JPN.TRY is an exotic token, analogous to TRY, used to specify further exotic tokens that can be used in Botchi.

• Indeed, best to take steps to avoid it, and to minimize loss of data and common knowledge upon a reconnection.

• A more formal equivalent of this Rule is a formal BBB Press Protocol rule too, but is good etiquette, whatever formal protocol is followed.
• As soon as a player is ready for EOT:
  • He should inform Server – by sending all required orders and a GOF after any NOT(GOF) – to allow EOT to happen, when all other players are ready.
  • He should respond appropriately to other players to enable them to become ready for EOT.
• Even though a player may discover better orders or press to send, given enough time, and is allowed to continue up to the time limit, he should not continue for negligible expected gain (depending on the importance of the game). Indeed, no point if major competitors  may gain even more by delaying EOT.
• As time limits, for a given phase, must be adequate for the most complex plausible cases, then to enable games as finish as soon as possible, it is important that players cooperate to enable early EOT in other turns.

• A more formal equivalent of this Rule is a formal BBB Press Protocol rule too, but is good etiquette, whatever formal protocol is followed.
• As soon as a player is ready for EOG, he should inform Server – by sending at least a DRW – to allow EOG to happen, when all other players are ready.
• Even though a player may often have some chance of improving his game-score, he should not continue for negligible expected gain (depending on the importance of the game). Indeed, no point if expected loss, even though a gain is possible, by delaying EOG.

• It is important that players are able to communicate effectively, otherwise, in the limit, there would effectively be no press.
• It would be an undesirable diversion for there to be any incentive to create private protocols, or to try to discover the protocols of others, let alone multiple protocols. Otherwise there will be undesirable diversions from the goals of TinKing and DAIDE.
• The BBB Press Protocol defines that which BBB-compliant players must behave. From time to time, I may modify those rules, as I think fit, always to be what I believe are currently the optimal ones to use or work towards. They will be what I believe are absolutely best, unless and until I believe that my DeepLoamSea bot would be overwhelmed by enough good bots that tend to use different rules, so degrading its performance in typical competitions, especially within DEMO. Inasmuch as my rules are good, and well documented and publicized, hopefully they will be what the majority will converge to, or nearly so. Official adoption would be ideal.