Re: Aisleriot ideas

On Wed, 8 Dec 2010, Christian Persch wrote:


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

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:


 	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                           |

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-

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]