[jdev] how to program a jabber game server

Richard Dobson richard at dobson-i.net
Wed Feb 7 09:13:46 CST 2007


> Anyway, in that case (with an evolving number of game hosts), game 
> hosts can not
> be internal components because they have to be launched dynamically 
> (by another
> host or by the game matching service). That's the point I wanted to be 
> sure of, which
> implies my game hosts have to be bots.
Technically speaking they could still be internal components being 
loaded dynamically, although its just an implementation issue as to 
whether you implement them internally or as bots, for example my server 
platform can host domains (like the matching service) i.e. 
games.domain.com over multiple machines balancing the load without the 
user being aware of that at the protocol level, but yes the beauty of 
the way I have suggested doing the protocol/architecture for this is 
that it doesn't matter if the game hosts are components, bots or indeed 
end user clients, as from the protocol perspective there is no 
difference between interacting with any of them, so from your 
perspective yes it should be fine having the game hosts as bots for ease 
of implementation.

Here is an example of the protocol I am working on when you are 
requesting to start a game session at a game host.

<iq type="set" id="tag_1" to="battleship at games.domain.com" 
from="user at domain.com">
    <start xmlns="http://domain.com/protocol/game" 
type="http://dobson-i.net/protocol/game/battleship" />
</iq>

and the host responds with:

<iq type="result" id="tag_1" from="battleship at games.domain.com" 
to="user at domain.com">
    <started xmlns="http://domain.com/protocol/game" 
id="ddfd4654544aeea2136121" />
</iq>

the id is then used for all subsequent communications about the game, I 
am also considering sending directed presence from the client to the 
game host to avoid orphaned games, or maybe some kind of ping and 
time-out option to detect that, but this is all a work in progress 
regarding the exact protocol and will likely change quite a bit.

Richard




More information about the JDev mailing list