[OLPC-Games] Activity API

[Ben Sawyer]

Hi Bruno,

Interesting stuff!

So I did some digging and there is an SDL_Pango library which sense  
PyGame is an SDL wrapper perhaps we can wrap this into it?

	http://sdlpango.sourceforge.net/

Not sure on your other comments from a technical standpoint so  
hopefully others will chime in.

Keep in mind that the Pygame stack is only one stack we're trying to  
make happen.  It is envisioned by many of us to identify multiple  
pathways and stacks that enable games to run on the XO.

To the extent we need  GTK/Cairo/etc. stack that isn't Pygame the  
goal is to define that and document it.

- Ben


On Apr 16, 2007, at 7:06 PM, Bruno Coudoin wrote:

>
> 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.
> _______________________________________________
> Games mailing list
> Games at laptop.org
> http://mailman.laptop.org/mailman/listinfo/games