[jdev] how to program a jabber game server

Richard Dobson richard at dobson-i.net
Wed Feb 7 05:37:51 CST 2007


Denis Guillaume wrote:
>
> "The easiest way (and how im implementing it) is for the game component
> to handle it all, what you are thinking of as a bot rather be handled by
> the game component directly."
Kind of, but that wasn't really a clear explanation of what I was trying 
to get at, ill try to explain more clearly below.
>  But in fact, being bots or components, what I would find flexible is the
> possibility to plug them dynamically this way :
> - the GameSessionsComponent is asked by a client to create a new session
>  game ;
> - this session is then simply a MUC managed by a dynamically plugged
> RefereeComponent or RefereeBot.
That is far more complex that it ever needs to be.

Well the way I am developing it is that technically from the protocol 
perspective there is no distinction between what you are calling 
gamesessioncomponent, refereecomponent and refereebot, the only two 
entities as far as initiating and managing a game are "game host" and 
"game client".

Now the game host can be anything, a component, a bot or another user, 
all it is is a JID which you communicate with to create a game session, 
send any game moves/actions and the game host will then distribute game 
state (i.e. any moves they should be aware of) out to all the game 
clients, be these players or observers, the moves are not sent via MUC 
rooms to make things nice and simple as a lot of games require that 
players only know a certain amount of the game state and should not know 
everything (only the game host should) examples of these sort of games 
are battleships, scrabble, poker (infact probably all card games), I can 
only think of a few instances of games where the entire game state is 
know by all players (chess and checkers), and it makes things far 
simpler for the game host to directly send out the game state, rather 
than having to have two sets of game state being sent separately, i.e. 
global state being sent via a MUC room and private state being sent 
directly, you would also need extra security in place in the MUC room to 
ensure other players couldnt send game state into the room that players 
would blindly think is from the host, so if a MUC room is associated 
with a game it is solely there for ingame chat between the game clients. 
This all makes things nice and simple and is inline with how proper 
online games usually work (i.e. there being a central host for the game, 
along with clients).

Right so, as far as a particular game session goes there are just two 
entities, "game host" and "game client", but there is also a third 
entity that might come into play but is not entirely required for gaming 
to function and that is the "game matching service". Now the game 
matching service is basically somewhere where you can browse a list of 
available games and find other people to play with (via disco), its 
pretty simple really.

In my implementation that I am working on I have a component acting as 
both the "game matching service" and the "game host", but this need not 
necessarily be the case (although its easiest for me to implement it 
this way) as you could just have the game matching service as a 
component which lists game hosts that aren't actually part of the 
component but which could be standalone bots, or simply games hosted by 
someone elses component, or even a users client which has registered a 
particular game with the matching service that it can host.

So if a user was trying to play a game (via the matching service) it 
would work as follows.

S = Matching service
M = MUC server
H = Game host
C = Game client

C [requests game listing]--> S
S [returns game listing]--> C

The client wants to play scrabble and finds a scrabble host in the list.

C [request to initiate scrabble session]--> H
H [creates ingame chat MUC room]--> M
M [MUC room created]--> H
H [game session started, includes MUC room address]--> C
C [invites other players]--> H
C [makes move/action]--> H
H [distributes game state changes to players]--> C
C [ends game]--> H

Richard





More information about the JDev mailing list