ProtoXEP: Game Support

Hello everyone,

although there were some proposals [1] and even some
implementations
[2], there is still no official and standardized way to play
games over
XMPP.
In my opinion this is one big hindrance for a large-scale
adoption of
Jabber. A fast growing pool of interoperable and fascinating
games would
drive many users to create and use Jabber accounts.

In order to solve this problem, I want to propose a XEP for
Game
Support. I intentionally left the Multi-User Gaming (MUG)
part out for
now, because it is the most complicated and controversial
one. It would
be best to make one step after the other.
The other reason why I left out MUG is because a colleague
and me are
already developing a game plugin for Pidgin based on this
ProtoXEP and
we concentrate on One-to-One gaming, since MUG will need
server support.
We do have a concrete plan for MUG, but do not want to drift
the
discussion away from One-to-One gaming which now has top
priority.

You can find the XEP to provide Game Support and a simple
XEP defining
Tic Tac Toe at these locations:
http://www.cs.uni-potsdam.de/~tgrote/xep/game-support.
html
http://www.cs.uni-potsdam.de/~tgrote/xep/tictactoe.html

Since I know that there are at least some people on this
list who would
also like to see standardized Jabber gaming becoming a
reality, the
purpose of this email is not only to get a discussion about
One-to-One
gaming going, but also to get help in improving the XEP and
in writing
the missing part about MUG. Everybody interested in
participating is
most welcome.
If you do have something to criticize about One-to-One
gaming, it would
be best, if you explain your critique *and* provide a
reformulation of
the concerning paragraphs and/or examples.

Thank you and Kind Regards,
Torsten Grote

-- 
[1] http://www.xmpp.org/extensions/inbox/gamesessions.html

    http:
//www.xmpp.org/extensions/inbox/chess.html
[2] http://tkabb
er.jabber.ru/tkabber-plugins
    http://dev.hyperstruct.net/xmpp4moz/wiki/Rem
oteApplicationChessboard

Hello

On Sat, Jan 12, 2008 at 12:21:43AM +0100, Torsten Grote
wrote:
> we concentrate on One-to-One gaming, since MUG will
need server support.

Is it really needed? A gaming support on server? Couldn't
this be done
trough ordinary MUC?

> http://www.cs.uni-potsdam.de/~tgrote/xep/game-support.
html

Just few notes here, may or may not be useful.

Discovering:
Wouldn't it make sense use service disco to get
supported/ongoing games
too? (add items supported-games and ongoing-games to item
list, and their
sub-lists as games, for example)

It seems to me defining new protocol for discovering is not
needed, if
there is a generic one.

Invitation:
What is the difference between body and reason? I would put
the reason
to body of the message directly, as is with MUC invitations,
and so on.

Besides, wouldn't it be better in <iq>, as it requires
response (either
positive or negative)?


I like the idea of using ordinary thread in messages as the
game
identifier, allows more concurrent games.

Saving:
she/he MUST not save the game and send the following

she/he MUST NOT save the game and MUST send?

Besides, shouldn't game saving/loading be optional in a way
some clients
can do it and some don't? (Therefore a discoverable feature
for that
given game). And, it should be noted each game needs a
description of
it's own, how it is saved, right?

Loading:
Is it a good idea send the whole state in the invitation? It
might be
long (depending on the game) and if the other side declines,
it is
wasted bandwidth.

Terminating:
It should be specified, what exactly happens, when the other
side just
changes to unavailable (lost connection, probably).

> http://www.cs.uni-potsdam.de/~tgrote/xep/tictactoe.html

Could it allow playing on any-sized plan (possibly infinite
too) and
have the length of winning strike & starting player
negotiated?

Besides, it probably should be noted, how the game is
saved.

Have a nice day

-- 
Please enter password:

Michal 'vorner' Vaner

LE SAMEDI 12 JANVIER 2008, MICHAL 'VORNER' VANER A éCRIT :
> HELLO
>
> ON SAT, JAN 12, 2008 AT 12:21:43AM +0100, TORSTEN GROTE
WROTE:
> > WE CONCENTRATE ON ONE-TO-ONE GAMING, SINCE MUG
WILL NEED SERVER SUPPORT.
>
> IS IT REALLY NEEDED? A GAMING SUPPORT ON SERVER?
COULDN'T THIS BE DONE
> TROUGH ORDINARY MUC?
>
> >
HTTP://WWW.CS.UNI-POTSDAM.DE/~TGROTE/XEP/GAME-SUPPORT.HTML
>
> JUST FEW NOTES HERE, MAY OR MAY NOT BE USEFUL.
>
> DISCOVERING:
> WOULDN'T IT MAKE SENSE USE SERVICE DISCO TO GET
SUPPORTED/ONGOING GAMES
> TOO? (ADD ITEMS SUPPORTED-GAMES AND ONGOING-GAMES TO
ITEM LIST, AND THEIR
> SUB-LISTS AS GAMES, FOR EXAMPLE)
>
> IT SEEMS TO ME DEFINING NEW PROTOCOL FOR DISCOVERING IS
NOT NEEDED, IF
> THERE IS A GENERIC ONE.

I AGREE THAT THE DISCOVERING SHOULD SIMPLY BE DONE BY ADDING
GNAME NAMESPACES 
TO THE FEATURE LIST OF THE DISCO :

ARGUMENTS:

- IT WOULD BENEFIT OF THE XEP-0115 (CAPS)
- GAMES ANYWAY REQUIRE SPECIFIC SUPPORT IN THE CLIENT, SO
THE CLIENT PROBABLY 
ALREADY KNOW THE NAME OF THE GAME IT IT SUPPORT IT.

LONG TIME AGO I ALSO THOUGHT ABOUT A WAY OF RUNNING EXTERNAL
APPLICATION FROM 
THE MESSAGING CLIENT. (LET'S SUPPOSE THE TIC-TAC-TOE GAME IS
A STAND ALONE, 
XMPP-ENABLED APPLICATION) 
HTTP://KOPETE.KDE.ORG/PROTOCOL/INVITATION.HTML
AND THE FACT THAT NAMESPACES ARE IN THE #DISCO WOULD HELP
SUCH PROTOCOL, MOST 
PROBABLY.

-- 
OLIVIER

Hello

On Sat, Jan 12, 2008 at 01:36:15PM +0100, Olivier Goffart
wrote:
> I agree that the discovering should simply be done by
adding gname namespaces 
> to the feature list of the disco :

You mean directly in features? But then all the clients who
do not know
games will get long list of all games the fancy game client
supports, I
would like to see some cascading. Is disco able to request
features of
some sub-item?

-- 
~, sweet ~

Michal 'vorner' Vaner

LE SAMEDI 12 JANVIER 2008, MICHAL 'VORNER' VANER A éCRIT :
> HELLO
>
> ON SAT, JAN 12, 2008 AT 01:36:15PM +0100, OLIVIER
GOFFART WROTE:
> > I AGREE THAT THE DISCOVERING SHOULD SIMPLY BE DONE
BY ADDING GNAME
> > NAMESPACES TO THE FEATURE LIST OF THE DISCO :
>
> YOU MEAN DIRECTLY IN FEATURES?

YES

> BUT THEN ALL THE CLIENTS WHO DO NOT KNOW 
> GAMES WILL GET LONG LIST OF ALL GAMES THE FANCY GAME
CLIENT SUPPORTS, 

YES, BUT THIS IS THE SAME WITH EVERY FEATURES, LIKE ALL THE
JINGLE NAMESPACE 
IF I DON'T SUPPORT JINGLE, ....

AND DOES IT HURT ?
THE ONLY NEGATIVE EFFECT I SEE IS THE BRANDWITH, AND THOSES
NAMESPACE SHOULD 
COMPRESS PRETTY WELL. THERE IS ALSO THE XEP-0115 TO HELP
US.

> I WOULD LIKE TO SEE SOME CASCADING. IS DISCO ABLE TO
REQUEST FEATURES OF
> SOME SUB-ITEM?

THERE IS THE NODE='' ARGUMENT THAT COULD MAYBE BE USED FOR
THAT. BUT IS IT 
WORTH IT ?  HOW WOULD THIS WORK WITH XEP-0115 ?

Hello

On Sat, Jan 12, 2008 at 02:31:52PM +0100, Olivier Goffart
wrote:
> Le samedi 12 janvier 2008, Michal 'vorner' Vaner a
écrit :
> > But then all the clients who do not know 
> > games will get long list of all games the fancy
game client supports, 
> 
> Yes, but this is the same with every features, like all
the jingle namespace 
> if I don't support jingle, ....
> 
> And does it hurt ?
> The only negative effect I see is the brandwith, and
thoses namespace should 
> compress pretty well. There is also the XEP-0115 to
help us.

You are right, this was just my first sight that told me it
will be
bigger. But maybe it is not worth it.

But, anyway, I think it makes sense use disco in some way to
discover
the supported games.

-- 
"Don't worry about people stealing your ideas.	 If your
ideas are any good, 
you'll have to ram them down people's throats."
	-- Howard Aiken

Michal 'vorner' Vaner

On Sat, 12 Jan 2008, Michal 'vorner' Vaner wrote:

> On Sat, Jan 12, 2008 at 12:21:43AM +0100, Torsten Grote
wrote:
>> we concentrate on One-to-One gaming, since MUG will
need server support.
>
> Is it really needed? A gaming support on server?
Couldn't this be done
> trough ordinary MUC?

We did it with ordinary MUC, with RPC messages for game
moves and disco 
for game discovery. No server support necessary.

--Z

-- 
"And Aholibamah bare Jeush, and Jaalam, and Korah:
these were the borogoves..."
*
Making a saint out of Reagan is sad. Making an idol out of
Nixon ("If the
President does it then it's legal") is contemptible.

Michal 'vorner' Vaner said the following on 01/12/2008 11:13
AM:
> Just few notes here, may or may not be useful.

Thank you very much for your comments!

> Is it really needed? A gaming support on server?
Couldn't this be done
> trough ordinary MUC?

We plan to use MUC extensively for MUG, of course. But
please let's
concentrate on One-to-One gaming for now.

> Discovering:
> Wouldn't it make sense use service disco to get
supported/ongoing games
> too? (add items supported-games and ongoing-games to
item list, and their
> sub-lists as games, for example)
> 
> It seems to me defining new protocol for discovering is
not needed, if
> there is a generic one.

I used a separate mechanism for discovering individual games
because
there may be hundreds of games a client supports and this
would blow up
a disco response considerably.
But compression or XEP-0115 might solve this problem. So, if
there are
no further concerns, I'll add the games disco to normal
disco requests.

> Invitation:
> What is the difference between body and reason? I would
put the reason
> to body of the message directly, as is with MUC
invitations, and so on.

MUC invitations use no <body/>, but a <reason/>
element. I agree that
one of them is enough. Maybe we should use reason in order
to be similar
to MUC. What do you (and the others) think?

> Besides, wouldn't it be better in <iq>, as it
requires response (either
> positive or negative)?

Well, MUC uses a <message/>, too and as far as I
understood <iq/>
stanzas, they always carry some kind of payload (get/set
data) and are
thought to be a request to another client, not its user,
which would be
better represented by a message.

> Saving:
> she/he MUST not save the game and send the following
> 
> she/he MUST NOT save the game and MUST send?

changed. Thank you!

> Besides, shouldn't game saving/loading be optional in a
way some clients
> can do it and some don't? (Therefore a discoverable
feature for that
> given game).

I thought about this, too and came to the conclusion that
saving is not
such a big think to implement and that it would only make
the protocol
more complicated.

> And, it should be noted each game needs a description
of
> it's own, how it is saved, right?

Could you please elaborate a little bit more on this?

> Loading:
> Is it a good idea send the whole state in the
invitation? It might be
> long (depending on the game) and if the other side
declines, it is
> wasted bandwidth.

Sending the state in the invitation has the big advantage
that the
invitee can see how the game looks like and decide on better
grounds
whether he wants to join. This is especially helpful with
"constructed"
games.

> Terminating:
> It should be specified, what exactly happens, when the
other side just
> changes to unavailable (lost connection, probably).

What happens when the other side changes to unavailable is
defined, but
not in terms of connection losses. They are a problem and
I'm not sure
how to handle these.
If the game was not canceled, the client should be able to
reconnect and
play. If the client crashes, this is not possible, but the
other player
could save the game it is of the complete knowledge kind.

>> http://www.cs.uni-potsdam.de/~tgrote/xep/tictactoe.html
> 
> Could it allow playing on any-sized plan (possibly
infinite too) and
> have the length of winning strike & starting player
negotiated?

Well it could, but it doesn't ;)
But it there are several variants of Tic Tac Toe which could
be added as
tictactoe#variant in the future.

> Besides, it probably should be noted, how the game is
saved.

Saving is not yet supported by this XEP. I don't think that
saving a
game of Tic Tac Toe is really necessary and it could be
explicitly
stated that it is not supported.

> Have a nice day

Regards and Thanks again,
Torsten

Hello

On Sat, Jan 12, 2008 at 05:34:21PM +0100, Torsten Grote
wrote:
> Michal 'vorner' Vaner said the following on 01/12/2008
11:13 AM:
> > And, it should be noted each game needs a
description of
> > it's own, how it is saved, right?
> 
> Could you please elaborate a little bit more on this?

I was somehow mistaken by the missing saving in tictactoe.
The saved
game looked like it is "from nowhere".

> > Terminating:
> > It should be specified, what exactly happens, when
the other side just
> > changes to unavailable (lost connection,
probably).
> 
> What happens when the other side changes to unavailable
is defined, but
> not in terms of connection losses. They are a problem
and I'm not sure
> how to handle these.
> If the game was not canceled, the client should be able
to reconnect and
> play. If the client crashes, this is not possible, but
the other player
> could save the game it is of the complete knowledge
kind.

Hm, did I read it too fast and missed it somewhere, or is
there only the
think that a client should terminate the game before
disconnection?

> >> http://www.cs.uni-potsdam.de/~tgrote/xep/tictactoe.html
> > 
> > Could it allow playing on any-sized plan (possibly
infinite too) and
> > have the length of winning strike & starting
player negotiated?
> 
> Well it could, but it doesn't ;)
> But it there are several variants of Tic Tac Toe which
could be added as
> tictactoe#variant in the future.

Well, the "variants" differ (if I omit the things
like 3D, more than 2
players) only in the sizes and I guess a client does not
much differ for
them. I would rather like to see the numbers negotiated than
have
variants like:
20x20-5
40x40-5
and so on.

(I get this is the first version, but I think a XEP for
3x3-3 variant
and another XEP for other variants is somehow a waste, so it
would be
nice to have it possible in future in the protocol. Not that
every
client would have to understand all the variants.)

> > Besides, it probably should be noted, how the game
is saved.
> 
> Saving is not yet supported by this XEP. I don't think
that saving a
> game of Tic Tac Toe is really necessary and it could be
explicitly
> stated that it is not supported.

Could be a nice example, thought. And you do not need to
define much
:

<tictactoe>
X_O
OOX
___
</tictactoe>

(Again, I know, it's first version.)

Have a nice day

-- 
This side up =>

Michal 'vorner' Vaner

Hello

On Sat, Jan 12, 2008 at 04:47:06PM +0000, Richard Dobson
wrote:
> That will only work if you trust each party to follow
the same set of rules 
> governing the game and not to make invalid moves/cheat,
it is far better to 
> have a third party (i.e. a gaming server, or maybe one
of the participants) 
> receiving all the moves and verifying them before
distributing them to all 
> the players, also a lot of games (for example
battleships, scrabble, most 
> card based games, i.e. poker, uno) work by neither
player knowing the full 
> game state with the full state only known by a neutral
third party.

You can do all this with a bot moderator and players only
visitors and
let them PM the gamebot.

But then, you can not send normal talking messages.

Or, a move would be valid only after approving message by
the bot (and
all other moves would be considered invalid up to that
time).

Or a bot could kick for cheating, which is somehow similar
what happens
with a game without a computer.

The only thing that I see as a problem is how to discover
the game
rooms, unless you have the support.

-- 
I still miss Windows, but my aim is getting better.

Michal 'vorner' Vaner

Hello

On Sat, Jan 12, 2008 at 05:05:31PM +0000, Richard Dobson
wrote:
>> You can do all this with a bot moderator and
players only visitors and
>> let them PM the gamebot.
>> But then, you can not send normal talking
messages.
>> Or, a move would be valid only after approving
message by the bot (and
>> all other moves would be considered invalid up to
that time).
>> Or a bot could kick for cheating, which is somehow
similar what happens
>> with a game without a computer.
>> The only thing that I see as a problem is how to
discover the game
>> rooms, unless you have the support.
>
> Sure exactly, as I said you need some kind of neutral
third party for a lot 
> of games, be that a server or a bot it doesnt matter,
but you cant do as 
> the previous poster seemed to suggest (as far as I read
it) and just use 
> bog standard MUC and RPC between the players for all
games.

But you do not need to change MUC, it is much easier done
with letting
MUC be the same and just add something, then redefining the
protocol and
duplicating the work.

You can use standard MUC and RPC, you just need another
"player" who
plays the "doom" of the game. Be it a bot or a
real player. Like in any
other real game, the only thing you need to add is the
figures and
moving with them.

-- 
The problem with graduate students, in general, is that they
have
to sleep every few days.

Michal 'vorner' Vaner

Hello

On Sat, Jan 12, 2008 at 07:16:19PM +0100, Torsten Grote
wrote:
> Michal 'vorner' Vaner said the following on 01/12/2008
05:53 PM:
> > I would rather like to see the numbers negotiated
than have
> > variants like:
> > 20x20-5
> > 40x40-5
> > and so on.
> 
> Feel free to send me your proposal for a section which
defines this.

Well, you can put something like
<rules xmlns='http://jabb
er.org/protocol/games/checkers'>
  <width>20</width>
  <height>20</height>
  <strike>5</strike>
  <at-turn>X</at-turn>
  <me>O</me>
</rules>

into the invitation. No need for other section, right?

> > Could be a nice example, thought. And you do not
need to define much
> > :
> > 
> > <tictactoe>
> > X_O
> > OOX
> > ___
> > </tictactoe>
> > 
> > (Again, I know, it's first version.)
> 
> Well the XEP Game Support has a fictive example for
saving Tic Tac Toe
> using Data Forms. Your way is much shorter, but is
useless for being an
> example on how to save game states in general. I'm not
an expert on this
> and don't know what's the best way. Suggestions by long
time XMPP
> experts are welcome.

Well, you need some defined mechanism for every separate
game anyway.
And what is in your namespace (the game's namespace) is your
own thing,
that's what namespaces are for.

You can not get a general way to save a game. And you need
to define a
game's moves in it's own namespace anyway, so I see no
reason why to
worry about data forms, which are for adding means of
transfering data
without defining a separate protocol for every usecase. But
you need to
define the fields at last.

-- 
_(){ _&_;};_

Michal 'vorner' Vaner

Some notes to slightly enhance the protocol, rather than
doing the 
following:

<message
     from='romeomontague.net/garden'
     to='julietcapulet.com/balcony'>
 
<thread>romeomontague.net-julietcapulet.com-checkers-1591-02-21T12:56:15Z-1234</th
read>
   <body>You have been invited to a game of Checkers
by 
romeomontague.net.</body>
   <x xmlns='http://jabber.org/pr
otocol/games'>
     <invite
         transport='one-to-one'
         type='new'>
       <reason>
         Hello Juliet,
         would you like to play a little game?
       </reason>
     </invite>
     <game var='http://jabb
er.org/protocol/games/checkers'/>
   </x>
</message>

I would simplify it as the following:

<message
     from='romeomontague.net/garden'
     to='julietcapulet.com/balcony'>
 
<thread>romeomontague.net-julietcapulet.com-checkers-1591-02-21T12:56:15Z-1234</th
read>
   <body>You have been invited to a game of Checkers
by 
romeomontague.net.</body>
   <invite xmlns='http://jabber.org/pr
otocol/games'
     transport='one-to-one' type='new'>
     <reason>
       Hello Juliet,
       would you like to play a little game?
     </reason>
     <game var='http://jabb
er.org/protocol/games/checkers'/>
   </invite>
</message>

There is no need for the top level x element, that is only a
historical 
remnant that a few specs use, also regarding the invite it
makes more 
sense for the game element to be inside the invite rather
than outside 
it, I would also update all the other actions too so they
dont use the x 
element either.

Also I would adjust the move action from:

<message
     from='julietcapulet.com/balcony'
     to='romeomontague.net/garden'
     type='chat'>
 
<thread>julietcapulet.com-romeomontague.net-checkers-1591-02-23T11:36:25Z-4321</t
hread>
   <body>What do you say to this?</body>
   <x xmlns='http://jabber.org/pr
otocol/games'>
     <move xmlns='http://jab
ber.org/protocol/games/tictactoe'
         id='1'
         row='2'
         col='2'/>
   </x>
</message>

To be slightly more generic into a turn action that
encapsulates the 
move i.e.:

<message
     from='julietcapulet.com/balcony'
     to='romeomontague.net/garden'
     type='chat'>
 
<thread>julietcapulet.com-romeomontague.net-checkers-1591-02-23T11:36:25Z-4321</t
hread>
   <body>What do you say to this?</body>
   <turn xmlns='http://jabber.org/pr
otocol/games'>
     <move xmlns='http://jab
ber.org/protocol/games/tictactoe'
         id='1'
         row='2'
         col='2'/>
   </turn>
</message>

Hope this helps.

Richard

Richard Dobson said the following on 01/12/2008 08:40 PM:
> Some notes to slightly enhance the protocol
> ...
> There is no need for the top level x element, that is
only a historical
> remnant that a few specs use, also regarding the invite
it makes more
> sense for the game element to be inside the invite
rather than outside
> it, I would also update all the other actions too so
they dont use the x
> element either.

Thank you very much for your help! I adapted the ProtoXEP
draft accordingly.

> Also I would adjust the move action from:
> ...
> To be slightly more generic into a turn action that
encapsulates the
> move i.e.:
> ...
> Hope this helps.

Good idea! 
I changed this also.

Do you have any opinion on the disco for individual games?
I see basically three ways to do it:

1. include games in normal disco as feature
2. use info/item nodes in normal disco
3. some "own" third way, as we did

Number 1 could blow up the disco response considerably,
while Number 2
and 3 allow for a separate query for games. Unfortunately, I
can't come
up with a nice way to do Number 2.
Our current solution is very similar to a disco#items query
(e.g. MUC
room query). Are there any good reasons not to do it that
way?

> Richard

Torsten

> Do you have any opinion on the disco for individual
games?
> I see basically three ways to do it:
>
> 1. include games in normal disco as feature
> 2. use info/item nodes in normal disco
> 3. some "own" third way, as we did
>
> Number 1 could blow up the disco response considerably,
while Number 2
> and 3 allow for a separate query for games.
Unfortunately, I can't come
> up with a nice way to do Number 2.
> Our current solution is very similar to a disco#items
query (e.g. MUC
> room query). Are there any good reasons not to do it
that way?
>   

I would do it as option 2, where the main disco info would
just have a 
feature of "http://jabber.
org/protocol/games", then if people want to 
retrieve a full list of the games you support they would do
a disco#info 
query on the special node for games (http://jabber.org/pr
otocol/games), e.g.

<iq from='romeomontague.net/garden' to='julietcapulet.com/balcony' 
id='req1' type='get'>
    <query xmlns='http://jabber.o
rg/protocol/disco#info' 
node='http://jabber.org/pr
otocol/games'/>
</iq>

<iq from='julietcapulet.com/garden' to='romeomontague.net/balcony' 
id='req1' type='result'>
    <query xmlns='http://jabber.o
rg/protocol/disco#info' 
node='http://jabber.org/pr
otocol/games'>
        <feature var='http://jab
ber.org/protocol/games/tictactoe'/>
        <feature var='http://jabber.
org/protocol/games/chess'/>
    </query>
</iq>

This allows easy use of disco without bloating the main
response.

Richard

On Sat, 12 Jan 2008, Richard Dobson wrote:

> Sure exactly, as I said you need some kind of neutral
third party for a lot 
> of games, be that a server or a bot it doesnt matter,
but you cant do as the 
> previous poster seemed to suggest (as far as I read it)
and just use bog 
> standard MUC and RPC between the players for all
games.

Just to be clear, I *did* mean that we have a referee bot in
the MUC. (The 
bot is the entity that sets up the MUC, in fact, although it
currently 
doesn't use any MUC administrator functions beyond that.)

I also want to address this bit from an earlier post:

Torsten Grote <Torsten.Grotegmx.de>:

> In my opinion this is one big hindrance for a
large-scale adoption of
> Jabber. A fast growing pool of interoperable and
fascinating games would
> drive many users to create and use Jabber accounts.

What we've found is that there's no need to drive people
towards Jabber 
accounts -- you say "use your Livejournal or Google
Chat address" and 
everyone's there. Or you tell them to register on a web site
(people do 
that six times a day anyway) and then provision them a
Jabber account. 
("Plays games, plus you can chat with it!")

The sticky point is getting people to download software. We
find, in this 
day and age, that people won't play a game unless it runs in
software they 
already have. That's a big obstacle for Jabber gaming: you
want that to 
be a *fast-growing* pool of games, but nobody is going to
download a new 
client update every week because another game came out.

Our solution was to have a custom client which could
download individual 
game plugins itself. (In the form of Javascript code.) That
worked great, 
but then nobody downloaded the custom client in the first
place.

The current plan is to grit our teeth and make it a web app.
Yes, it's a 
cliche, but people have web browsers and they expect
everything to run in 
them. We're still using Jabber on the back end, so they will
still get 
chat and federation with all the other Jabber users of the
world.

We realize that "Jabber on the back end" doesn't
do much for XMPP 
advocacy, but it's better than nothing, and our primary goal
is to get 
people playing games. Whatever that takes.

The only flaw with the current plan is that it's a lot of
work and it's 
not done yet. :/

--Z

-- 
"And Aholibamah bare Jeush, and Jaalam, and Korah:
these were the borogoves..."
*
When Bush says "Stay the course," what he means is
"I don't know what to
do next." He's been saying this for years now.

Torsten Grote wrote:

> In my opinion this is one big hindrance for a
large-scale adoption of
> Jabber. 

We estimate that there are 50+ million end users of Jabber
technologies. 
But I guess that's not large-scale compared to MSN, eh?

> A fast growing pool of interoperable and fascinating
games would
> drive many users to create and use Jabber accounts.

Yes that might be fun. 

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Torsten Grote wrote:

> Do you have any opinion on the disco for individual
games?

How many games do you expect clients to support?

> I see basically three ways to do it:
> 
> 1. include games in normal disco as feature

That seems OK. The nice thing is that if a user installs the
checkers 
plugin (or whatever), it can send an entity capabilities
update.

> 2. use info/item nodes in normal disco

That might be appropriate. It depends on what we think a
game is (is it 
a feature or an item?).

> 3. some "own" third way, as we did

-1

> Number 1 could blow up the disco response considerably,
while Number 2
> and 3 allow for a separate query for games.
Unfortunately, I can't come
> up with a nice way to do Number 2.

Using disco#info or disco#items is preferable.

> Our current solution is very similar to a disco#items
query (e.g. MUC
> room query). Are there any good reasons not to do it
that way?

Yes, it's non-standard and other clients won't be able to
play along.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Peter Saint-Andre said the following on 01/14/2008 08:41
PM:
> How many games do you expect clients to support?

Well at first there won't be so many. But if Jabber Games
kick off, the
protocol should be prepared to handle it. Modern
Instant-Messenger
Plugin-Systems could make Game development quite easy and
result in many
many games.

> Using disco#info or disco#items is preferable.

I updated the disco in the XEP at
http://www.cs.uni-potsdam.de/~tgrote/xep/game-support.
html to reflect
Richards proposal (Thanks!) concerning disco#info nodes and
yours
concerning the use of XEP-0059.

It may be an idea to separate the One-to-One and the
Multi-User Gaming
into distinct XEPs, because Multi-User Gaming is quite
complex and
controversial. What do you think?

> Peter

Torsten

Hello

On Wed, Jan 16, 2008 at 10:03:12PM +0100, Torsten Grote
wrote:
> It may be an idea to separate the One-to-One and the
Multi-User Gaming
> into distinct XEPs, because Multi-User Gaming is quite
complex and
> controversial. What do you think?

Well, I would prefer the Multi User version to be as much as
possible similar
to the 1-1. I think it could be easier to reuse many parts.
Isn't it
easier then to have one XEP instead of two, when there would
be just
different transport and some organization added?

-- 
The problem with graduate students, in general, is that they
have
to sleep every few days.

Michal 'vorner' Vaner