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

[Dmitry Suzdalev]

On Monday 10 July 2006 19:23, Andreas Beckermann wrote:
> 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 :-)
Oh... What to do then? Always post to both lists to get some audience? :)
I'd love to see all game-related questions in corresponding mailing list, but 
*sigh* atm it takes sooo long to get an answer...

> 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.
Yes, but KGameMouseIO is ": public KGameIO". So, when it stops working for me 
on a QGraphicsView it renders a whole idea unusable.

For example in kwin4 there's a code like

// 'ioType' is read from config file
someFunc( int ioType ) 
{
    KGameIO* input = 0;
    if( ioType == KGameIO::MouseIO )
        input = new KGameMouseIO(...);
    else if( ioType == KGameIO::KeyIO )
        input = new KGameKeyIO(...);
    else if( ioType == KGameIO::ProcessIO )
        input = new KGameProcessIO(...);
 ......
}

I'm currently stuck at this.
KGameMouseIO isn't working with QGraphicsView (so is KGameKeyIO), but other 
IOs work OK.
What should I do?
Implement key+mouse input as QGraphicsView dictates - through mouse*Event 
functions, and remove corresponding branches in 'if' above?
That's quite a mess I'd say.
Don't know what to do...

> 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.
I don't blame you at all ;). Nor anyone else :).

> 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 ;-)
That's good :).
Nice to read you ;).

Dmitry.