[Kde-games-devel] Unify pixmap caching across card games

[Luciano Montanaro]

Il Sunday 06 January 2008 13:12:38 Andreas Pakulat ha scritto:
> On 06.01.08 11:57:05, Andreas Pakulat wrote:
> > Hi,
> >
> > I've started to work on unifying the pixmap caching across card games,
> > currently that involves kpat and lskat which are in kdegames presently.
> >
> > I'm planning to use KPixmapCache behind the scenes instead of any custom
> > caching method for the pre-rendered SVG's. For this to work well across
> > all card games I've created a new class CardCache in libkdegames and I'd
> > like to have a discussion about the API.
> >
> > The attached file contains the header of this class including api dox,
> > so please have a look and send your comments.
>
> Sorry, forgot to attach the actual file...
>
> Andreas

I have looked superficially at the code.

My comments:

I'd use card() and backside() instead of getCard(), since this is the 
conventions used throughout kde.

Also, the theme and size is not going to change that often in normal use.
So I'd use setTheme() and setSize() methods to set those when they need to 
change.

The card() method (or front() method?) could then be card(suit, value);

The enum start with Ace, then King... is this the best choice? 

I'd go with Ace, Dice, ... King. Card value are assigned differently in 
different games / different traditions.

The load method should either ask for the cards suit and values it needs to 
load, or for a fixed enum like Deck52, Deck40 or so on...

One of the decks we ship has card numbered up to 13.... Some game may need 
that option. Also it would be nice to support tarot decks, eventually! :)

Some game could benefit from having more than one back available. 
Games like "Scala 40" are played with two decks of cards; traditionally the 
two decks have different backs (red and blue), and it would be nice to offer 
this option.

Our decks have Jolly joker cards too. Those can't be represented with a 
suit+value combination...

Finally, I'd really like to be able to "get rid" of the separate backs themes 
somehow. But others like it; I think this can be solved if we understand each 
other better. 

My problem with the separate backs is that we do not have (rightly) any 
convention on the size/ratio of the cards, or on their shape. In the world 
there are decks of many different shapes, from circular, to tall and thin, to 
square... all of those card shapes could work in our games, in principle.

They would not work with backs that are not part of the design, however.

So the simplest option to give a few options to the players is to add a few 
(or many) back variants directly in the deck svg. The backs could be selected 
by name, if we name them progressively ("back_1", "back_2"...) or we could 
give a class="back" attribute to the cards drawings that are supposed to be 
used as backs, and then offer all of them for selection in the card dialog.

It would be easy enough to add all the current svg backs (modified to match 
the deck aspect ratio and shape) to the svg card decks. 

Well, I really wrote much more than I wanted to...
I hope I did not dissuade you to work on this, however!

Luciano