Re: Kids Game Builder version 0.0.1

[Leon Brooks <leon@brooks.smileys.net>]

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...

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

No.

> Do we want ONE huge
> dataset?

Some programs will. An age-conscious dictionary would be good, for
example, for any word-based game. Having a SQL backend would immediately
cripple Windows and Mac ports for individual users, if this is a
problem. 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... (-:

> 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.

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.

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

Another useful starting point would be common I/O device and display
modules. 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.

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.

There are other configuration issues to consider, such as the situation
where you have two players on one screen. Did you know that X supports
more than one mouse? Two-handed rubber-banding is great fun! But you
could also have toddler using toddler-stick and older sister using mouse
(with an appropriate handicap, such as a three-second response lag or
artificial intoxication for the mouse) on the same game on the same
screen - or different screens. Do you run local copies of the game and
co-ordinate them, or pass data between X sessions to one program? 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.

With power comes responsibility. These are issues that it's basically
not possible to face under Windows! (-:
kidgames@smluc.org  -- To get off this list send "unsubscribe" in the
body of a message to majordomo@smluc.org