Re: Aisleriot ideas

[Christian Persch <chpe gnome org>]

Hi;

Am Mon, 6 Dec 2010 13:40:10 +1100 (EST)
schrieb "Timothy S. Nelson" <wayland wayland id au>:
>  	Hi all.  I've got some ideas about Aisleriot, and I wanted
> to put them out there and see what people think.
> 
>  	Most of these ideas are aiming to achieve one of the
> following:
> -	Make it easier for people to add new games without having to
> know as much
> -	Make it easier for people to find Solitaire games that they
> like
> 
> A.	Move the XML out of window.c
> 
>  	In window.c lines 2326-2458 contain an XML file.  It has
> preprocessing data in it.  I think it would be nice to have this as a
> separate file.  The pre-processing statements could be left in, and
> it could be preprocessed with "gcc -E".

It could be done that way, but setting up extra Makefile rules vs. just
including it verbatim in the code didn't seem worthwhile. (Note that to
add new games, it's not necessary to change this xml.)

> B.	Have an XML file for data associated with each game
> 
>  	It could include data like:
> - The name of the game (allows punctuation, etc)
> - The Category/Subcategory of the game (is it like Klondike?
> FreeCell? Spider?)
> - The number of decks (single/double deck)
> - The type of deck (ie. have some cards been removed?
> - The number of redeals

I'd also add a rough estimate how difficult the game is.

>  	The data above would then make it possible for games to be
> selected by category.  Also, if it was in XML, the knowledge required
> by contributors would be much lower, so others could contribute the
> descriptions and categorisations, relieving the developers of *that*
> load at least.

Yes, I've wanted to do something like that. This would be used by a
re-designed games selector (the current one just lists all the games by
name). I don't know if you're a coder or not? But even if you're not a
coder, this could be an area to contribute to, by a) providing the data,
and/or b) providing the UI design of the new game chooser.
(In addition to that static game data, the game chooser could also have
access to the user's statistics for each game.)

I'm not sure I'd choose xml for that description; a simple .ini style
keyfile format would probably be enough.

>  	It would also be useful if there were a Scheme function that
> could be called, so that the developers of games could access the XML
> data associated with their game.

The game itself doesn't need access to that data, as far as I can see?
It would be only for use in the UI.

> C.	Reorganise filesystem by game
> 
>  	I wonder if it wouldn't be useful to have a directory called
> "games" that contains a directory for each game, and each game's
> files there.  So you'd end up with things like:
> 
> games/gaps/rules.scm
> games/gaps/C/data.xml
> games/gaps/C/help.xml
> games/backbone/rules.scm
> games/backbone/C/data.xml
> games/backbone/C/help.xml
> 
>  	I'm not sure I've understood the internationalisation stuff
> well enough to have done that properly.  But this should enable the
> translation of individual games, and the like.

I don't think that's necessary (and actually not easy to do without
creating more work for translators). Games are already
translatable, and the game help text is also translatable. And the
proposed new xml (or keyfile) data would just be installed in another
directory, and translated trough the usual means. 

> D.	More .desktop files.
> 
>  	Might it be useful to have the "Aisleriot Solitaire" item on
> the Gnome menus be a submenu instead, and then list all the Solitaire
> games (categorised, of course) directly on the Gnome menus?

Not opposed to that, but not really convinced either. I think you
should put that idea to the gnome-shell design team, since these menus
are their area. (It'll be easy to implement for us, in the event that
they like the idea.)

>  	How would it be to display the score in the "end of game"
> box?  And also say what the maximum possible score is, so that people
> know how they did?

The end-of-game dialogue is certainly due for a makeover, see e.g. bug
#324613; the blocking issue here again is after having a good UI design,
implementing it is easy.

About the score issue I'm actually not sure that scores and meaningful
in aisleriot (e.g. spider always finishes with the same score on
success), but if the design team thinks we should put more emphasis on
scoring, that could certainly be done.

So to summarise, there is a need to come up with an UI design;
non-coders can help with that, and by providing the game data.

Regards,
	Christian