Diplomacy
|
Home > Diplomacy > BlabBotBase > Exotic Press
AI in the Game of Diplomacy: BlabBotBase: Exotic Press
Exotic press is any form that is not recognised by the latest released versions of the official Server and Mapper, even if officially defined and documented. For sanity, exotic press should retain the official interpretations of any official forms of press, but existing forms may be extended, by adding additional forms of sub-expressions, or totally new forms may be added. Usually, but not always, any such extensions would only be recognized by one of a few kinds of bot. Some exotic forms would only by used internally within a bot, to represent a idea that is useful internally, but which would or could never be sent or received – see Internal Press.
Exotic forms of press are normally rejected by standard Server (but this is not guaranteed, e.g., duplicate terms cannot be rejected; replies are unnecessarily accepted within replies!), and they cannot normally be displayed or generated by standard Mapper (within its limitations, e.g., duplicate terms cannot be rejected; numbers and strings cannot be handled). To enable exotic forms, appropriate definitions must be added to the language definition files. Generally, to avoid confusion and incompatibility, it is best not to change or remove any official forms, or their interpretations; only add forms – let players simply ignore any (official or exotic) forms that they cannot handle, using TRY to specify which forms they can handle. However, Mapper's transliterations of any (official or exotic) form may be made more precise, or adjusted to the taste of each player.
Unfortunately, there is currently no way to add new tokens to Server or Mapper without recompilation of cspdll.dll, but that source is are not currently released, and cannot, be because it includes proprietary software. Nor can more significant changes by made to Server or Mapper without their source files, which are also not currently released. To circumvent this problem, we are currently forced to reuse existing tokens! Reused tokens are generally non-mnemonic in their new roles, but Mapper can be made to use suitably labelled buttons and meaningful transliterations, thereby hiding the problem from players; it is then only an annoyance to developers, and even there it can be hidden from most code. Any fixed (named) tokens that are unambiguous in their new roles may be reused, but those which are not officially used at all in press are recommended, as they are likely to lead to less confusion, or, indeed, accidental ambiguity – the THX note tokens offer a convenient selection.
Although not a problem in the immediate future, independent developers might happen to reuse the same tokens, possibly leading to ambiguity, and lack of independent control by TRY, if using incompatible bots in the same game. In any case, language files would then have to be manually merged. Clashes could be minimized by pre-allocating disjoint sets of substitute tokens to different developers. Ultimately, as the choice of tokens is limited, some remapping of the tokens used by a given bot may be required; BBB allows default exotic tokens to be changed by command-line arguments.
To simplify any future remapping, internally BBB uses fixed, distinct token names and associated values. Equally, any tokens saved in any persistent client files (excluding logs) should equally have fixed names. To ensure that there are no clashes with current or future official token names, including powers and provinces in any game variant, three-letter names are best avoided for exotic names.
With hindsight, perhaps it would have been better if all types of message had been in text form, leaving tokenization to be a private implementation detail, internal to the clients. (Compression of such short messages over the network is unimportant; the text form is needed for logging anyway; standard string manipulation routines could be used during generation and parsing. Apparently cspdll.dll has an option to translate between token and text forms, but new tokens still need to be compiled in )
The syntax used by Server and Mapper are defined in text files in the same folders as the executable files. There is currently no official documentation, but the main features required can easily be determined by inspection of the definitions of official forms that are similar to the proposed exotic forms. Below are some empirically discovered details; as such they may not be quite correct!
The syntax is specified in server_language.txt. General rules:
The syntax is specified in language_encoding.txt. The general rules are the same as for Server, except:
The following exotic examples are illustrated by BBB, if enabled by a command line argument, and associated Server language definition and Mapper language definition files are used. Reused tokens are listed in comments at the end; recommended for future additions too. In case of a clash with the substitute tokens used by other bots in a given game, the language definition files must be edited, and any changes to BBB's replacement tokens must be specified to BBB bots by command-line arguments. To avoid clashes with official token names, including those of any possible game variant, exotic token names should avoid three-letters names. To avoid clashes with official token values, BBB's convention is that the values of any exotic tokens that may be used externally (transferred between clients) are in the range 0x5C00 to 0x5CFF.
Although now officially agreed and and documented, there has been a long delay in their implementation in Server and Mapper. [Official release may now be imminent [2010-10-10], but a similar pre-release mechanism may be useful in future.] By implementing them as exotic tokens, their semantics can be used without delay. In this case, their three-letter names are official, so are best used, albeit their official values are yet to be defined. FCT(arrangement) has also been moved to game level 10, as specified in the same update to the official language.
CHOICE is a semantic equivalent to CHO that can be implemented in the current Mapper. Because numbers are needed for the range, but cannot currently be input in Mapper, exotic tokens are defined for each digit. For simplicity, only single digits range values are currently implemented, which should normally be adequate, but beware: it may not be adequate for some bots, especially during testing! (There is a peculiar bug however: a spurious "No prompt" button is also generated, which generates a spurious field!) This alternative format could be defined for CHO, as well or instead, but then clients would not know which form to use!
CONTINUE is a fundamental statement, with no arguments, meaning "Undersood; please continue": much like grunt, smile or a nod in a normal conversation to keep the conversation going. (Also a bit like continue in C++.) It is provides an important mechanism to optimize conversation speed; analogous to faculties in many other protocols. It indicates that the sender has nothing worthwhile to say at present; the recipient is advised to say anything else that he currently has to say, rather than waiting for a response to what he has already been sent. It has the lowest urgency message to be sent; it should be suppressed if the last message from each participant in a given discussion was CONTINUE (to avoid repetitive CONTINUEs by all participants!). It is distinct from saying nothing: receipt of CONTINUE indicates that the sender has decided that he has nothing more useful to say at present, but would be interested in receiving further messages, whereas absence of any message may instead indicate that the sender has not yet interpreted previous messages or decided what he wants to say, or a new message is still in the process of being composed or transferred. Without CONTINUE, some recipients might otherwise carry on waiting forever, or may wait unduly long before continuing anyway.
CONTINUE is an illustration of an exotic form that is available for immediate test, pending a possible formal proposal for it, and maybe eventual official acceptance and implementation.
TRUE, FALSE and VOID are constant arrangements, with no arguments. TRUE and FALSE represent unconditional constraints; the only possible values that any arrangement may ultimately prove to have. VOID represents no constraint either way. They are examples of internal press, so need no changes to any language definition files.
Internal press is a subset of exotic press that can only be used internally in a bot. They therefore do not need to be made known to cspdll, Server or Mapper, or any other client or player. BBB's convention is that the values of any exotic tokens that will only be used internally are in the range 0x5B00 to 0x5BFF.
A common example is a list with less than the official minimum length. Such lists can be useful internally if they are still meaningful when interpreted in a general way. It then allows any such instances that may be generated internally to be handled in the normal way. Internal press must not be sent, and is HUHed if received. But BBB would only send canonical forms, and such lists are always canonicalize to simpler forms; often eliminated. For example, if AND is interpreted as a list of arrangements that must be TRUE for the whole to be true, then AND(x) canonicalizes to x. An AND with an empty list canonicalizes to VOID, meaning constraint. So PRP(AND) canonicalizes to PRP(VOID), which canonicalizes to CONTINUE, since no constraint is proposed, nor is any other more worthwhile statement implied!
It is not currently possible to run non-standard game levels from Server's Windows interface, but may be possible using Server's command-line interface (not tested). I recommend any experimental levels be 1000 or more, or not be divisible by 10, so that they will tend to avoid any new official levels. Alternatively, experimentally modify standard levels, so that Servers Windows interface may be used.
(This in not currently implemented in the example language definition files.)
In level 2000, more complete variations of various official forms are enabled. Lower levels could be defined for finer of control of exactly when to enable each extension.
For instance, IDK(HOW(power)) is not an official form, and is normally rejected by Server, but seems a natural reply to HOW(power) if the responder does not know how to deal with the specified power. Likewise, for HOW(province) and WHT(unit), and any otherwise excluded reply. Also, WHY makes sense with any otherwise-excluded statement or reply.