%ents; ]>
Instant Gaming This document defines an XMPP protocol extension for serverless instant gaming in a one-to-one context. xxxx ProtoXEP Standards Track Standards Council XMPP Core XMPP IM XEP-0004 XEP-0030 XEP-0045 NOT YET ASSIGNED Torsten Grote Torsten.Grote(ät)fsfe.org Torsten.Grote(ät)jabber.fsfe.org Arne König arne.ko(ät)23inch.de arne++(ät)jabber.ccc.de 0.0.1 2009-03-14 tg

First draft.

&LEGALNOTICE;

Many modern instant messenger networks support playing games. Still, XMPP mostly lacks this kind of support. Therefore, this document describes a base protocol for game playing over XMPP.

This protocol is not by itself sufficient to play games. It just describes a basic protocol framework which game-specific protocols can use.

This document addresses the functionality which is needed to play games over the XMPP. In particular this functionality consists of:

  1. discovering support for games in general and for particular games
  2. inviting users to matches
  3. exchanging match information (moves, states, etc.)
  4. saving and loading of matches
  5. terminating matches

The following section describes the use cases associated with one-to-one instant gaming. It is not supposed to provide professional gaming capabilites with independent move validation, spectators, etc. Instead, it only supports two player games without spectators and no move validation.

Despite the existence of Multi-User Gaming, Instant Gaming is considered important for making gaming over XMPP popular. Rapid deployment of new two-player games is possible without waiting for server support or finding a suitable server.

An implementation of Instant Gaming MUST support &xep0030;.

A Jabber entity may wish to discover if another entity implements the Instant Gaming protocol; in order to do so, it sends a service discovery information ("disco#info") query to the other entity's full JID:

]]>

The entity MUST return the features it supports. Game protocols SHOULD include a &FEATURE; element with their namespace in the response, too.

... ... ]]>

In order to invite someone to a game, the initiator sends a message to her/his opponent containing an &INVITE; element, which MUST specify the invitation type (see Table 1).

Furthermore, a &GAME; element with a "var" attribute containing the namespace of the game protocol is REQUIRED. It MAY also contain additional information which SHOULD then be specified using &xep0004;. Such information might be used to state the rules or other slight variations for the particular game. If an invitation with unsupported rules or options is received, a ¬acceptable; error of type "modify" SHOULD be send to the inviting entity.

The &THREAD; element MUST be present and it MUST contain a unique ID which identifies the current match. The ID MAY for example consist of the initiator's and the opponent's (bare) JID, the game name, the current datetime (which then SHOULD conform to the DateTime profile specified in &xep0082;) and a random number, all separated by hyphens. It is not supposed to get parsed and is only used to uniquely identify the game.

romeo@montague.net-juliet@capulet.com-checkers-1591-02-21T12:56:15Z-1234 Hello Juliet, would you like to play a little game? ]]>
Invitation Type Meaning
new The game is totally new and contains no data of previous games.
renew The game is over and shall be recreated from the beginning with the same match ID.
adjourned This invitation is to resume an adjourned game. It MUST only be send to the same opponent as from the beginning of the game and MUST contain the same game id. Further information provides Game Loading
constructed This type states that the game will start with a state which is different from the state new games have.

An invitation of type "renew" SHOULD contain the same match ID and &GAME; element as the initial "new" invitation. It MUST only be send when the previous match with the same match ID has been terminated. If it is received earlier, an &unexpected; error SOULD be send to the sender of the premature invitation. Game protocols SHOULD switch the beginning player and leave all other options the same.

In the unlikely but possible event that an invitation of type "renew" is received immediately after one has been send with the same match ID, this invitation SHOULD be treated as if it were a &MESSAGE; with a &JOIN; element. Invitations with match IDs that are already assigned to a running game SHOULD be ignored.

The opponent SHOULD NOT ignore the invitation. If she/he does not want to play, the invitation SHOULD be declined. In order to decline the invitation, the opponent MUST send a message of the following form to the initiator.

romeo@montague.net-juliet@capulet.com-checkers-1591-02-21T12:56:15Z-1234 I won't fight you. ]]>

In order to join a game, a &MESSAGE; stanza has to be send to the initiator's full JID. The &MESSAGE; stanza MUST contain the ID of the match to which the opponent wants to join in the &THREAD; element. Besides that, a &JOIN; element qualified by the namespace 'http://jabber.org/protocol/games' is REQUIRED and the &BODY; element is OPTIONAL.

romeo@montague.net-juliet@capulet.com-checkers-1591-02-21T12:56:15Z-1234 ]]>

A successful join MUST be confirmed by sending the same message (with different sender and recipient) back to the opponent.

The initiator might refuse the join by sending a &MESSAGE; stanza of 'type' "error". It then MUST mirror the &THREAD; ID and the original &JOIN; child element. The &ERROR; element MAY contain a &TEXT; element with a human-readable description of the error.

romeo@montague.net-juliet@capulet.com-checkers-1591-02-21T12:56:15Z-1234 You are not welcome here! ]]>

A turn in a game is sent in a message (of type "chat") to the other player's full JID. The &MESSAGE; stanza contains a &TURN; element which contains the element, representing the desired action (e.g. &MOVE;) qualified by the namespace of the particular game. The action itself can be further described by attributes or child elements (see corresponding game protocol).

A human-readable comment MAY be sent with the move in the &BODY; element of the &MESSAGE;. In order to track the game to which the move belongs, the match ID is REQUIRED to be in the &THREAD; element.

juliet@capulet.com-romeo@montague.net-tictactoe-1591-02-23T11:36:25Z-4321 What do you say to this? ]]>

A receipt for each message MAY be requested in accordance with &xep0184;.

While playing a game, it might be desirable to interrupt playing and resume it at a later time. Games with complete knowledge can be saved at any time by each of the players without sending messages. But the client of the saving player SHOULD inform the other player that the game was saved by sending the following message.

to='juliet@capulet.com/balcony' juliet@capulet.com-romeo@montague.net-tictactoe-1591-02-23T11:36:25Z-4321 ]]>

After receiving such an notification, an implementation MAY decide to save the game, too.

When playing games with incomplete knowledge, it is desirable that both players save the game at the same time in order to save a clean game state. The game protocol MUST define whether its game has to be saved independently or mutually.

If a game needs to be saved mutually by both players, one of the players requests the game to be saved by sending a message with a &SAVE; child element as follows.

juliet@capulet.com-romeo@montague.net-tictactoe-1591-02-23T11:36:25Z-4321 ]]>

The recipient of the above message MUST confirm a successful saving process using a &SAVED; element as above.

To ensure that both players save the same game state, the sender MUST NOT send any game moves until he receives confirmation from the other player and the receiver MUST NOT send any game moves after receiving the request for saving until he has responded to it.

If the sender of the saving request receives a game move before getting confirmation of a successful saving process, she/he MUST NOT save the game and MUST send the following error message.

juliet@capulet.com-romeo@montague.net-tictactoe-1591-02-23T11:36:25Z-4321 ]]>

If one of the player's client encounters an error during the saving process, it MUST send an error message, too. This time it SHOULD NOT use a &conflict;, but an &undefined; error condition.

An XMPP entity that wishes to resume a saved game has to send an invitation of "type" 'adjourned' to the same opponent it began playing with. It MAY also resume the game with another opponent, but then it MUST use the "type" 'constructed' and a new match ID.

In case the game requires mutual saving by both players and the game was saved this way, one of the players simply sends an invitation of "type" 'adjourned' with the match ID of the saved game to the other player. After the invitee has successfully joined the game, it begins at the point where it was saved.

If the game was only saved by one of the players, the inviting player MUST send the saved game state in the invitation. This SHOULD be done by including an &X; element in the &MESSAGE; stanza of the 'jabber:x:data' namespace. The exact representation of the game state is up to the game protocol, but SHOULD use &xep0004;. E.g. the state MAY also be encoded in a history of game moves.

romeo@montague.net-juliet@capulet.com-tictactoe-1591-02-21T12:56:15Z-1234 Hello Juliet, would you like to resume our little game? Game of Tic Tac Toe saved on 21st of February 1591 at 1 o'clock juliet@capulet.com/balcony romeo@montague.net/garden 5 o o x x ]]>

The Tic Tac Toe game state information in this example is entirely fictional and only for demonstration purposes.

An implementation MAY present the game in the saved state to the user along with the invitation. It MAY also compare the state it received with the state it saved by its own and inform the user about any mismatches.

An implementation SHOULD send the following &MESSAGE; to end the game. The "reason" attribute is always REQUIRED.

juliet@capulet.com-romeo@montague.net-checkers-1591-02-23T11:36:25Z-4321 What devil art thou, that dost torment me thus? ]]>

This &MESSAGE; SHOULD also be send by one of the players before she/he changes her/his presence to unavailable, though a different "reason" MAY be used. For a list of possible reasons and their meaning see Table 2.

In case one player changes her/his presence to unavailable without sending a termination message, the other player might just wait or MAY save the game (if possible) and send a termination message with reason 'adjourn'.

A terminating &MESSAGE; with reason 'cheating' SHOULD be send, if an illegal move is received. If one entity receives a terminating &MESSAGE; although it already send one by it's own, it MUST ignore it.

Reason Meaning
won The player sending the message has won the game.
lost The player sending the message has lost the game.
draw The game is over and nobody has won.
resign The player sending the message capitulates and quits.
adjourn The game is not over and might be resumed at a later time.
cheating The player receiving the message has submitted an illegel game move.

Initiator -- an entity who started a game.

Opponent -- in an One-to-One gaming context, the entity who was invited to play and did not start the game.

Spectator -- an entity who does not actually plays the game but watches it.

OPTIONAL.

OPTIONAL.

OPTIONAL.

REQUIRED.

REQUIRED.

REQUIRED.

]]>