Re: Aisleriot ideas

["Timothy S. Nelson" <wayland wayland id au>]

On Wed, 8 Dec 2010, Christian Persch wrote:

> 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.)

	Yes, I realise that.  I guess I just had my idea about XML, and then 
saw more xml, and thought "Oh, we could pull them both out".

> > 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.

	Good idea :).

> >  	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

	I'm a Perl coder :).

> 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.

	I have a list somewhere that I made years ago where I classified the 
Aisleriot games.

> (In addition to that static game data, the game chooser could also have
> access to the user's statistics for each game.)

	I was wondering about that in conjunction with high scores, but I like 
where this is going :).

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

	Fine by me.  I just figured there are probably already lots of XML 
processing libraries out there already.

> >  	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.

	I was thinking of the redeals.

	Ok, one of my motivations here (I should've mentioned this too) is 
that my preferred style of game is one that always allows you to complete, but 
penalises you points-wise for not doing it within a certain number of redeals, 
etc.  So I've been finding games that I like the idea of, and then increasing 
the number of redeals.  But the games I've modified (Gaps, Pileon, Backbone) 
have the redeal numbers hardcoded various places throughout the code.  I 
figured that if people thought there was a standard "redeals" variable, they 
might stop doing that :).  I still haven't got the hang of decreasing the 
score by 10 (or maybe it's conditionals I don't get), but I haven't tried very 
hard yet.

> > 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.)

	I'm not particularly convinced either way either -- just thought I'd 
mention it :).

> >  	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.

	I'm probably not the best UI designer.  But as a not-very-UI designer, 
I'd tend to approach it from an incremental point of view -- put out 
something, and improve as we go.

	:)


---------------------------------------------------------------------
| Name: Tim Nelson                 | Because the Creator is,        |
| E-mail: wayland wayland id au    | I am                           |
---------------------------------------------------------------------

----BEGIN GEEK CODE BLOCK----
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI++++ D G+ e++>++++ h! y-
-----END GEEK CODE BLOCK-----