[Kde-games-devel] Generic Card Game Framework

[Parker Coates]

On Fri, Mar 12, 2010 at 15:29, John Schneiderman wrote:
> On Thursday 11 March 2010 18:10:09 Parker Coates wrote:
>> LibKCardGame is focused only on the visual presentation and
>> interaction aspects of a card game. Just display, animation, mouse and
>> keyboard input. It makes no attempts at game rules, players, AIs or
>> anything else of that nature which I see are provided by KardsGT. I
>> have no plans to add such thing to LibKCardGame, so that one important
>> area of distinction.
>
> What's the thinking behind only having the visual presentation in the library?

KPat had a decent set of classes for the visual aspects and
interaction handling, so that's what I've been extracting into
LibKCardGame. There are several tricky problems that have been solved
in KPat (multithreaded card rendering and caching, card pile layout
conflicts, efficient animations, etc.) and it makes sense to capture
these in a library. This stuff happens to be common to all card games.
Every card game is going to need to show cards and let the user move
them around. Not every game is going to need AI, players, bidding,
scores, etc.

I'm not in any way claiming that there isn't a need for such a
framework, just that there was no existing generic code in KDEGames to
handle such things so there was nothing to extract into
LibKCardGame.My intention was to clarify that LibKCardGame had a more
limited scope than KardsGT, not that there was anything wrong with
KardsGT's expanded functionality.

>> From looking at the screenshots, it doesn't really seem that KardsGT
>> is up to the graphical quality currently provided by the card games in
>> KDEGames. Can it make use of KDE's SVG based card decks? Does it
>> provide scalable interfaces or animations?
>
> The next stable release is switching to SVG for the card graphics. As the only
> developer, I have focused more on getting a library set-up to easily create
> new card games then to make "wow"-factor graphics. Also doesn't hurt that I'm
> still learning the whole graphics stuff at the moment. :D The interfaces aren't
> scaling right now, and I suspect it has to do with when I started they were
> designed using the Qt Creator. So, that's just a matter of changing a few
> things there. There isn't any code that does animations, but all card
> movements happen by drag-and-drop. So, I imagine adding the animation code
> there would be trivial.  I never said it was ready to go straight into the KDE
> base, but that is where I would like to take the project. The more efforts that
> can be combined, the less time it would take to bring it up in graphical
> quality.

Okay, so I've had a few minutes to look into the KardsGT sources. The
biggest "concern" I found was that it's using a cards-as-widgets
approach. KDEGames has almost entirely switched over to canvas-based
UIs (either KGameCanvas or more commonly nowadays QGraphicsView) as
they tend to make writing attractive, scalable UIs easier. I could see
that being a problem for KardsGT when attracting new game developers,
but of course switching from QWidgets to a canvas is certainly not a
trivial change. What are your thoughts on this?

Personally, my plan is to continue working on LibKCardGame as a
private library inside KPat for the time being as I think this work is
of benefit to KPat, even if the library is never used publicly.

Parker