Percy's Alife Project

Doesn't it, though!I didn't follow the reference to compression technology, but the part about tracking local min/max's and infering the value for other locations seems good.Density and conductivity could definitely be additional properties, and I agree about introducing the more complex properties later rather than sooner.I *have* thought about energy sources. I'm not sure at this point whether it needs to be part of the early universe (ie, the debugging phase), but it seems like a critical component of any self-sustaining universe. There have been a few others who have offered help, and it would be great if we had several people working on this. To keep it fun my inclination is just to keep discussing details and issues, and whenever anybody sees something they'd like to do they should just pipe up and say, "Hey, I'll do that part." I've been wanting to hook up a chatterbot to a thread here. Ever heard of Leo? Is your chatterbot better?--Percy

No argument from me.Thanks for the offer of help - I can use all I can get.As I said to Awinkisas, we'll just take an ad hoc approach to coding assignments and see what happens. We'll need a place to post code, but I don't have a good suggestion for how to do that other than posting it in this thread and having me add it to the local repository (when it exists). Maybe somebody knows of some free webware that addresses the needs of web-based code development teams?--Percy

Thanks! I better start a list. People who have offered assitance so far: --Percy

I'm not sure how much help I can be, but I'd love to lend a hand - I just sort of learned Java, and now I'm working my way through C. Eventually I'll get up to C++ and Visual C++. (I think I might have learned things the wrong way around.)I'd say you'd probably be looking at using Visual C++ and OpenGL for the 3D graphics stuff. Coding 3D graphics in Java would be a real headache.I checked around for web-based stuff for code teams, but most of it costs money - maybe someone else will have more luck. I'll be watching...The Rock Hound

How about Lifescape?------------------
Ia! Cthulhu fhtagn!

Some image compression algorithms average all the colors over a small area and then infer the gradient between adjacent areas when rendering. Smaller areas are used near regions where there are steep gradients i.e. near object edges. A 3D temperature gradient could be treated similarly but using a local max or min rather than averaging. I hadn't heard of Leo but I checked it out. It's amazing that very simple rules, compounded, can create complex results. If only it was somewhat self-aware (the holy-grail of AI programmers). My bot is more complex but it's only about 1/2 done right now. It can parse pharses and identify subjects and predicates. I'm working on the knowledge representation portion right now, which is orders of magnitude more difficult than parsing.But back to CellscapeHow do food objects get into cells?
Instead of logically separating food and waste objects, how about making them the same object, say a matter object. This way cells could potentially treat all matter as food. Each matter object could have an energy object bound to it and this would be the maximum amount of energy the cell could extract. The characteristics of the matter could define what cells can consume it. Cells in turn will emit matter objects that they have consumed after modifying its characteristics and removing some or all of the energy. Once a matter object has become depleted of energy it could potentially absorb some from the environment or remain inert.So many ideas ...

I don't know jack about "real" programming - I just tool around with Java - but No webpage found at provided URL: http://www.sourceforge.org seems like it be the place to look. For instance I searched for "code teams" and found something called TUTOS that would kind of seem like what you guys would want.Then again I haven't used it or anything. It's free, though (open source/GPL'd).

No, Irish not the wrong way round. Java offers a cleaner syntax and allows you to learn OO design without the complexities of C++.You may as well go straight to C++ and skip working with just C. Once you have the OO stuff down getting a bit of C++ wrapped around the C code isn't a big deal.That is my not so humble opinion anyway. I've only worked for a couple of years in both C++ and Java so I am not the world's greatest expert

Right - I was looking for something a bit more capable than Leo. Let me know when you've got something to look at. Okay, now I see the relationship. Current thinking is that they drift in through pores in the cell membrane. Pores are created whenever movement of the cell wall objects create non-adjacency. I'm expecting this behavior, creation of pores, to emerge. Cell wall objects that evolve motions that, as part of a coordinated effort with other cell wall objects, do a better job capturing food objects should compete better. This is behavior I've been taking a hard look at. The significant question is whether there should be one type of object that can take on different attributes, or whether there should be inherently different types of objects. If the former, then assuming attributes aren't fixed there is nothing to prevent a food object from changing into a waste object, or even a cell wall object or metabolic object.My current concept already assumes some of this type of behavior. For example, if a cell "dies" in that too many of its component objects have insufficent energy to execute their algorithems, then they simply follow the default drift algorithm and in effect become food.Ultimately I would like to achieve a design in which the properties of the objects emerge without ever having been anticipated by the designers. Not sure what you mean by "bound". I'm hoping for a conceptually clean design where objects feel like they have a physical manifestation. Depending upon the conceptualization, some of this disappears if objects can become bound to other objects as if they were properties or attributes.--Percy

Taken. Keep trying!--Percy

Hi Percy,I'm pleasantly surprised that you're in the exact same situation I'm in: somewhere in the process of reading Emergence. Nice little book, contains some profound insights.I'm still of the opinion you should give up 3D, and I'll back it up with some numbers. I'm certain you can do this yourself, but maybe you just haven't come around to doing it. It's revealing though.Let's assume a conservative value for the time it takes to calculate one complete cycle of your universe: say one second. This is tediously slow and you would probably want a faster pace, but let's just see what this means. Let's further assume that you've got an incredibly powerful computer, that can calculate the new life situation of one grid unit in a nanosecond, takes another nanosecond per unit to calculate its 3D situation and yet another nanosecond to calculate its 2D representation. This means that you can calculate the new situation of a third of a billion units in the time alotted for a complete cycle. In a 3D universe, this means a grid of less than 700 units per axis. Well now, that's not the very large universe you envisioned, is it? And it gets worse: in reality, your computer isn't nearly as fast as I assumed in this example, so the number of units on an axis is going to drop dramatically. If your computer is slower by a factor of only 10, you end up with a good 450 units per axis. And if you'll be wanting a faster refresh rate, the number of units drops even futher.Going back to the optimistic nanosecond-computer scenario above, let's see the effect of dropping the 3D requirement. You no longer lose a nanosecond on the 3D calculation, so now you can calculate half a billion units per cycle. In a 2D grid, this means well over 22,000 units on an axis. Still not the meganumber you'd like, but it's a hell of a lot more than 700.Regarding complexity, I think you're overestimating the effect of 3D. The gain, if any, that you expect from the sheer fact of having more directions is completely bogged down by the greatly reduced number of units. Complexity is a matter of numbers. If more complexity is what you're after, you should go for larger numbers.Of course, you can probably implement some clever tricks to cut down on the number of calculations, but I think that without dropping 3D, they may not help very much.Now, for something more constructive: one of the tricks you might want to consider is an 'expanding universe'. What I mean by this is that the computer could keep track of the outer limits of the region that contains objects. In the beginning this region could be small and concentrated around a 'center of the universe'. The computer wouldn't have to bother with calculating the situation outside this region. As objects drift apart, the region to keep track of would slowly expand. This means that, as time goes by, the cycles would get progressively slower.That's it for now. I don't have time to help you programming, but if I have new ideas, I'm perfectly willing to share them.Cheers.

You are talking about the program having mutable classes.I am thinking there would be a base class called CellScapeObject from which all other object classes would derive. This base class would have methods and properties that are common to all objects. Things like position, movement vectors, temperature etc.Static classes can be derived from the base class but how would new properties be added to create new objects. In post #1 you talked about attaching algorithms to objects. As far as I know C++ does not allow for dynamically adding new methods to classes at runtime. You could have an array of pointers to functions but each function would have to return the same value. This could work if the functions only returned a boolean indicating success but had side-effects on parameters.The functions that could be called would have to be predefined. I guess the trick lies in creating several simple functions that the objects can combine in novel ways to create new behaviours. "Bound" may have been the wrong word. I agree that everything should have a physical analogue. With that in mind, since the program does not model chemical bond energy, and cells get their energy from food, and food could potentially be any item in the CellScape universe, there must be an energy component of each object. This energy component would represent the chemical bond energy that could be extracted from that object when metabolized by cells.I'll think about this some more and post some pseudocode.

Hi Awinkisas!I don't have time for a good reply now, but I did want to briefly touch on this: I'm having real problems conceptualizing how one might have object type be a function of its properties, rather than having explicit object classes. But I've also convinced myself that it isn't necessary to figure out how to do this at the outset. If we figure out an effective way to do it down the road then we can add it in at that time, but for now having explicit object classes for each entity in the universe should work.The algorithms associated with objects will be algorithm objects rather than methods. I was planning to put them in lists which are traversed with iterators, but I'm open to other ideas, especially if they're more efficient. Probably the most important part of the program affecting efficiency is the interpretation of the algoriths - it had better be fast.Just as the algorithm list is not fixed (and neither are the algorithms themselves), the properthies or attributes won't be fixed either, and these, also, can be placed in lists, though if they're always just property/value pairs there's more efficient approaches. The important factor is that the properties of an object are not fixed - they can change during reproduction.I don't think there's such a thing as mutable classes in C++, but I'm not sure. What's a mutable class to you, and what does it look like in C++?--Percy

Hi Percy,C++ classes are not mutable and I don't know of anyway to do it short of redefining the language. In any case I don't think I read your first post very well because I now realize that you are talking about storing your algorithms and objects as data and not as code. You have to bear with me, I'm a little slow I did some research and found that java as well as languages using the .NET framework expose a compiler class. If the algorithms are written using any of these languages they can be compiled on the fly and executed. The compilers they implement are probably better than anything we could come up with. Ideally the algorithms would be compiled once and only recompiled if they are modified. Something to think about.

Hi, Awinkisas! I know you're talking about object algorithms, but this raises questions about my choice of C++ for implementation. Can you say more about this? There were two reasons I focused on C++ for implementation: I'm familiar with it, and it compiles to object code. But I'm not Java-familiar, and perhaps my assumption that Java is interpreted (ie, slow) is incorrect. A best case scenario would a an alife that can be distributed across the net because it is implemented in Java. And naturally if Java is compilable then it makes sense as the algorithm language, too, though by necessity for simplicity and efficiency we'd use only a subset.--Percy