Garden Activity

Introduction

This document describes in detail my idea for a virtual garden, to be deployed int the XO Laptop as a Sugar activity.

This virtual garden has three main goals:

• To be a rich and interesting tool for learning about Mendelian genetics,
• To provide rich support for extensions an modifications through a plugin architecture and
• To generate an understandable and simple body of code, that might be used by future XO developers as an example of a reasonably complex application.

The rest of the document is laid out as follows:

Section 1 : The Garden Activity, is a tour through the idea of the application, its interface and the way it will accomplish the first goal.

Section 2 : Technical Description, describes the technical aspects of the project

Section 3 : The Code, is about the design principles that the project's code will follow, in order to fulfill the second and third goals. It describes the plugin architecture, and proposes a general design for the code.

Section 4 : Schedule, gives a tentative schedule for the completion of the different stages of the project.

Section 1 : The Garden Activity

The garden Activity will be a virtual garden, where the users will create artificial plants and mate them to enhance their characteristics, gaining insight into the process of inheritance and the mechanisms of Mendelian Genetics.

The interface will be divided in three sections: The Garden, the Species Design Laboratory and the Seeds Room.

In The Garden, the user can arrange the plants and monitor the progress of her experiments, as well as pick individuals for their reproduction. When two individuals are picked for reproduction, the resulting seed is stored in the Seeds Room. Although the "gardening" aspects of a virtual garden are not a main concern at this stage of the project, It might be interesting to add some basic capabilities, with the chance to improve them in future versions: things like watering, fertilizing the soil, amount of sunlight, etc.

Apparently, the gardening stuff has encountered a warm reception, so I think I'll expand on that. As suggested by Homunq, each plant will have a health level, and an age. I'm still thinking of the factors that will influence the health, and the rate of change of the age... ¿perhaps variable?. Weed species could also be interesting.

The Species Design Laboratory will be the place where new plant species can be designed. It will provide controls for adjusting the parameters of the underlying L-System and the Superformula, but conveniently abstracted under intuitive plant parameters, like amount of flowers, weed-like or tree-like, shape and color of the flower's petals, etc. Once the new species are created, they are stored as "templates" for generating new seeds.

The Seeds Room will be where the birth of new individuals takes place. From here the user can either select the previously generated templates to create new seeds, or use one of the previously stored ones. When looking at the seeds, the program will show information about their genealogy, and notes attached to them during their creation.

For pedagogical purposes, the user will only be able to create a limited number of species, tweaking a restricted set of parameters. In order to gain more power for the design of the flowers, the user should enter "challenge mode". There, it will be asked to perform experiments, and answer questions about them: They will gradually introduce her to the mechanisms of inheritance and basic genetics, and help her discover by herself the rules behind it.

The field of genetics is huge, and there are lots of little things that would add complexity and beauty to the plants. A compromise will have to be achieved between complexity and understandability; but I think I can get a little bit more in the program than just mendelian genetics.

As for sharing functions, a plugin will be developed to allow the user to share her plant's seeds with other XO Laptops. Additionally, the idea of a "school garden", stored in the central server and viewable in each Laptop seems very interesting, It might be implemented if there is enough time.

Section 2 : Technical description

L-Systems were conceived by Aristide Lindenmayer as a mathematical theory of plant development. Originally, it didn't consider the geometry of plants, but rather the relationships between their cells. However, several geometric interpretations of L-systems have been proposed: In "The Algorithmic Beauty of plants" a "Turtle Geometry" approach is used, and so will our virtual garden use too.

A tree generated by an L-system. The turtle interpreter is still ugly, but you get the idea.

A complete description of LSystems lies beyond the scope of this document; the reader is advised to go to the Prusinkiewicz and Lindenmayer's book for that. For now it is enough to say that they provide the means to describe the general structure of the plant, while leaving room to enough random elments as to generate "individuals" of each species.

On the other hand, the Superformula is a Generalization of the sphere that can represent many natural shapes. It will be used to describe the shapes of flowers; the color and size of the flowers will vary between individuals.

A flower created by superimposing various instances of the superfomula

Once species are defined, we need a list of values to "fill-in the blanks" in the species template. We will come to it later, but for now, supposing we already have the values, we can proceed to the graphical representation of the plant.

The first step is to create the flower. For this, Cairo paths will be created by joining points in the perimeter of each petal layer. They will be colored and arranged as specified by the template, and drawn into a Cairo surface.

After creating the flowers, a "turtle" (as in turtle graphics) will interpret the description of the individual: the chain of instructions generated by the rewriting process of the L-System. It will include information as to where should the flowers be placed; copies of the flower surface will be placed at those locations. Once the drawing is finished, we have a picture of the individual that can be used wherever we need.

The template that describes a plant species is not a complete description of an individual plant; it leaves some blanks that can be randomly filled to create individuals. When we have to draw a particular member of the species, this values should be randomly generated; we will call "chromosome" to this string of random values, that can appropriately complement the species template to draw individuals. However, the chromosome is not the individual itself, but a representation of it's tendency to have certain characteristics. Although two interpretations of the same chromosome will be very similar, there are certain characteristics that might vary, specially when the individual genes represent probabilities. The only univocal representation of a particular individual would be the final string generated by the L-system, and the accurate description of it's flowers, which shall be stored for each plant, and that can be used to exactly reconstruct the plant's picture.

However, although they are not an exact description of each individual, our chromosomes are suitable vehicles for inheritance. The mating of two chromosomes to create new individuals will be very much like the process described by classical genetics: When new species are created, the program will randomly choose criteria for discriminating between dominant and recessive genes; those choices will be part of the species template, and used whenever two individuals mate. When that occurs, the program will go gene by gene, deciding which one will manifest in the individual, and which copies shall be stored int he genome; the result will be roughly the same as Mendel's Laws would predict.

The technologies that will be used for the implementation of the project are pretty much the standard ones: Python, PyGTK, Glade and Cairo. A Cairo-based GTK widget will be created to allow te "on-line" design of the flowers. As for the rest of th application, it'll try to use standard components as much as possible, while drawing directly with Cairo for the more graphic parts of the Interface.

Section 3 : The Code

The code for the project ought to be as clear and as "hackable" as possible. To achieve that, I'll work in advance in the general structure of the program. I plan to have a clear definition of the classes that should be written before summer starts, and then improve on that.

Please check back for updates on that area.

On the other hand, I'll include an extensive plugin architecture; I'll try to expose almost every aspect of the software through an API, allowing further work on the software to be done without modifying the core code, making distribution of improvements much more easy. Since I plan to keep working in the project after the GSoC, I'm pretty interested in easing the updating and improvement process.

Section 4 : Schedule

• Google Calendar [1]

Please go to May in the Calendar for the beginning of activities. I plan to dedicate August to improvements, tweaks and bug fixes.