[Kde-games-devel] KGame/KPlayer API usability in kdegames
Andreas Beckermann
b_mann at gmx.de
Mon Jul 10 17:23:19 CEST 2006
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
More information about the kde-games-devel
mailing list