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

Re: [kidsgames] word familiarity



Hello Paul,

On Thu, 17 Feb 2000, Paul Kienzle wrote:

-->Date: Thu, 17 Feb 2000 19:13:40 +0000 (GMT)
-->From: Paul Kienzle <pkienzle@kienzle.powernet.co.uk>
-->Reply-To: kidsgames@smluc.org
-->To: kidsgames@smluc.org
-->Subject: Re: [kidsgames] word familiarity
-->
-->>The (kindof) answer to that is to have one person read the *entire*
-->>dictionary (just the root words at least) into a BIG sound file -
-->>and have people who want to contribute to the database cut out the
-->>word they want from that big file (or set of 26 big files).  I
-->>wonder how long it would take to read the dictionary like that?
-->>20,000 words - two seconds each?  Eleven hours.  I guess that's
-->>do-able if you have enough disk space.  One person could do it in
-->>a couple of weeks at one or two hours a night.
-->>
-->>Oh - but wait.  20,000 words is only the start of it.  My dictionary
-->>has "JUMP" - but not "JUMPED", "JUMPING" or "JUMPS".
-->>
-->><sigh>
-->
-->You really do not want to paste word tokens together to synthesize
-->sentences.  The prosody will be totally wrong, and the result will
-->be hopelessly unintelligible.  A bad synthesizer will do as well.
-->

I tend to agree with you even if I don't know what prosody means.


-->Furthermore, flashing up the picture and then reading the word does
-->not make for a very exciting game.  It's better if you mix things up a
-->little bit.  For lletters, I recorded sentences like "T is for train;
-->tiger starts with T; that's a pretty angel fish."  And I'm in good
-->company.  We have a very compact version of Dr. Suess's ABC's wherein
-->each page has the form "Big X, little X, what begins with X? ...",
-->which I found too tedious to read to my son --- not at all like the
-->rest of Dr. Suess.  Then I chanced upon an original full-sized version,
-->and it was so much better.  Here, he breaks up the monotony by changing
-->the structure of the verse on some of the pages.  I really don't see
-->how a database can capture this sort of creativity.
-->

No I doubt the database would have that creativity in it, but how it is
used by a program could certainly be creative.  One of the huge things I
notice in games that have sound (even good phrases) is that there is a
very finite (between 1 and 10) number of these phrases that is repeated ad
naseum....  Normal humans will say something the same way maybe twice to a
child and then change it around 'cause it drives people nuts to hear an
exact quote over and over again. I don't know why this is, but it is
certainly true with me.  This leads one to the notion an AI generating
"natural" speech.  THAT is a breathtaking huge task.

-->>
-->>> -->So, even downscaling to words to a childs vocabulary, this is a
-->>> -->HUGE undertaking.
-->>> 
-->>> And the benefits, I hope, more than make up for it.  They say open source
-->>> ("freed" software) allows the developer's to "do it right".  So the
-->>> question is -- "Is building this database the RIGHT way to do it?"  If so
-->>> then I think we attempt it...  Future generations can fix it on the fly...
-->>> It is theirs TOO.
-->>
-->>Yes - this is an incredibly good idea - it would be a VERY useful
-->>resource - and doing it RIGHT is good.  But we keep coming back to
-->>the amount of effort required.
-->
-->It still seems to me that the structure of the database should follow
-->from the demands of the games that are going to be using it.  Here are
-->my pet examples.  Can you add others?
-->
-->Linux Letters and Numbers:
-->   a word, a picture, a recording of an "interesting" phrase.  
-->   E.g., "cow", a picture of a cow in a field, "cow starts with C".
-->
-->Stickers:
-->   a word, a picture, a recording of the word, a "stamp" sound, and a
-->	"paint" sound
-->   E.g., "cow", a picture of a cow with transparent background, a
-->	recording of the word "cow", a recording of a cow mooing, and
-->	a loop recording of a field of cows which can be played back
-->	for the full duration of the paintbrush stroke.
-->

This is not a horribly bad idea, but I wonder how appropriate these
pictures will be accross applications.  It doesn't bother me to have
"application" specific data in the database, but I feel it will need some
type of labeling as such, and that part I'm a bit hazy on in what you
proprose above....

-- 
Jeff Waddell
jeff@smluc.org

Kids Games Project Coordinator
main website at http://smluc.org/SIA/kidsgames/


-
kidsgames@smluc.org  -- To get off this list send "unsubscribe" in the
body of a message to majordomo@smluc.org