ALife Standards

I was thinking that if many of us are going to be creating artificial life in SL, we should eventually develop a set of standards. In particular we will need a standard way for various life forms to ask and retrieve information from each other. This will make it so that everyone's life forms can co-exist peacefully or compete fairly.

This is a bit premature, since I haven't put much thought into this and we don't have a large space devoted to Alife, but I was thinking the communication standard would be something like this:
* All life forms listen to a standard (negative) channel...
* When a life form wants to retrieve information about another (see it, smell it,, taste it), it simply sends an ask request of the form: Say(channel, (string)key);
* If a life form hears it's key on the channel, it replies back with a string (CSV) full of data... including information such as:
~ Version # (what format the rest of this data will be in; this will surely change over time)
~ Type: Plant/Animal/Robot/Other (every living thing will be one of these types; creatures should have various Types marked as edible; plants just eat sunlight)
~ Subtype or Species (needs to be decided upon and cataloged; will determine breeding and friendliness/communication)
~ Color (so that creatures may be able to form connections between colors and food/enemy/etc)
~ Visible State (agitated, calm, weak, etc.)
~ Foodquality (how much nurishment it gives if eaten)
~ perhaps various commands and channels that may be needed to interact (although these could also be standardized beforehand)
~ etc.

This way our creatures and plants will be able to intermingle, eatting each other and possibly even mating together. (It'll be funny to see a cyborg-fish develop naturally.)

This could be a rather big undertaking, and if we do start this up, I recommend getting us a wiki somewhere.

N!Rust

This is a good idea and could possibly bear fruit . ( scuse the pun ).

I will be publicly releasing the simple email and sensor protocols for my eco system fairly soon. I'm happy to take part in discussion and even to expand my protocol to include any that might arise from this, but I'm unlikely to change the work I've already done because it's working now here's a starter if you like...

Without giving away too much at this point my extremely simplistic parameterised gene strings are sent by email in newline seperated strings and are of the form:

ix +/- integer
fx +/- float
sx string
vx vector
rx rotation

where x is any string but often just a number.

Format for each gene consists of 3 parts
type \n generation \n data

eg
vA\n12\n<1,2,3>
is a 12th generation vector gene symbolically named "A"

i202\n2\n101
is a 2nd generation integer symbolically named "202" with the value 101

s0\n0\npalm tree
is a zero'th generation string with the data "palm tree"

each gene in the string is seperated by newline \n

each whole string contains a special string marker s0 for the species/genus at the very begining of the string and it must be there! All other genes can serve any symbolic purpose I like and are mostly only of any use within the same species of alife, hence the importance of the species marker at the start of the string...

s0\n0\npalm tree\nv1\n12\n<1,2,3>\n ...

the only important part for the mutation system to work is the lowercase symbols that tell the system the format of the data following, s for string i for integer, v for vector, f for float etc. The generation counter is used to determine a dominance weighting in the mutation and combination algorithms.

A generic mutator function can take this string and mutate it and/or combine it with another and the code in each species in the system actually determines whether a mutated gene is usable or not and can fall back on defaults if required.

Metadata can also be stored in string genes or even in other types.

I'm not bothering with cromosomes atm but might add them later !

Some advice from experience...

I believe it's sensible to avoid using listeners if at all possible, they appear to be the most laggy form of comms.

Having said that. Listeners are about the only method for anything approaching real time communication in SL. Just to avoid them wherever possible.

I personally prefer to use low frequency sensors and very low frequency timers to obtain keys which can be used for email. This method requires coded names in objects for success.

All my alife dynamically change their names as they grow, live their lives, become fertile, whatever.

This way, for example, bees can sense the location of fertile plants and ignore those that are not. Birds can sense food and water. Plants and seeds can sense rain clouds and suitable habitats by looking for name coded passive or active objects and even make sense of a simple scan for scripted objects.

Coded, dynamically changing object names are the key here. Descriptive readable info (for us humans) can be stored in the object description fields as these can't be accesed by sensors unfortunately.

Another way of easilly getting sense data is to have invisible marker prims and use their rotations to store some value. Many of my markers store their water or nutrient levels by setting their rotations and alife can sense a marker by name, get it's rotation and therefore quickly obtain a simple value.

----

Another problem is physics. The Havoc implementation in SL is, simply put, rubbish. Even a few awkward collisions can bring down a sim. Therefore I like to make ALL objects PHANTOM unless they are actually requiring a collision event for something to happen. This massively reduces the number of physical collisions.

Thanks for all your good input Lauk!
From what you've said I can see that storing all "visible" data in the object name will make more sense. It definately seems like a simple llKey2Name will be a lot more efficient than having a listener always on and a two-way communication needed between the life forms.

I haven't used the email functions at all, but it seems like they will be useful for any communication that doesn't need to be quick - such as critters socializing, mating/passing genes, etc. What is the typical delay between an object sending an email and it being received?

Your method of using the rotations to store data is pretty ingenious! But I'm just wondering why that data couldn't just be stored in the object's name? It would seem like that would also help decrease the # of prims.

You can only sense whole names, it's not possible to sense partial names. Because of that, I store specific object "states" in names not variable data. The names are coded to mean something specific at any given time. eg a flower which is ready to seed and waiting for pollen from another flower changes its state from phantom to solid, changes its name to "fertile flower". One of the names bees look for is "fertile flower", the bee can then locate the flowers and use the collission event to pass its key id for an email.
( in fact you 'could' bypass the collission altogether and use a sensor to tell how far you are from the plant in this case, but I considered that over using the sensor function, and the collision happens automatically when the bee arrives successfully at its target! )

Using a rotation to store percentages or other values allows you to get at them in 2 fast moves... sense for pre-known name ... get rotation in the sensor event. The limitation here is to remember a quaternion could be normalized and scale your values accordingly. I find using the DEG_TO_RAD and RAD_TO_DEG multipliers a useful tool for storing percentage values in a rotation.

email delay is about 20 seconds i think.

a good tip for collisions is to know that the events can be called in rapid succession for the same objects. It's a good idea to store the key of the last thing you dealt with in the collision_start or collision event and to ignore it if another start event happens too soon or before a collision_end.