[Scummvm-devel] Detection hints in the Add Game browser

[Travis Howell]

From: "Ori Avtalion" <oavtal at bezeqint.net>
> I noticed a slight usability problem in the "Add Game" dialog. I will
> outline it and offer a solution.
>
> Since the file list in the browser only displays directories, the actual
> clicking of the "Choose" button is done when nothing is on the screen.
> I think this disorients some users (for one example, see
> http://video.google.com/videoplay?docid=-1663029591101855863).

Seems like you posted the wrong link, I get a concert shown. Anyway I think 
our current method of locating a game's data files is already simple enough.

> One possible solution is show the files alongside the directories, but
> have them greyed-out. I understand this was done on the mac version and
> also caused a bit of confusion.

This would be no better, since it could cofuse users more, when deciding 
what exactly to select. Or a person can still attempt to select a file and 
complain when they are unable to.

> My solution is to have a message such as "This directory seems to
> contain a SCUMM game" displayed when a candidate directory is entered.
>
> How is this done?
> Each engine will implement an Engine_XXX_rootFilesList which will
> contain a list of filenames that identify the game engine (could be just
> one file).
>
> Whenever the game browser enters a directory, it will scan it against
> each engine's list. If an engine's list is found inside the dir, it will
> pop up the message. Note that the message does not mean "Choose" will
> actually detect anything. The actual, heavier Engine_XXX_detectGames
> function is not being executed (it may contain more logic: checking
> against md5's, checking file headers etc).

Could waste more time with file access and further complicate the game 
detection code of engines, for very little benefit. ScummVM can already 
waste too much time with file access when starting a game now, if there is a 
sub directory, with large amount of files.

From: "Max Horn" <max at quendi.de>
> The point is that only a tiny fraction of all SCUMM games have a
> detect file which is bigger than 64kb.
>
> Basically, on those games which have a single "big" data files (i.e.
> certain Mac versions of LEC games, and possibly NES/C64/etc. dumps --
> not sure about HE games) would require computation of new MD5
> checksums if we go for 128 kb. With 64kb, I think only COMI would be
> added to that list. With 32kb, there'd be some HE titles on the list,
> too.


Requring many SCUMM games to have their MD5 details updated would be a bad 
idea and best avoided, as it can take a long time to build up MD5 details 
again (As shown by changes to Simon game detection). In the case of HE 
games, reducing to 64K would require many games to be updated and reducing 
to 32K would require large amount of games to be updated.
So it would be best to only require the big data files of Macintosh versions 
to updated, if it must be changed, since they are all owned by people on 
development team as far as I know.


I think a much better idea, is just to improve the documentation and help 
options for ScummVM:
Adding a guide like 
http://www.unet.univie.ac.at/~a0200586/videogames/scummvm_tutorial/ to the 
future HTML documentation, so the process of adding games is even more 
clear.
Maybe adding a help button to each section of the GUI, with brief 
descriptions to explain that section. Keeping the text for help descriptions 
in a separate file would be best, for easy translation to other languages in 
the future.