Re: Gnome-sudoku - features, menus and memory usage

["Thomas Mills Hinkle" <tmhinkle gmail com>]

On 5/19/07, Thomas Andersen <phomes gmail com> wrote:

1) Save/resume
The save/resume feature is the main offender regarding bugreports
(File corruption, full disks, confusion caused by the feature). I've
found that I never use this feature. A sudoku is something you solve
here and now, just like solitaire. You need to have the numbers fresh
in you memory.
Saving was also once specifically stated as unwanted in gnome-games. I
Don't know the current opinion on this thou.
Seeing as this is the cause of many crasher bugs and not really an
essential feature for the game I suggest to simply remove it.

Hmm -- I agree the complexity of the save/resume could be reduced, but I for one use the basic feature of "keep my sudoku where it was" all the time. I like closing a half-finished puzzle and opening it to finish days later.

Perhaps something simple such as: allow saving a partially completed puzzle to a file that can be opened later (i.e. allow save/open to work with the traditional metaphor). Otherwise, just keep the current puzzle until solved or the player hits "new puzzle" ( i.e. don't make puzzles arbitrarily end when you close the application). I'd actually aim to have it save at some interval rather than on close so that e.g. crashing the computer doesn't lose your puzzle.

I agree that the resume-old-game/open dialog is needlessly complex. Although I liked the concept when I created it, I've never really used it as I intended. I realize now I would much rather have a simple file-based save/open so that I could i.e. save and name a particularly interesting game so that my wife could play it later. This also would allow e-mailing puzzles to friends, etc., so it would both A) add a new "feature" at very little cost and B) remove much complexity from the old implementation.

2) Highscores
Gnome-sudoku uses it's own highscore system instead of the one
supplied by gnome-games. One reason is that you can replay a sudoku
solved earlier. More than saving just the score it also saves
statistics like: fills used, hints, date, unfillable squares, etc. I
don't really think this is useful information later.
I suggest to port to gnome-games highscore code using the categories
Easy, Medium, Hard, Very Hard and scoring based on time.

The statistics are largely saved so that if the scoring algorithm changes, the scores change with it :) That said, I agree scores don't need to be complicated, and I would be amenable to cutting high scores altogether (though I suppose it's possible some users have gotten attached to them)

3) Fill / Fill all
Currently you can have the computer fill out a specific (or all)
numbers on the board. This completely ruins the gameplay imho and
allows cheating in the highscore list. I suggest to replace both
"Fill" and "Fill all" with "Give up" that would end the game and show
you the solved puzzle.

I use "fill" all the time -- when there are 8 or 9 numbers in a box filled, I don't mind letting the computer fill in the last for me without my having to count through myself. I don't care much about "Fill all", though.

4) Puzzle generator / storing puzzles
Currently puzzles are stored in a file and loaded into memory at
startup. This leads to high memory use and bugs regarding corrupted
files. A puzzle generator is provided in the game but the puzzle must
be saved to allow replay/save/resume. Without those features it would
be possible to generate needed puzzles on the fly when a new game is
started.

It is not possible to generate needed puzzles on the fly with the current algorithm. Specifically, it takes quite a while to generate difficult puzzles. For this reason, the game likes to generate puzzles in the background while you play. If someone implements a super fast generator that can  do difficult puzzles super-quickly, that would be great, but I'm not sure how feasible that is.

Given the current generator, I think we need some variant of the current system to provide a range of puzzles. Perhaps it would be better to move to a file-based system -- i.e. generate puzzles and save them in an organized directory-structure of generated puzzles (this could potentially be system-wide rather than user-independent). This way, GNOME Sudoku wouldn't have to load all puzzles ever generated into memory -- rather, it would just have to load some useful info (such as how many puzzles of each difficulty it has that the player hasn't yet played) and then do any necessary puzzle-generation based on that info.

5) The "New" dialog
Picking a difficulty on a slider is, well, difficult. Why not do like
the rest of the games and have a menu item "Difficulty" (easy, medium,
hard, very hard). Pressing "New" would immediately start a new game of
the selected difficulty.

About the slider -- I've heard this before, so there must be some truth to it, but I can't see why it is harder to move a slider on a scale than it is to click one of 4 radio buttons. Also, the slider more accurately models difficulty as a continuous rather than a discrete property.

As to the menu item -- if I understand, you're proposing that there be a setting of the difficulty you want, and then every time you click new you get a puzzle of that difficulty, right? This seems less transparent to me than letting the user select each game (and by default nudging the difficulty up each time they play), which is the current behaviour. I'd imagine some users might never figure out how to choose how difficult the game is if they had to go to a menu to do it.

6) "Puzzle Statistics" dialog
Some of the provided information is already present in the status
bar(level# and difficulty). Is the rest really of any interest? Could
it be moved in a nice way the status bar as well?

I think statistics are actually of interest and could become more interesting if the game learns some of the more complex solving algorithms.

7) Add a preferences dialog
Highlight, always show hint, tracker enable/disable, "warn about
unfillable squares" would fit nicely in a preferences dialog.

Agreed -- although I generally don't like preferences dialogs, you're right that the menus/toolbars are too full, and this would be a simple way to take care of it. We could also move things like "Generate puzzles as you play" to preferences.

Removing features is never popular but I believe in cutting to the
bone and only keeping the essential features. Doing these things would
make gnome-sudoku look and behave a lot more like the rest of the
games in gnome-games.

Thanks for taking the time to think carefully about this. Apologies in advance if I sound at all defensive -- as the author, I know I'm unlikely to represent a neutral point-of-view :)

Tom Hinkle