Research on the Memory game

[todd rme]

On Thu, Aug 25, 2011 at 5:51 PM, Anne-Marie Mahfouf
<annemarie.mahfouf at free.fr> wrote:
> Hi!
>
> Following Marco's mail about the Memory game, I wrote a small doc to assess
> what we currently have and hopefully to trigger a discussion and the best
> design possible as a conclusion for such a game.
>
> In this doc, I define what a Memory game is. I present the MemoryGame and
> KMemory with screenshots, I extract positive and negative points (subjective
> as that only reflects my view).
> Then I list a few points for an implementation and that's what should be
> discussed and defined here.
>
> The doc is in .odt (I can put it on my scratch pad), the pdf is attached.
> Should the conclusions we agree on be on a wiki? Community or techbase?
>
> Best regards,
>
> Anne-Marie

Great overview!  A few suggestions:

1. You say for single-player the score should be based on time.
Alternatively, or in addition, I think a score based on the number of
misses or total number of attempts might be good.  So making less
mistakes or trying less pairs of cards is considered a better score.
In my opinion, if the goal is to teach hand-eye coordination, then
time makes sense.  If the goal is to teach memory, then either the
number of mistakes or total number of turns makes sense.  I think
mistakes is better because it makes it easier to compare across board
sizes, since a larger board will always take more turns even if you do
it perfectly.

2. In terms of programming, QML seems ideally-suited to this.  It has
a built-in mechanism for objects with "front" and "back" pictures
(like cards), and has a built-in, very easy animation for "flipping"
the picture over to see the back.

3. If you go the QML route, I think rather than having the cards just
disappear, the pair could fly to either a pile or score counter or
something.  This would give good visual feedback, and I think this
would help younger players understand the significance of finding a
pair and the significance of the score counter.  Animations for
dealing the cards out would also be fairly easy.

4. In terms of layout, I think that "easy", "medium", and "hard" is
good, but for "custom", rather than changing numbers, ideally it would
be something like the table creation interface in
OpenOffice/LibreOffice writer, were you have a large grid of boxes.
You then click one box and drag diagonally until you have the size you
want.  Alternatively you could use a rubber-band selector like in a
file manager.

5. I am not clear on the point of showing the matched pairs.  I think
it would be better if there was just a raw pairs counter box, or a
stack or pile of face-down "cards" with the number of pairs on top of
it.  In fact remembering what matched pairs have already been done is
probably part of the point, so showing them I think would be
counter-productive.

6. We need to think about how the theme selector should be designed.
Making this easy and intuitive for kids is not going to be easy.

7. How do you handle the number of pictures?  Is there a minimum
number a theme needs?  What if there aren't enough?  Would there be
duplicates?  Do we want it to be possible to intentionally set
duplicates?

8. About the text and number-based versions others have discussed,
this probably means that the theme format should support raw text
input.

About game versions, we should probably think about all the
combinations we want:

Matching critera:
1. Identical: The two things you match have to be exactly the same.
This is the "classic" version, and can be handled automatically by the
program (it just picks two of everything)
2. Non-identical: the two things you match need to be different.
Examples include matching baby and adult versions of an animal, an
animal with its name or sound, Bina's math example, and so on.  The
computer cannot know this, so the theme would need to specify what
cards match what other cards.

I think the best way to handle 2 would be to have categories of cards
in a theme, with each category having one card from the other
categories that it would match.  Themes can have as many categories as
it wants (including just one).  So for instance a theme could have the
following categories: "baby animals", "adult animals", "animal food",
"animal calls", "animal names", and "first letter of animal names".
With every card from each category being linked to a card from the
other category (if you want to make it simple, just have an ordered
list of cards, with the nth card from each list matching the nth card
from every other list).  The program would then automatically pull out
every possible combination, and list them.  The player wouldn't need
to know that the games all came from the same original file, all
themes would be combined into a flat list of games.

What sorts of cards should be allowed? My suggestions

1. Image
2. Text (these would just be unicode text, the text would be rendered
by the program)
3. Sound (perhaps in this case the card would vibrate instead of flipping?)
4. Video

The advantage of using unicode text is that several things could be
done automatically:

Match text with different case (capital, small, title, etc)
Match text with different fonts
Numbers or math would just be a special case of text

-Todd