KsirK and Jabber

Hello,

The Jabber enabled version of KsirK is now Jabber-only: it uses no more a
standard TCP/IP connexion after the initial handshake. Everything goes through
Jabber. It was very easy to do so by just reimplementing KMessageIO, a
libkdegames/kgame class. The new class just encodes the content of the
KGameMessage in base 64 and encapsulate it as the body of a Jabber message.

I'd like to thank Olivier Goffart, the kopete jabber plugin developper for his
help in transforming my inital idea in implementation plan.

The current version works with my local ejjaberd server but not with the
kdetalk.net one. Also, there is performance problems in the initialization
phase where a lot of messages are sent. But I will work on that.

When everything will be in line, I think that the Jabber classes could be
useful in libkdegames/kgame. What do you think ?

Also, I wonder if I should keep the possibility to do TCP/IP games ? I suppose
it could be useful for local network games. But will it be used ?

Bye.

Gaël
--
KsirK - a world domination strategy game
http://techbase.kde.org/Projects/Games/Tactic_and_Strategy/KsirK

KGraphViewer - a GraphViz dot graphs viewer
http://extragear.kde.org/apps/kgraphviewer


_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Richard Hartmann]

On Sun, Sep 14, 2008 at 09:43, Kleag <kleag@...> wrote:

> Also, I wonder if I should keep the possibility to do TCP/IP games ? I suppose
> it could be useful for local network games. But will it be used ?

To ask the other way round: What is the benefit of using Jabber as in
intermediate layer? For chatting, Jabber is fine, but for actually
playing a game
over it?
Also, if you abstract the function calls, you can transparently use TCP/IP or
Jabber without much work.


Richard
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Monday 15 September 2008 01:52:38 Richard Hartmann wrote:
Hello,

> On Sun, Sep 14, 2008 at 09:43, Kleag <kleag@...> wrote:
> > Also, I wonder if I should keep the possibility to do TCP/IP games ? I
> > suppose it could be useful for local network games. But will it be used ?
>
> To ask the other way round: What is the benefit of using Jabber as in
> intermediate layer? For chatting, Jabber is fine, but for actually
> playing a game
> over it?
I see 4 benefits:
- no proxy/firewall change: as soon as you have a working Jabber, you can have
games running on your machine or connect to any other running game without
changing your network configuration ;
- very few changes in architecture : using classes gathered from kopete and
the libkdegames/kgame lib, it was very easy to implement ;
- chatroom infrastructure : you inherit from the Jabber chatrooms. It is
really easy to create a chatroom and it is also easy to connect to other
chatrooms to find running games. Also, you can use the very same room to
discuss with other human players about the future games.
- P2P and standardized naming: as soon as you are connected to the Jabber
network, you can connect to any chatroom you know (and are authorized to
reach). In the future, ksirk rooms and games should also be able to tell their
presence to the rest of the world, reducing the need to know a precise
chatroom name.


> Also, if you abstract the function calls, you can transparently use TCP/IP
> or Jabber without much work.
I don't understand what you mean, here. It's already the case, by subclassing
KMessageIO from kgame. Is there another kind of abstraction I don't see ?

Gaël
--
KsirK - a world domination strategy game
http://techbase.kde.org/Projects/Games/Tactic_and_Strategy/KsirK

KGraphViewer - a GraphViz dot graphs viewer
http://extragear.kde.org/apps/kgraphviewer

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

[Richard Hartmann]

On Mon, Sep 15, 2008 at 22:04, Kleag <kleag@...> wrote:

> - no proxy/firewall change: as soon as you have a working Jabber, you can have
> games running on your machine or connect to any other running game without
> changing your network configuration ;

Afaik, KDE games should use a central server provided by KDE, no? In that case,
the firewall/NAT will not pose more or less of a barrier for plain
TCP/IP than for
Jabber.


> - chatroom infrastructure : you inherit from the Jabber chatrooms. It is
> really easy to create a chatroom and it is also easy to connect to other
> chatrooms to find running games. Also, you can use the very same room to
> discuss with other human players about the future games.

You need two rooms for each game. One for talking and one for data exchange.
Otherwise, you would need to filter out certain messages and use them for
game data exchange.


> - P2P and standardized naming: as soon as you are connected to the Jabber
> network, you can connect to any chatroom you know (and are authorized to
> reach). In the future, ksirk rooms and games should also be able to tell their
> presence to the rest of the world, reducing the need to know a precise
> chatroom name.

I thought the announcement should be handled by a central KDE server?
At least, this idea went over this list quite some time back.


Another thing I see as a potential problem is that it would be very easy
for kiddies to disrupt games other people play. Fire up your Jabber client
and spam everyone. The entry barrier is a lot lower than with a seperate
protocol.

Also, this setup does not allow for a central data source. If the 'host'
quits, the whole game will stop (unless you have fall-over provisions).
Without a central, neutral component, cheating is very easy. I can just
modify my local client to have two extra buttons: 'throw sixes in attack'
and 'trump the attack for defense throw'.


Richard
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Richard Hartmann wrote:
> On Mon, Sep 15, 2008 at 22:04, Kleag wrote:
> You need two rooms for each game. One for talking and one for data exchange.
> Otherwise, you would need to filter out certain messages and use them for
> game data exchange.

"DATA: <data>"
"CHAT: Hey, are you going to play, or what?"

...seems like pretty easy filtering. Of course, someone watching with a
raw Jabber client will see extra junk, but is that a problem?

> Another thing I see as a potential problem is that it would be very easy
> for kiddies to disrupt games other people play. Fire up your Jabber client
> and spam everyone. The entry barrier is a lot lower than with a seperate
> protocol.

I don't get it... wouldn't you simply ignore messages from non-players?

> Also, this setup does not allow for a central data source. If the 'host'
> quits, the whole game will stop (unless you have fall-over provisions).
> Without a central, neutral component, cheating is very easy. I can just
> modify my local client to have two extra buttons: 'throw sixes in attack'
> and 'trump the attack for defense throw'.

There's probably some inspiration to be had here from the DOOM engine...
modem play worked because the game engine used a synchronized PRNG, so
that the world behaved the same way on all clients without needing a
central server to determine what a particular entity was doing, since
the synchronized PRNG made that process deterministic.

I think you could avoid cheating by building a similar, synchronized
PRNG into ksirk. Trade seeds at the start, and each client can determine
for itself the result of any random query. If they disagree, someone's
doing something "hinky". At best, you might get a slight advantage
forcing a particular seed, but that's easily avoided by creating the
seed from a combination of inputs from all players. (One honest player
keeps everyone honest; and two or more dishonest players will tend to
neutralize each other.)

--
Matthew
There's no place like ~. -- Unknown

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Tuesday 16 September 2008, Matthew Woehlke wrote:
> There's probably some inspiration to be had here from the DOOM engine...
> modem play worked because the game engine used a synchronized PRNG, so

this doesn't work as well for strategy games like risk when it comes to
preventing cheating, however. here's why:

* ask the PRNG for the next, say, 1000 entries
* use those values as the game progresses for other people's turns
* when it comes to your turn, "peak ahead" at what the results would be for
different moves
* decide the best outcome

now think about card games and this is just insane: you can know exactly what
order the cards are in the deck. talk about your perfect poker cheater! ;)

obviously this is not a trivial hack, but it's not a difficult one either and
makes sync'd PRNGs utterly useless for strategy based games esp when something
valuable is on the line (giving people a reason to do it =)

--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech



_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Aaron J. Seigo wrote:

> On Tuesday 16 September 2008, Matthew Woehlke wrote:
>> There's probably some inspiration to be had here from the DOOM engine...
>> modem play worked because the game engine used a synchronized PRNG, so
>
> this doesn't work as well for strategy games like risk when it comes to
> preventing cheating, however. here's why:
>
> * ask the PRNG for the next, say, 1000 entries
> * use those values as the game progresses for other people's turns
> * when it comes to your turn, "peak ahead" at what the results would be for
> different moves
> * decide the best outcome

Hmm, good point. But what about using the seed distribution system
again? Each machine has a non-deterministic PRNG (at least, one that
cannot be reasonably predicted by any of the other machines within a
single game... which you need anyway, otherwise a central server could
be predicted as well), and contributes X number of bits to any decision.
These bits are then fed into a well-defined formula to generate the
result. Each machine will get the same answer from the same input, but
no machine can predict the answer before the request to generate a
result is made.

--
Matthew
There's no place like ~. -- Unknown

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Tuesday 16 September 2008, Matthew Woehlke wrote:
> Hmm, good point. But what about using the seed distribution system
> again?

assuming you can generate enough entropy between requests, that should
probably work.

note that you can only have as many players as there are bits in the seed
before it starts to break down (on disconnect you could re-choose seed
contributors; or rotate between players). i doubt that will be an issue for
most games though =)

in the case of 2 players, one side could wait for the contributed bits and
then match it with their own to produce a desired result. it would get a bit
harder as the number of players increase, but still feasible.

any local input to the random number generator creates some weakness.

it's a question of how much and if you care.

p.s. i remember the same "common seed, local generation" mechanism on a mac
game called "robowars"

--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech



_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Hello,

On Tuesday 16 September 2008 16:03:50 Richard Hartmann wrote:
> On Mon, Sep 15, 2008 at 22:04, Kleag <kleag@...> wrote:
> > - no proxy/firewall change: as soon as you have a working Jabber, you can
> > have games running on your machine or connect to any other running game
> > without changing your network configuration ;
>
> Afaik, KDE games should use a central server provided by KDE, no? In that
> case, the firewall/NAT will not pose more or less of a barrier for plain
> TCP/IP than for
> Jabber.
Personally, I dislike centralized solutions. Even if they present advantages,
it seems to me to go against my view of the freedom spirit of free software.
Well, don't take that too seriously, it's not so important but it express a
part of why I want to continue this way.
Concerning the "should use a central server...". The existence of the central
kde games server serving games that even can be interoperable with Gnome (?)
is a Great Thing (TM) but really it should not forbid experimentations toward
other ways of doing. We are in the free software world where many great things
come from initial little experiments. And, as said elsewhere, "who code
decide" :-)

>
> > - chatroom infrastructure : you inherit from the Jabber chatrooms. It is
> > really easy to create a chatroom and it is also easy to connect to other
> > chatrooms to find running games. Also, you can use the very same rosom to
> > discuss with other human players about the future games.
>
> You need two rooms for each game. One for talking and one for data
> exchange. Otherwise, you would need to filter out certain messages and use
> them for game data exchange.
No, no (and you can already try it, it is available). Because I kept my
original design where one of the clients become the server of a running game
and all the others send personal messages to its full id in the room, thus
avoiding displays in the room.
>
> > - P2P and standardized naming: as soon as you are connected to the Jabber
> > network, you can connect to any chatroom you know (and are authorized to
> > reach). In the future, ksirk rooms and games should also be able to tell
> > their presence to the rest of the world, reducing the need to know a
> > precise chatroom name.
>
> I thought the announcement should be handled by a central KDE server?
> At least, this idea went over this list quite some time back.
Well, as said before, centralization is not a must have in my mind, but there
is also the possibility to have a central "official" kde games jabber room...

>
>
> Another thing I see as a potential problem is that it would be very easy
> for kiddies to disrupt games other people play. Fire up your Jabber client
> and spam everyone. The entry barrier is a lot lower than with a seperate
> protocol.
A generic protocol cannot be a bad thing. It's just a language and it's
extensible if necessary to add all what is necessary to provide needed
security.

>
> Also, this setup does not allow for a central data source. If the 'host'
> quits, the whole game will stop (unless you have fall-over provisions).
It's conceived like that: if one of the clients quit, then the server propose
to save the game that can be restarted later. Only if the central player crash
the game is lost.

> Without a central, neutral component, cheating is very easy. I can just
> modify my local client to have two extra buttons: 'throw sixes in attack'
> and 'trump the attack for defense throw'.
Well, I wrote in a previous mail that fighting against cheating is not my
current priority. Trust, you know :-) And in fact, you have just to trust the
central/server peer: it's him who takes all the decisions. If you trust him,
you trust the game. If we want more distributed trust, I'm sure that there is
solutions like the one suggested by other posters in this thread or the
cryptographic systems used in distributed P2P databases.

Gaël
>
>
> Richard
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel@...
> https://mail.kde.org/mailman/listinfo/kde-games-devel

--
KsirK - a world domination strategy game
http://techbase.kde.org/Projects/Games/Tactic_and_Strategy/KsirK

KGraphViewer - a GraphViz dot graphs viewer
http://extragear.kde.org/apps/kgraphviewer

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Aaron J. Seigo wrote:
> On Tuesday 16 September 2008, Matthew Woehlke wrote:
>> Hmm, good point. But what about using the seed distribution system
>> again?
>
> assuming you can generate enough entropy between requests, that should
> probably work.

Well, you'd *better* be able to generate enough entropy :-). Otherwise,
a central server is going to have the same predictability problem, no?

(Maybe not, since a central server using a monolithic PRNG may be
unpredictable in not knowing how many bits it has fed out since the last
ones you saw, but conversely, individual players have much more time to
generate additional entropy than a busy central server.)

> note that you can only have as many players as there are bits in the seed
> before it starts to break down (on disconnect you could re-choose seed
> contributors; or rotate between players). i doubt that will be an issue for
> most games though =)

I think that would depend on how you feed the bits into the PRNG, i.e.
you could probably use a bitstream-based PRNG that can accept any number
of input bits. But as you say, how many games have that many players? ;-)

--
Matthew
There's no place like ~. -- Unknown

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Kleag wrote:
> Concerning the "should use a central server...". The existence of the central
> kde games server serving games that even can be interoperable with Gnome (?)
> is a Great Thing (TM) but really it should not forbid experimentations toward
> other ways of doing. We are in the free software world where many great things
> come from initial little experiments. And, as said elsewhere, "who code
> decide" :-)

I agree 100% with you on this. I do not see any harm in attempting to
provide a different way for multiplayer games. Who knows if in the near
future we will find out that playing KsirK over Jabber becomes a new
trend and helps us attract a new community that we would have missed
otherwise?

Regards,
Mauricio Piacentini
_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Tuesday 16 September 2008, Matthew Woehlke wrote:

> Aaron J. Seigo wrote:
> > On Tuesday 16 September 2008, Matthew Woehlke wrote:
> >> Hmm, good point. But what about using the seed distribution system
> >> again?
> >
> > assuming you can generate enough entropy between requests, that should
> > probably work.
>
> Well, you'd *better* be able to generate enough entropy :-). Otherwise,
> a central server is going to have the same predictability problem, no?

no, because you're not re-seeding the PRNG each time you go to get a result.
if you don't get enough entropy between re-seeds, e.g. the see is the same,
then you end up with a predictable result. SO... one client could simply
request random numbers constantly from the clients and "peek ahead" that way
too if the entropy is too low.

> > note that you can only have as many players as there are bits in the seed
> > before it starts to break down (on disconnect you could re-choose seed
> > contributors; or rotate between players). i doubt that will be an issue
> > for most games though =)
>
> I think that would depend on how you feed the bits into the PRNG, i.e.
> you could probably use a bitstream-based PRNG that can accept any number
> of input bits. But as you say, how many games have that many players? ;-)

yeah, it's not like we're making WoW

still ... central server is way more straightforward for this...

if *i* was writing the code (i'm not, btw ;) then i'd create a PRNG interface
with three implementations: all-local (use the local PRNG only for local only
games), sync'd-seed, central server.

the library with the PRNG access in it would use local PRNG if it's not a
network game, and try the central server if it was and failing that fall back
to the sync'd seed mechanism which may be less reliable but at least let you
play =)

--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Tuesday 16 September 2008, Kleag wrote:
> Personally, I dislike centralized solutions. Even if they present
> advantages, it seems to me to go against my view of the freedom spirit of
> free software.

assumedly, the central server software would be available to anyone to run.

btw... the central server could be a jabber server plugin.

--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech



_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Aaron J. Seigo wrote:

> On Tuesday 16 September 2008, Matthew Woehlke wrote:
>> Aaron J. Seigo wrote:
>>> On Tuesday 16 September 2008, Matthew Woehlke wrote:
>>>> Hmm, good point. But what about using the seed distribution system
>>>> again?
>>> assuming you can generate enough entropy between requests, that should
>>> probably work.
>> Well, you'd *better* be able to generate enough entropy :-). Otherwise,
>> a central server is going to have the same predictability problem, no?
>
> no, because you're not re-seeding the PRNG each time you go to get a result.
> if you don't get enough entropy between re-seeds, e.g. the see is the same,
> then you end up with a predictable result. SO... one client could simply
> request random numbers constantly from the clients and "peek ahead" that way
> too if the entropy is too low.

I guess I don't get it. Either I don't understand why you couldn't do
that to a server also, or else I don't understand why the other clients
wouldn't either simply ignore an unexpected PRN request or else
interpret it as a breach of protocol.

--
Matthew
There's no place like ~. -- Unknown

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Tuesday 16 September 2008, Matthew Woehlke wrote:
> I guess I don't get it. Either I don't understand why you couldn't do
> that to a server also, or else I don't understand why the other clients
> wouldn't either simply ignore an unexpected PRN request or else
> interpret it as a breach of protocol.

there's a difference, or at least should be with a PRNG, between knowing the
entropy (seed) and knowing the current value.

with a central server you only know the current value, the next value should
be statistically random.

with a coordinated seed, you know the internal state of the PRNG which renders
it statistically predictable.

PRNG's only appear random due to information hiding (the seed) which is why
the Doom approach works in the first place.

--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech



_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

Aaron J. Seigo wrote:

> On Tuesday 16 September 2008, Matthew Woehlke wrote:
>> I guess I don't get it. Either I don't understand why you couldn't do
>> that to a server also, or else I don't understand why the other clients
>> wouldn't either simply ignore an unexpected PRN request or else
>> interpret it as a breach of protocol.
>
> there's a difference, or at least should be with a PRNG, between knowing the
> entropy (seed) and knowing the current value.
>
> with a central server you only know the current value, the next value should
> be statistically random.

Right. But the distributed seed system is supposed to make the next
*seed* random, so, while you know the seed for the current turn, you
don't know it (and hence, don't know what random values will be
generated) for the /next/ turn. And you wouldn't know it for the current
turn until /after/ you've committed to a course of action.

So I still don't get it; maybe I'm failing to explain my idea clearly?

My envisioned flow is something like:

- Commit to a course of action
- Tell all clients what you are doing this turn
- Clients send back a partial seed
- Use the combined seed to determine the outcome of the action
- Throw that seed away

...but because the seeds come from their own PRNG's, which are only
known to the clients generating the seed, no client knows what the next
seed will be (assuming the PRNG generating the seed is robust), and thus
you can't predict the outcome.

--
Matthew
There's no place like ~. -- Unknown

_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel

On Tuesday 16 September 2008, Matthew Woehlke wrote:
> - Commit to a course of action
> - Tell all clients what you are doing this turn
> - Clients send back a partial seed

- wait for their seed parts
- calculate the missing part of the seed that does you the best favour
- send your part of their seed

> - Use the combined seed to determine the outcome of the action
> - Throw that seed away


--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech



_______________________________________________
kde-games-devel mailing list
kde-games-devel@...
https://mail.kde.org/mailman/listinfo/kde-games-devel