Welcome, O weary traveller, to the home of Project Ouroborus!

This is the homepage of our budding artificial life (AL) project. You can find anything Ourborus-related here, from architecture to zip files, including history, some theory, downloads, how to contact the developers and so on.

For the sake of readability, this whole website is being restructured. The witty rants done in archaic style and full of obscure alchemical references which originally comprised ALL of the documentation are still there, but italicized and indented so you can skip them entirely if you're not interested in this kind of nonsense.

Whether it was blind fate that bore you in her arms to this secluded confine of the Web, or the thirst for knowledge that drove your resolute pursuit, rest assured that you may now take your much-needed rest, and perhaps tarry among some searching souls who took upon them the daring quest of following the path of wisdom.

And for what its worth may be, we now share with you the brilliant pearl which we did find as we did exert ourselves on the path: that wisdom is not a thing which you obtain, but a work that you undertake, that it may grow and you may share.

Now choose you must; either to follow one of the links below to more information pertaining to our project, or else to bear with me still awhile as I tell you more about us and our history.

And in this same page:

Overview and History of Project Ouroborus

Project Ouroborus started life early in the 21st century under the name of Mundito. It was harboured, as it still is, by a Mexican public college: UPN. Its original concept was to develop a general artificial life application suitable for running across an extended network of computers. The details are as follows:

The foundation of the system is a cellular automaton grid. You can learn more about cellular automata in the Resources area, but in very gross terms, you can think of this grid as a chessboard where each square changes its state depending on the state of its neighbours. Now, there are a lot of variables to take into account here, including the size and shape of the neighbourhoods, and the general form and dimensionality of the chessboard. Then, we also have the automaton iteration rule, in other words the exact way in which each state transition is calculated, in terms of a square's neighbours. We would like our application to be as general as possible, in the sense that it should allow the greatest diversity of choice in all these variables. This chessboard constitutes the background, or 'terrain', on which life will manifest.

Then, on top of this foundation, we have independent agents, that is virtual entities or 'creatures' which are able to move on the chessboard, and are capable of interacting with their environment, which includes not only the 'terrain', but other 'creatures' as well.

From its conception, it was observed that the project lent itself well to object-oriented programming, and Python was picked initially as our language of choice for implementation, due to its open-source, high-level nature.

cage, a library written in Python by Erik Max Francis, was found to provide much of the functionality required by our conceptual needs, and so it was adopted as our cellular automata engine. You may find out more about cage in the Resources area.

When thought was eventually given to the matter of implementation, it was decided that the project would follow a mix of two patterns, already used in gaming applications. One of them is the View-Model-Controller pattern which splits the whole system into three interdependant components. These components would communicate following another pattern: the Event-Listener pattern. Once again, you may read more about these patterns at our Resources area.

The Model had been accounted for, thanks to the cage engine. We decided to tackle the View using a widely used Python library, specially popular among game developers: Pygame. As for the Controller, we sought to follow the revered tradition of XML, and hence chose the CAML dialect, intended precisely for communicating cellular automata data. There is more about CAML in our Resources area.

We had gathered together all these remarkable components and it only remained to put them all together and somehow make them work.

This did not proceed smoothly.

So, after a series of mishaps, twists of fate and unexpected nuances which it is pointless to delve into, we reached the present state of evolution of Ouroborus. The project has now expanded into a loosely knit structure which covers several lines of development, as follows:

Lines of Development

Open Lines of Development

  1. Ouroborus Proper. This line follows the original concept as described above. A release is expected shortly. For more information, click here. (under construction)
  2. Biology Education. A practical application of Ouroborus as a tool for teaching biology to secondary school human young. See the associated HTML worksheet (in Spanish). More to come soon!
  3. Birdcage. This is a reimplementation of the cellular automata engine cage in the Python extension language Pyrex. (To learn more about Pyrex visit our Resources area). This optimisation of our engine currently ran approximately 100 times faster than the original version in Python when the first optimisation was completed. It has probably become slower since then as new features and abstraction layers have been added. Look for the latest release in our Downloads section. Birdcage is currently a part of the Ouroborus Proper line of development, however it is a standalone project in its own right. Some documents, straight from the developers keyboard, can be found here.
  4. CAML Parser.. The idea behind this line of development was to hand over control of the model to the XML parser, as well as to facilitate the creation and exchange of full models, or at least CA backgrounds. It could have eventually superseded birdcage as the cellular automata engine for the overall project. The release of the CAML Parser was indefinitely postponed when David left the project. As we further refine Birdcage, it seems more and more unlikely. Still, if a strong XML coder wanted to take it on, it could still make sense as a data exchange format, or even as an automated Birdcage model code generator. The original CAML project is clearly abandoned as well.
  5. Cage Cpp. Vian has created a Cage-like library in C++ in an effort to further optimise our model. He is currently porting the newest version of this library to Linux.

Closed Lines of Development

  1. Yogiserver. An XML-RPC server written in Python, providing a library of functions for storing strings on line. It may be used as a repository of randomly chasing sutras or whatever. This is basically a toy which came into being with no particular purpose, and is currently unrelated to the greater scheme of things. Sill, for those interested, click here. (under construction)
  2. Yogiclient. A python client for Yogiserver. Clients in other languages are more than welcome. Click here. (under construction)

Members of Project Ouroborus

The developers currently working in one or more of the lines of development are currently four, as four are the elements which together combine to produce all things under the Sun and Moon, as explained by the philosophers of yore: