[Kde-games-devel] KGame: A few questions

[Inge Wallin]

On Sun, 1 Aug 2004, Martin Heni wrote:
> I wrote:
> > nice vacation :-) ), but now I feel it is time go get going again so that I
> > can have something to deliver as soon as KDE 3.3 is released.
>
> It would be excellent if someone would work and improve libkdegames!!

Well, that would certainly be part of it.  But my first goal is to make
some of the current games in KDEgames actually use it.  My first project
will be kreversi.

> > 1. How up-to-date is Martin Henis docs?
> The basic structure is to my knowledge the same (although I did not have
> time to look into it much lately)

Good.

> > 2. There are two distinct meanings of the word "game":
> > My language, Swedish, has two distinct words for the two, and in my
> Interesting point. Might be worth a thought. At the moment you are right,
> that KGame combines both.

I have thought about it some more.  This is actually not a problem.  It
can be solved without introducing any backward incompatibilities.

> > 3. Sometimes a game (in the sense b) above) can have viewers that should be
> > able to comment to each other about the game. Should this be implemented as
> > KPlayers, and, if so, what would be the best way to do it? The players in
> > the game shouldn't be able to see the comments, at least not until the game
> > is over.
>
> The KPlayer concept supports this.

However, it is not entirely clear how this should be done.  Setting a
player to state inactive, which could be one alternative, is not the same
as making it a viewer.

> > 4. If I want to analyze a game (in the b) sense), I might want to look at
> > variations, and then save them.  This doesn't seem to be supported by
> > KGame.
>
> All and any game situation can be saved and loaded by kgame. Therefore also
> variations. This should work.

Yes.

> It does not support any format internally. This is up to the programmer.
> However, a unified game format could be added to the library.

I will have a shot at it.

> All KDE is work in progress. The KGame libs seem to work allright. But
> refactoring them is in principle ok. However, you have to keep in mind
> to guarantee compatibility (source&binary) depending on the KDE release 3.x
> etc. You have to read the KDE compatibility guides. Maybe target a major
> change to KDE 4.0?

I couldn't find anything more official than this link to KDE myths
(http://kdemyths.urbanlizard.com/viewMyth.php?mythID=42).  Did you have
anything else in mind?

Anyway, as I mentioned above, I don't think we need to actually change
KGame et al.  We only need to introduce some inheritances and
specializations.


So, without further ado, here is my current work plan:

I. Prepare kreversi for use of KGame.  This consists mainly of some small
   refactorizations.
   a. Change the name Player in Score.h to Color.  This is actually what
      it is.
   b. Introduce "Color  m_to_move" into the class Position.  The color to
      move is definitely part of the position of a game.
   c. Maybe remove the class Score, since it is mainly a trivial array[2]
      of ints.

   These steps should be fairly uncontroversial.

   d. Separate the engine into its own subdirectory.  This would prepare
      for the possibility of more (and better!) engines as well as
      separating the code for the view (actual GUI) from the document (the
      Game).

   Somewhat controversial since CVS is so bad at things like this.

II. Switch kreversi over to using KGame et al.
   I think that this has to be done in one step.  I don't think we can
   do this in smaller increments.  I will try to make the code changes as
   small as possible though.

III. Enhance kreversi with new functions made possible by KGame.  Many of
     these are taken from bugzilla.
   a. Human-human game
   b. Computer-computer game
   c. Network game

In parallel with these enhancements, I would like to enhance the code
quality.  For one thing, there are too few comments to my liking.  For
another, the lack of formatting in many places obscures the inner working
unnecessarily.

Until I have my own CVS privileges, I will send the patches to the list
for comments.  Then somebody has to commit the changes.  I had some
contact with Nicolas Hadacek earlier this summer and he seemed to be
somewhat in charge of kreversi.  Maybe he or You (Martin) would be the
best to do it?

So.  Now to some practical questions.  I understand that there is a code
freeze in place, and that there will be so until KDE 3.3 is released.

1. Comments on the plan?

2. Can I / we perhaps work on a CVS branch until the end of the freeze?  I
   have seen other examples of this.

3. Shall I send the patches to the list or in private mail?

4. How can I get the size of these d*mn mails down to something
   reasonable?  :-)

	-Inge

Inge Wallin               | Thus spake the master programmer:               |
                          |      "After three days without programming,     |
inge at lysator.liu.se       |       life becomes meaningless."                |
                          | Geoffrey James: The Tao of Programming.         |