[Kde-games-devel] Memorandum. RE.: KDEGames monthly meeting.

Mauricio Piacentini piacentini at kde.org
Tue Jan 22 12:32:26 CET 2008


Ian Wadham wrote:
> So in case I am unable to attend this time, here is my 2c worth:-
> 
> Procedural: Major decisions at IRC meetings should be published,
> discussed and confirmed on this list, for the benefit of those who
> were unable, for whatever reason, to attend the meeting.

I hope you will be able to participate this time, for fun! But I agree 
with you that the serious "decisions" on the meeting should also be 
confirmed via the mailing list. I think this is more or less what 
happens already, isn't it? Even when games were removed we had a list of 
"candidates for removal", and a last chance to rescue them via mailing 
list (which saved KJumpingCube :))

> General: KDE Games is and always has been a "module", so we should
> start acting as though it is a true module, not just a convenience for
> compiling and packaging.  We should accept collective responsibility
> for the *contents* of the module, particularly if/when the module's
> requirements change, as they have done so dramatically in the last
> two years.  If the original author or maintainer of a game is still
> around, well and good - then no doubt they can "maintain" the
> game to the module's requirements.  But if they are not around, or
> if they have other programming priorities, then the group should
> feel honour-bound to step in and meet the new requirements.
> 
> It is up to us collectively to keep all the games alive, for as long as
> they have value to players and end-users.

I think we all agree that it is time to change our working mode, from 
trying to cut stuff and define policies to trying to be creative, refine 
and build new stuff. This means (for me) that we should probably try to 
stop defining new compulsory module policies, or forcing authors to 
implement a given feature in a given way. We had 2 years of that, now it 
is time to relax. So to be very clear: I am fundamentally against 
compulsory implementation of the itens listed in

http://techbase.kde.org/index.php?title=Projects/Games/Ideas

Under the 'Visual Changes' header. I do not feel like discussing 
*compulsory* implementation or removal of toolbars and statusbars again, 
and the unified screen interface specifics. Remember the KDE motto: he 
who does the work decides. If an author does not feel it is appropriate 
(or do not have time/motivation) to use SVG graphics, or Get New Stuff, 
or any other common feature, this is/should continue to be allowed. No 
stress. Games that are in the module now have already crossed our bar. 
No need to continue to increase it.
Of course, if people want to work on a better shared highscore system 
for example, or a better notification system, or a good way to use KNS 
that can be abstracted and added easily to other games, I am all for it. 
What will happen is that organically and over time more games will pick 
up these bits, and will naturally start to look and feel the same, IF 
the solution is good. Darwinism at its best.
So to be clear, I think it is time to start experimenting in a different 
  energy path, so I am with Ian and Josef on this. We created a number 
of interesting shared technologies and methods of work, and we need some 
rest from this constant need of *compulsory* porting and changing to 
new/shared APIs. Huge importance to the *compulsory* bit: I still 
believe everything that could be abstracted and shared should be coded 
in a way that makes this possible in the future (and I have done this in 
libkmahjongg and some parts of libkdegames.) But let it evolve more 
organically for now. I speak for myself, I am a bit tired of discussing 
architectural possibilities and porting code, and not having the time to 
finish KBlocks. One of the reasons I did not finish it was exactly due 
to the whole discussion about statusbars and onscreen points, which 
drained a lot of my motivation at that time. And at the end, it was all 
for nothing, as other games continue to use these elements  (*)

> So my vote is to do *both* of the above, refine existing games, add
> new games and revive KDE 3 games that were passed over, but avoid
> too great a burden of cosmetic and new-GUI features, such as those
> proposed under "Visuals changes", "User interaction" and "On screen
> interface" in the above-mentioned Ideas page.

+1, +1, +1. Not that I think that there is something fundamentally wrong 
with some of the ideas, I just think they should not be compulsory or 
whole-module-affairs. A nice strategy could be if someone wants to 
experiment with some (of all) of these ideas in ONE game. This is a nice 
start: maybe we will end up with good technology and APIs that other can 
use in the future as well, maybe for 4.2, 4.3, or 5.

Personal plans for 4.1: finish KBlocks, work on KMahjongg's level 
editor, some cleanup of KShisen.

Best regards,
Mauricio Piacentini

(*) For KBlocks, I still plan to investigate on-screen interface and 
points display. But as it is 4.1 territory, I think I can experiment 
with Qt4.4's widgets-on-canvas feature for this, so it should take an 
additional month or two for this to be done.


More information about the kde-games-devel mailing list