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="[EMAIL PROTECTED]"
from="[EMAIL PROTECTED]">
<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="[EMAIL PROTECTED]"
to="[EMAIL PROTECTED]">
<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
