[Kde-games-devel] KGame/KPlayer API usability in kdegames

[Andreas Beckermann]

On Monday 10 July 2006 16:54, Dmitry Suzdalev wrote:
> On Monday 10 July 2006 18:28, Andreas Beckermann wrote:
> > So why kde-devel instead of kde-games-devel?
>
> Because, everytime I write there my message gets no reply for several days
> :). Plus it turned out that not all game developers subscribed to
> kde-games-devel (surprise!), but are subscribed to kde-devel.

Of course. Rarely anyone writes to kde-games-devel, so theres little point in 
subscribing to it.
That doesn't change the fact that this belongs there :-)

> > On the other hand there are also lots of concepts which worked out
> > perfectly, such as the KGameIO concept which makes network/AI/human
> > players pretty much all the same and thus very easy :-)
>
> As it turned out several days ago (I reported this case here on the list),
> this concept doesn't always work. For example, KGameMouseIO can't handle
> QGraphicsView (qt4 replacement of QCanvas), because QGraphicsView has it's
> own mouse*Event() functions and won't give this event's to outside world
> (in this case to KGameMouseIO::eventFilter() ).
> So it can't be considered general-purpose and working on _any_ widget...

KGameIO != KGameMouseIO
KGameIO is a general concept: all player input is meant to come from an object 
of this class. Thus it is very easy to replace the player input - a network 
player disconnects and the other players want to continue: simply replace the 
network IO by a AI.

It was never said that KGameMouseIO was in any way "general-purpose" or even 
on "_any_ widget". However it worked perfectly for Qt/KDE 3 and that's what 
KGame has been written in.
Don't blame me, if Qt4's canvas replacement doesn't support event filters 
anymore.
Unfortunately I cannot say much on this, because I have not yet looked on 
QGraphicsView at all. All I know about QGraphicsView is the nice blog article 
a while ago and your mail on kde-devel.

> > So if you intend to throw KGame away, please let the relevant people
> > (i.e. especially kde-games-devel) know, so we (in particular me) can use
> > replacements for existing code. In particular it'd be pointless for boson
> > to keep a copy of kgame, if kgame doesn't really exist anymore (atm we
> > provide a copy of the kgame directory, so that boson doesn't depend on
> > libkdegames). And of course my 2 local games that are not in a releasable
> > state will need some changes then, too. So I'd really like to get
> > informed before kgame is going to /dev/null
>
> At the moment I'm not intending anything - I'm collecting information :))).
> Being a newbie, I'm a bit afraid of doing such serious steps as throwing
> away looking-general-purpose classes on my own :).
>
> Btw, you've said you keep kgame copy with boson. Are you using it heavily?

Umm. Yes.
But in large parts completely differently to the original KGame usage.
For example we use the whole KGameProperty concept only to make loading/saving 
(we have a nice little class that saves all KGameProperty objects to xml 
automagically) extremely easy. The whole property-sending concept is not used 
by boson at all (and atm I think it's not a good idea to do so anyway).
Also the "KPlayerSequence" idea is not used at all - boson is a realtime game 
and thus a turn based concept is not applicable at all. Same goes for the 
other "turn based games" support in KGame.

However we do make a lot of use of basic network messaging (KGameMessage, 
KGame::networkTransmission(), ...) and of course the IO system.

Also the KPlayer::userId() (versus KPlayer::id(), which has been renamed to 
KPlayer::kgameId() in our svn - and I will rename in KDE svn sooner or later, 
too) has proven to be highly useful (though it looks very unimpressive): in 
network games it is important to have a unique ID for a player that (ideally) 
also identify the client the player is on. That ID should never ever change 
(you actually want to receive all messages sent to you!). However on the same 
time you want an ID that is as dynamic as possible: you may play the "red 
guys" on the map or the "blue guys" or whatever.
By NOT using KPlayer::id(), which is used and managed by KGame as a unique ID 
that also identifies your client, and using KPlayer::userId() instead for 
your game, you get all this for free :-)

Yeah, I admit it: I talk to much ;-)

> Cheers,
> Dmitry.

CU
Andi