[kidsgames] Re: Kids Game Builder version 0.0.1

[Jeffery Douglas Waddell <jeff@smluc.org>]

Hello Leon,

On Tue, 28 Sep 1999, Leon Brooks wrote:

> Jeffery Douglas Waddell wrote:
> > I'm thinking that we want a simple database backend, perhaps mysql the gpl
> > version.
> 
> It's not hard to support practically any SQL with a simple interface
> layer; for example TWIG (http://www.screwdriver.net/twig/) have done
> this.
> 
> > Then that means we need to define the schema for the database.
> 
> Um, I think that there will be some stuff generally common to all
> applications (such as name and birth-date), but...
> 

Good point, where should we store the pupil information and what all
should we store.  On unix/linux systems, it makes since to use the user's
home directory, how ever this might make it difficult to have a statistics
generator that accesses ALL scores.  Of course we could have a group for
kidsgames to facilitate that.  Also these conventions are not available on
other platforms.  Personally I'm not interested in the other platforms,
but platform independence is still something we should take into
consideration.

> > Is this generic enough so that we can have ONE huge dataset of
> > problems from which our games can draw questions?
> 
> No.
> 

Hmmmm, I tend to agree that delivering one huge database would be bad, but
I can't help but think that having a web accessable database with as much
of the content as we can get into it as being the right way to go in the
long run.  Can we make a database that can easily be divided into several
smaller (and downloadable) subsections while still maintaining web
accessibility?  Can we also allow our users (parents/educator's/students)
to add content both locally and to the public repository?  These are
difficult questions.  Who's ready to start tackling them...

> > Do we want ONE huge
> > dataset?
> 
> Some programs will. An age-conscious dictionary would be good, for
> example, for any word-based game.

we have several gpl dictionaries, it may be nice to rate the word age
appropriateness for the words that are out there.  /usr/share/dict/words
and the dictd program come to mind.

> Having a SQL backend would immediately
> cripple Windows and Mac ports for individual users, if this is a
> problem.

why is this?  can't mysql (gpl version) run on those systems?

> A school would find it cheaper to buy a box and put
> Linux+(My|PostGre)SQL on it than to buy MS-SQL, so perhaps this is a
> good marketing ploy... (-:
> 

Sounds good to me :)

> > Anyway, we may also want a meta database that will associate different
> > problems together, this would facilitate such things as language
> > translation.  At least in a simplistic sense, it would be easy to map the
> > Problem Object for "easy" in English to the problem object "facil" in
> > Spanish.
> 
> Ummm, i18n should be handled as much as possible by existing tools,
> methinks.
> 

Absolutely.  I'm not an i18n expert, do we have any on list that would
like to tackle the technical issues involved in this?

> As a separate issue, there would be no point in making a scrabble
> program's interface Esperanto-aware if we only had English and Japanese
> dictionaries available, but if the dictionaries were there, word games
> could be quickly figured out even if the interface labels were Swahili.
> 

As I said I'm PRIMARILY focused on English, that does not proclude ANY
OTHER language, and I will help where I can (hablo espanol).

> > Anyway, there's a quick brain dump.
> 
> I think the basic problem here is that the possible variety of useful
> educational tools is very great.

This is true, almost infinite you might say...

> Your database could serve word games
> quite well, and reflex/coordination trainers (think of a modified
> version of Tux-AQFH) only en-passant.
> 

The tux en-passant thing did not register with me, can you elaborate on
that as to what you mean?  Keep in mind tux-aqfh has not worked for me
yet.

> Another useful starting point would be common I/O device and display
> modules.

That would be the point of the kids game developer library that we haven't
really even discussed yet....

> One issue which may exceed the scope of this list is that sound
> does not at present follow the X server as the keyboard and mouse do -
> which it should, or at least should be capable of doing. Too much
> MS-think amongst the sound driver developers.
> 

I tend to agree with you there, I wonder how hard it would be to bolt
generic sound onto X, just like joystick and table modules are bolted on?
There is the enlightenment sound daemon which might be the way to go, but
I'm not sure how that will work yet.  It seems important that we must be
very careful to have the sound content be on par with the video/graphic
and text content if at all possible, even if we don't know how that data
will be delivered yet.

> Anyway, some commonality of interface and input-device would be useful.
> The toddler-compatible joystick device that I proposed in an earlier
> message, for example, can be a pretend mouse in most situations, but
> there are some in which it would work better if treated specially.
> 

At the same time we can't expect our user's to automatically replace their
hardware with another interface.  I don't mind designing the hardware and
gpling the results and letting things take their course but locking into
that hardware would I think be a mistake.  We can certainly have baseline
hardware requirements, though.

> There are other configuration issues to consider, such as the situation
> where you have two players on one screen.

That could be really fun.

> Did you know that X supports
> more than one mouse?

Yep, and tablets and joysticks and anything else we can come up with a x
module or kernel driver for ;)

> Two-handed rubber-banding is great fun!

I can't even do it one handed....

> But you
> could also have toddler using toddler-stick and older sister using mouse
> (with an appropriate handicap,

You can even have them logged into there own linux accounts when doing
that by allowing attachments such as what x2x allows.

> such as a three-second response lag or
> artificial intoxication for the mouse) on the same game on the same
> screen - or different screens.

Sounds like a really cool idea.

> Do you run local copies of the game and
> co-ordinate them, or pass data between X sessions to one program?

I think the X protocol and corba (ala gnome) come in here.

> A
> consistent way of configuring for this kind of thing would be good, so
> it could be done simply, and more or less once only.
> 

hmmmm, configuration file in the home directory, with the necessaries
being put in with a hopefully simple little gui/console configuration app.


> With power comes responsibility.

true enough.

> These are issues that it's basically
> not possible to face under Windows! (-:

yep.

Thanks for your input

Sincerely,

Jeff Waddell
jeff@smluc.org

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