Bots Query Mode

Bases

Here the current subject is bots query mode specification. Query mode by keywords has been chosen. Each bot possesses a set of words, with which are associated answers.

Each bot will have to answer the following keywords:

• Name

• Job

• names of the creatures known by the bot

• names of locations known by the bot

Whereas the first two keywords are static, the following ones will be dynamic and will rely on bot memory. However, we have to nuance the staticity of the first two ones: a creature can lie or change job.

Keywords should also allow to move forward in a conversation:

But they can also be used as the thread of a quest:

Active Bots

Until now, we considered bots as completely passive, only answering players queries. But there is no reason and to the contrary bots should be more active in conversation.

They can propose discussion subjects (talk about the weather, local news), start a discussion with a passer-by (be it player or not), especially if the bot has something to sell.

Janselmeer can say his true name (1) or not (2). Both answers will be accepted by the guard. Janselmeer will be known until that moment under the name he gave (Janselmeer or Oumph) by this guard, and potentially by other people in town.

Now, let's take this example again but the guard already knows the name of Janselmeer.

Here, the guard waited 'Janselmeer' as an answer. Any other answer, for instance 'Oumph', can be interpreted as a lie by the guard.

This examples allows to touch two new aspects. First is the temporary addition of extra keywords. In the example above, it's Janselmeer which has been added.

Second is the more interesting integration of player answers into the bot memory. In the examples, the guard will remember that the name of the player is Janselmeer. Of course, nothing prevents lying but the example shows incurred risks in a simplified way.

It can happen that one does not wish to answer questions. In this case, a creature can use the keyword JOKER to mean it.

The lack of an answer (after a limited time) could be considered as a refusal to communicate too.

Players will generally use the second solution and bots the first one. If players have to use JOKER, it would be better to alias it as "..." (or something else) in the UI, that is more explicit.

Communication between bots

Let us apply what we previously defined to communication between 2 bots. Let us go over the guard example again.

The main difficulty to achieve this is that the guard does not know that he talks to a bot. The one whom the guard talks to should be able to understand whether it is a bot or a player.

In order to make sure he is understood, the guard must therefore speak to his interlocutor in a way understandable by players and non-players alike. Moreover, if there are other creatures who listen to the conversation, they will hence be able to understand too, whether they be bots or players.

The solution that the example suggests is to integrate into a message both the short version interpretable by bots (corresponding to keywords), as well as a long version for players.

When a bot or a player sends a message which can not be understood or which does not need an answer, the short version will be empty. No processing will then be done in order to interpret the message. On the other hand, it could be repeated.

Application to user interface level

The player has two ways of sending messages:

• classical

  Example 11. Where was Oumph?

  tell Oumph "Where have you been?"

  This will generate this message ("", "Where have you been?"). It could not be understood by a non-player; however every creature is able to report the words that she hears (spy, gossip, etc).

• with aliases

  Example 12. Oumph's job

  This will generate this message ("Job", "What's your job?") which can be understood by bots and players.

  An alias list will have to be implemented in the controller. The player will of course be able to modify them in his own way.

  If the alias does not exist, 'tell Oumph cloporte' will generate the message ("cloporte", "cloporte").

Control codes

In order that the bots could understand one another better, we add return codes NONE, ANS, WRONG_ANS and BAD_ANS. These codes are not readable by players and cannot be used directly by players either (the 'answer' commands will allow to send a message with the control code ANS). So the codes using is reserved to bots.

NONE is the default control code. It does not mean anything. It is employed when no other control code is used.

The code ANS means that the message is an answer to a previous question.

WRONG_ANS is used to point out that the answer is regarded as wrong and deceitful. The interlocutor can therefore give another chance to say the truth (or rather what the bot considers as the truth), change topic of conversation or break the discussion with troublesome consequences (fight, reputation drop...).

It is advisable to limit the number of possible tries... BAD_ANS marks that the answer is incorrect, inconsistent with the answer type which was expected.

A BAD_ANS code generated by a bot is a serious error in the game code or in the bot code. An error log must be made for debugging and correction.

A BAD_ANS code generated by a player means a typo, a bad understanding of the question, a voluntary lie, a try at disturbing the bot, etc.

The coder is free to make its bot react as she thinks best (polite and understanding, nervous and aggressive, etc). So the bot can repeat its question or not.

the bot cannot and should not know whether it speaks to another bot or to a player. This is the reason why the number of BAD_ANS answers must be limited, in order to prevent buggy bots to induce infinite loops...

Expression modifiers

An Expression Modifier is a context information going with the message. This information is relevant for the bot receiving the message and help him decide how to react.

For example, there are several ways to ask somebody its name:

• polite: "Would you mind to tell me your name, please?"

• neutral: "What is your name?"

• insulting: "What is your name, alien scum?"

Each time, only the expression modifier changed. Below are the same messages understood by bots:

• polite: (name, NONE, POLITE)

• neutral: (name, NONE, NEUTRAL)

• insulting: (name, NONE, INSULTING)

POLITE, NEUTRAL and INSULTING are Expression Modifiers. Here is a list of expression MODIFIERS:

• OBSEQUIOUS

• POLITE

• NEUTRAL

• RUDE

• THREATENING

• INSULTING

• CHARMING

This list is not closed.

The following example explains how Expression Modifiers could be used. Janselmeer meets Robert the butcher (Raoul's brother) and asks him about Raoul the baker.

There is no obligation using an Expression Modifier whether another. It is a pure matter of roleplay. Some people are used to be rude and some others are used to be polite only because it is their way. But of course creatures may not have the same reaction with the first than with the second. It depends on them. For example, a lord is normally used to be talked obsequiously and may be offended by someone that would act differently. So the choice of an expression modifier depends on both the personality of the character that is speaking and the expected reaction of the character that is listening.

Future extensions of bots language

The keywords system has been chosen on grounds of simplicity of implementation. Nevertheless, this should evolve and lead towards a true dialog with complete sentences (subject, verb, complement).

The first extension to keywords could be the use of interrogative pronouns and adverbs: what, who, where, why, how, how many, which, when.