[OLPC-Games] Activity API

[Bruno Coudoin]

Hi, I have some concern about pygame on the olpc. In fact, until know, I 
though activities should use GTK and the hippo canvas.

I understand pygame is more efficient to build games but it has also 
some drawbacks:
- We will have 2 different event loops for sugar and the activity, I 
though the main activity concept was about using a single event loop.
- Pygame doesn't use pango, last time I checked there was not support 
for shaping in arabic for example (letter shape depends on the previous 
one).
- Layout management, usually games are made for a predefined window 
size, I though hippo canvas could help in building a dynamic game layout.
- cairo and pygame integration. I know there is a good support of cairo 
in GTK, what about pygame.
- Mixing GTK widgets and pygame. It's sometimes useful to use regular 
widget in a game, mostly, we sometime use text entries (using all the 
different character input GTK support, and the assisted technology) In 
the HIG, it's stated that this is important for the OLPC, does pygame 
offer a good support for that?

We, in the GCompris project have build and designed over the year a 
multi activity application that includes about 100 different activities.

To some extend, GCompris core and Sugar play the same role and looks 
very similar in their design. We also support python and can start 
python based activities. Based on our 7 years experience in GCompris, 
over the year we have build an API that is far from perfect but I 
suggest to use it as a draft to implement in sugar these feature. If we 
don't create this API that all activity can use, it will be very hard to 
make the activities behave consistently and to maintain them over the years.

To give you an example of what's needed, each activity may have several 
levels, how do we represent the level to the user, if each activity 
implement this, it will be inconsistent.

More important, each activity should provide a translated help, how do 
we store and display it, it must be set in a common API.

On our wiki, we have documented all the core services we have set in 
common in GCompris:
http://gcompris.net/wiki/index.php/GCompris_internals#Core_services

I don't want to say this can be used 'as is' in sugar, anyway, this code 
is in C in GCompris so forget the reuse, but anyway, it can be used as a 
draft to define a sugar activity API.

Is there a plan to go this way, does that makes sense?

Bruno.