On May 1st, the KDE games developer community held its monthly IRC meeting. This time the major topic was discussing which games would stay in the kdegames module for KDE 4 and which ones would have to be removed because they don't meet our self-imposed quality standards. Read on for a discussion of this decision.

Our quality standards focus on having resizable, scalable interfaces as modern computers
now feature high resolution screens, and having non-resizable games decreases their usability, so now most KDE games use SVG graphics or similar techniques to achieve this functionality.

KAtomic (KDE 3)

KAtomic (KDE 4)

KReversi (KDE 3)

KReversi (KDE 4)

KBounce (KDE 3)

KBounce (KDE 4)

Over the KDE 4.0 development timeline, KDE games has welcomed two new additions, KSquares a
KDE implementation of the paper "squares" game and Kiriki, a Tali dice game.

KSquares

Kiriki

Unfortunately, there are around 10 games that did not made the cut, mostly because
no maintainer was found to work on the KDE 3 to KDE 4 transition.

Atlantik

KFouleggs

Klickety

KPoker

Kenolaba

KAsteroids

KSnake

KSokoban

KJumpingcube

KTron

If any of these games is on your list of favorite games, join us and start working on it so it makes a star comeback in KDE 4.1.

Also, imho, some of the options in the Lipstik style for KDE 3 should be default in the default KDE 4 style (oxygen?), such as not drawing seperators and handles, and not drawing a status bar frame. This along with application creators cleaning up the toolbars would give KDE a much cleaner look.

Just my two cents. And if it's not default, atleast it's customizable. Thats what I love about KDE. Keep up the good work! :)

Is there any convenient way to make a group of Qt/KDE toolbar buttons (I wouldn't know if KDE provide their own toolbar/tool button widgets) all take the width of the largest button in the group?

Given that most toolbar buttons are quite narrow anyway, this wouldn't usually increase the width significantly. I just find that a group of buttons of slightly different widths tends to stand out in a very bad way - does anyone else feel this way?

"Also, imho, some of the options in the Lipstik style for KDE 3 should be default in the default KDE 4 style (oxygen?), such as not drawing seperators and handles, and not drawing a status bar frame. This along with application creators cleaning up the toolbars would give KDE a much cleaner look."
totally agree !!

> i'm quite sure the borders in this article are mostly
> added by developers on purpose.

No, that is not the case. The explanation here is that the view in KReversi is housed in a scroll area, and scroll areas have borders by default. You have to add additional code ( not very much, only one line ) to turn it off. I just committed a patch to do that. In fairness to the developer(s), they are spending their time on the important functional points of the application that matter - in this case the game logic and artwork. These little fit and finish tweaks are a good opportunity for new coders to contribute. You don't need a very detailed understanding of C++ either.

Using the Cleanlooks style provided with Qt4 ( a copy of the Gnome Clearlooks style ) produces a more attractive interface.

Would it be possible to change the code of the scroll area class so that that it only shows the border _if_ the scroll itself is visible? If this behavior occurs by default, the application that incorporates the scroll area doesn't have to care about when to place the border (although it would still be able to override the default behavior if it wants).

Removing borders is not hard. It's something _you_ can do yourself. Just run through the kde4 applications, and whenever you notice an ugly border add the single line of code that turns the border off and send of a patch to the maintainer. It's a great way to get involved and grow beyond an anonymous coward into a valued member of the community.

At least not like that. Don't go about making such decisions in the application as it affect every style.

Instead ask the style developer of your favourite style to not draw borders in the scrollview. That way every program will be fixed at one, and you you don't remove borders from styles that actually want it.

we already have proof for this in kde3 where various styles try various things with borders resulting in various apps looking alternately bad or good depending on which app and which style. =/ so i have to agree with you here.

I'd like to congratulate the kdegames team on their work for KDE 4 so far.

Along with many of the kdeedu applications, the KDE 3 / KDE 4 difference is night and day.

The swish new artwork in particular looks great.

If I may insert a request, it would be helpful to have an overlay or some other quick-to-access help screen which explains what a game is and how to play. Opening up and reading the manual is a bit of a chore to do when you are after a ten-minute distraction. Thanks again :)

iirc, there is a tutorial mode for one of the games and the intention is to add tutorials to the other games over time as well. this should do what you want and would be available from the same opening screen overlay that offers to start a game =)

I like when modules are cleaned up (waves at dannya and his kdeartwork efforts) so the improved quality of the kdegames module is good news for KDE in general, as it's one of the first things new KDE users will look at, especially if they are not net connected.

I find myself playing ktron a lot. It's a good distraction that is over quickly. Hopefully a maintainer could be found, but if not it's understandable to me, as I wouldn't have the time or motivation to do it myself.

IMHO armagetron is a lot nicer I would rather they took the time to work with armagetrons developers to properly intergrate and update an existing game than waste efforts on an older title that needs far more work. I'm sure if you look around you can find many fitting games that could be worked on and then shipped with kde.

Sure armagetron looks nicer. But it misses the feature of ktron that attracts me: over quickly. Armagetron is a bit more involved, and not as good a way to blow off a little steam for a minute or two (or 30 seconds). Navigating armagetron's menus takes almost that long ;)

Ksame is a very similar game, and that is alive and well for KDE 4.
There will be no klickety for 4.0 unless a maintainer appears out of nowhere in the next couple of days and starts getting it into shape. And that's pretty unlikely I'm afraid.

these are amusements and distractions, not "games" as used in the context of "the gaming industry". there are a couple types of games: simple, fun things to play and full-on entertainment. the latter are more akin to movies and novels, the former are more like solitaire, soduko and crosswords. in fact, that's often where the source material comes from. =)

yeah.. the gaming industry is not motivated to do something about Linux. I could not care less, because 95% of those "games" are like glossy paper. Looking shiny but little substance.
Try playing bzflag with your mates. Trashy GFX, looks like crap actually, but loads of fun for hours. I don't want the game to provide complexity, I want the game to be made of simple rules to built the basis for some complex gameplay.

As I understand all that is needed is a KDE4 development plattform. But as long as pre-alpha nothing will happen. How does porting Games from KDE3 to KDE 4 work? What are the differences and what time does it take per game?

Many distributions already have KDE 4 packages for developers, and when alpha 1 is released, many more will do so (I happen to know a bit about that ;-)).

About the porting of the games, my impression is that it's some work, but not too much. It seems pretty doable, which makes sense, as the games aren't that big. Help of artists is important, though, as you will need some help in the art area for nice, scalable graphics.

The biggest work needed to port games from KDE 3 to KDE 4 is changing them to use Qt 4 rather than Qt 3. Other than that there are a few other upgrades which are being added to all appropriate games like resizable, scalable interfaces and theme support.
With regards to time, it really depends on the complexity of the game. The change to how Qt 4 handles graphics is quite significant.

Whenever I see preview pics of KDE4's new game graphics, the one thing that keeps bugging me is the blocks, particularly when they're in large groups. Maybe it's the dark edges/color, the identical lighting, or the way they leave gaps when stacked, but in a word, they don't look "real" at all. It's kind of distracting...

This is one place to help improve KDE where neither programming or creative artistic skill are needed. The graphic are just SVGs and as good as finished, only minor modifications needed. So why not try tweaking it yourself and apply that last bit of polish making it better. That way the games developers/artist can consentrate on more pressing matters, like porting the rest of the games. While you improve it from decent to perfect :-)

No :)
The new Kolf artwork is currently "programmer art" made by me, so although it looks better than KDE 3 kolf it has yet to had much work on it from anyone with any real artistic skill. Don't worry, this will happen before the KDE 4 release, but there is little point showing you a current screen shot as there are likely to be big changes between now and October.
Of course if you are desperate to see it you could drop me an email, but I don't want to post anything public yet.