Biota.org
ALES Team Interview

John P. Daigle (Larry Eisenstein not photographed)

ALES Pages

ALES Wiki

ALESimulator on SourceForge

[John] Well, first, let my thank biota.org for taking an interest in our project, and offering us an opportunity to share it with the Alife community. We're honored.

[John] I've always had sort of a passing interest in artificial intelligence and artificial life, as long as I can remember being interested in anything. But I didn't start writing computer programs until about three years ago. So there is about 25 years of philosophy behind A.L.E.S., but not a lot of practical experience.

[Larry] It really started our as a Software Engineering project, but after seeing some of the results, and viewing some other's works, I've realized there is so much more that can be done. Its more of a learning process for me.

For those not familiar with ALESimulator, can you please give some background to the development? What is the development's link to Georgia State University?

[John] The brief description is that A.L.E.S. simulates the interactions between single celled organisms (creatures) in a drop of water. So the user can add more nutrients to the water to help the plants grow, or alter the alkalinity of the water and so forth. Its a tiny ecosystem of interacting software objects.

[John] ALEsimulator started as a graduate project in software engineering. So there is almost as much documentation as there is code, and we have a lot of UML. And one thing I learned is that no matter how much you try to fight it, in the end, your lead developer has to drink a lot of Mountain Dew and just write the thing, which is what happened with A.L.E.S. So all the documentation and UML describes a system that is similar to, but not identical with, A.L.E.S.

[John] That development team, myself, Larry Eisenstein, Michael Balum, and Edward Bulwinkel, are all Georgia State University students. There is some connection to Dr. Xiaolin Hu's research in artificial robot crawfish. But this is primarily a student project, and now, an independent project.

[Larry] The development was really rushed on this project. Due to all of the members working and finishing college at the same time, it was hard to coordinate our activities. Its really a simple, Object-Oriented design. This worked really well for us, since we were really trying to model real-life objects. Having a main ''creature'' class, then just subclassing from that. We used Java 1.4 as the language, mainly for the portability and it was more suited for future Internet integration.

The development is defined in a Wiki document. What properties of Wiki documentation lent themselves to defining the Simulator in Wiki? Have you had any feedback from users or other developers on the benefits and pitfalls of Wiki for this kind of information?

[John] Even though all the developers were taking the same class and live in the same city, it was almost impossible for us to get together in the same room at the same time outside of class. GSU is a commuter school, no one actually lives near campus and everyone has a full time job, families, and so forth. So the wiki allowed us to work together separately on a single document from anywhere, hyperlink to other sites, converse in lag time, write and share drafts... it was an unbelievably useful tool. The MediaWiki software is very good.

[Larry] The Wiki was probably the best way for us to collaborate. I had never worked with a Wiki before, but it allowed us to easily communicate and put our work together. Any of us could work on the project at any time and everyone would be able to see the changes. This helped also when I wanted to work on the documentation and I did not have my laptop readily available.

[John] We had some issues. It would be nice to take JavaDoc to the wiki more easily, my hosting service doesn't have the best bandwidth on earth, and some developers had trouble learning wiki markup. And there were some inevitable spats in terms of editing as well! But my experience was very positive, and I would recommend this approach to anyone.

[John] Another piece of software we used was dotproject, which is an open source project management tool. We used this to distribute specific tasks and set development goals. It also has a file server with versioning built in, so we could check UML and code in and out. So we used that originally instead of sourceforge.

You talk about the Sims and SimCity in the ALES documentation. How important was this software and what did you want to do differently with ALES?

[John] When I started trying to envision ALES, the only other simulations I was really aware of were the Sims series of games, SimCity, SimEarth. I used to play with SimAnts as well. But really, those systems are huge, and beyond being inspirational in terms of what can be done, they weren't important in terms of design and concept.

[Larry] SimCity was really used to help us define a market space, but the influence itself, in my opinion, was not that strong. The main thing we got from it, was ideas on interface. How do users expect to interact with a simulation? Building on that shared knowledge would be helpful.

[John] ALES is a very small simulation, but one thing I want it to have that many other simulations don't have is the ability to add your own creatures to the simulation, user ability to enrich the environment. We don't have that yet, but there are some ideas on the table about how to accomplish it. Ultimately, I may try to implement an AlesML to handle that.

The documentation contains a lot of analysis about potential user interactions with ALES. How important is the micro user interaction (icon/environment feedback) versus the general use patterns (how frequently the user runs ALES, how they load and save the environments, how they share the environment with others)?

[John] One thing I was very concerned with was saving files. The output files are human readable, you can edit them and open them with the simulator to see how the new conditions work. We want to build good user interaction into the system as well, just so that the user can zoom in on a particular area or get statistical output on a critter or species. That is definitely a design goal.

[John] But the most important thing, I think, is the richness of the environment itself. If it acts like life, it will be interesting, and if it doesn't, it will be boring. But the user only knows if it acts like life if they can really see the interactions, so I think that system feedback is very important.

[Larry] Right now the project is in very early development, so these interactions are not well defined (or developed). In the future, I would like to see more of this. The simulation is now super-interactive now, but as we fine tune the interactions and other classes, this will need to become more of a focus.

Do you see ALES moving from the water droplet to the ocean? Is there an expansion possibility built into the Simulator?

[Larry] We'd like to see expansions in the future, but I haven't really considered expanding the scope in that way. You can really do the same things in a drop of water as you can in an ocean (just on a much smaller scale). The thing I could see that lending itself to would be like a ''network'' of water drops. That would be kind of cool and would eventually form an ocean.

[John] I would like to allow non-coders to create new species, and to allow any coder to create new attributes for species. I would like ALES to model the systems that the user is interested in modeling, acting more like a platform for making simulations than a simulator.

My goals for the next few months are to

1: Debug the system for wider use.

2: Add mechanisms for adaptation and variation over many generations.

3: Investigate and if possible implement simpler tools for adding new species to the simulator.

4: Increase the complexity of the environment.

5: Investigate means of encoding the ''genetics'' of each species in order to allow for genetic behaviors such as frame shifting or point mutation.

[John] Ultimately, I'd like to take A.L.E.S. into the bloodstream, and try to build something like an immune system from this agent based perspective.

What is your sense of the broader Alife community?

[John] Well, I'm pretty new to it. Which is odd, because I'm fascinated by Alife, so first, I would say the community has a very low profile. But looking at the work that people are doing, I think there are a lot of great ideas and a lot of very sophisticated projects.

[John] I guess my overall impression is that there are a lot of brilliant minds and not a lot of organization, but on the other hand, it isn't clear that there should be a lot of organization.

What more would you like to see with the Alife community?

[John] I'd like to see an RSS feed for biota and an aggregate blog as well--something like Panda's thumb. It seems silly, probably, to focus on that. But I think a community needs a community newspaper, and RSS is the best way to accomplish that.

Many thanks for the opportunity to talk with you.

[John] Thank you for the opportunity to talk!

[Larry] Thank you Tom for your time.

The interview was taken by Biota.org's Tom Barbalet via email on March 1st, 2006.