Crash Course Evolution

Sounds great. I'd want closer to 5%, but again it's all dependant on how exactly we finally decide to handle complexity measurements.

~sciocont wrote:

The idea I'm having here is making behavior editing more visual and easier for programmers and players. It's not fleshed out yet, but I'm imagining a hexgrid with tiles on it that correspond to entities and behaviors. Entities are organisms in your environment or parts of your environment (water, a cave), and behaviors are things to do when that entity is sensed(run away? eat entity?). An enemy is connected to a behavior by a connecting line, and that line has a condition attached to it based on the situation. (is an entity coming close? Is it far away? is an animal wounded?) Those three things would create the meat of the editor.
Behavior and entities are placed on tiles so a player or computer can easily group them together- when tiles of the same type (entity/behavior) are next to each other, they are paired together. If entities are paired, the same response goes for both of them. If behaviors are paired, they will always happen together. You can duplicate behaviors  or entities if you want, so you can lump all predators together and link them by "when near" to "run away", while at the same time linking one enemy to "stop in place" by the path "when far away".
Intelligence is determined by the size of the hexgrid.

Hot Belgium that's elegant.

That sounds like a neat but powerful system that'll be intuitive and easy to use but at the same time allow a lot of different actions. Each line you draw between entities and actions could cost MP, allowing your species to evolve mentally using the same currency as physically.

This could also link in with other behaviours. Although it's probably all but a dead concept by now, the AI Editor Prototype linked on the ModDB page could be incorporated into this system. As well as environmental entities, you could add variables (for instance, hunger, thirst, etc.) and link them to actions as well. The interface could show this as the variable surrounded by values, and each of the values can be linked to an action. For the example shown on the AI Editor Prototype, you'd have a central hex labelled 'Feel of Itch', then in the surrounding hexes there would be value ranges (0-10%, 11-20%, etc.). These value ranges could become more precise as your creature becomes more advanced, so a primitive organism would only be able to know which side of 50% the feeling of itch is but more highly evolved creatures may have ranges of 20%.

To solve the issue of tracking evolutionary changes, I thought of a third solution. There could be a complexity bar in the Organism Editor that would keep track of the complexity of your changes. Now before you fly off the handle saying that this is a Spore thing to do, this will be a bar that measures only the complexity of your changes, not the overall complexity of your organism, which are two very different things. The benefits of this approach would be:

• It would apply to both the AI and the player, and one system to do two things is always easier than two separate systems
  
• Since there is always the same complexity cap when you enter the editor, it means the player won't have to/be able to grind for currency to evolve
  
• The CPU does not have to keep track of the currency held by all the orgs and species on the planet, because the complexity cap is the same for everyone
  
• Everything can have an assigned complexity value
  
• Easy to scale speed of evolution be altering complexity cap
  
• Not necessary to make arbitrary triggers during gameplay yield an "evolutionary currency"

However, this system would also mean that we would have to make reproduction something the player can't spam, because otherwise the player could reproduce a lot and evolve very fast (because without having to obtain a currency, it becomes easier to evolve).

I fully support this approach, but I would like to hear what you guys think.

Actually, that was my idea. I have no idea if I should be flattered or ripped off. I'm not bitter, by the way.

NickTheNick wrote:

To solve the issue of tracking evolutionary changes, I thought of a third solution. There could be a complexity bar in the Organism Editor that would keep track of the complexity of your changes. Now before you fly off the handle saying that this is a Spore thing to do, this will be a bar that measures only the complexity of your changes, not the overall complexity of your organism, which are two very different things. The benefits of this approach would be:

• It would apply to both the AI and the player, and one system to do two things is always easier than two separate systems
  
• Since there is always the same complexity cap when you enter the editor, it means the player won't have to/be able to grind for currency to evolve
  
• The CPU does not have to keep track of the currency held by all the orgs and species on the planet, because the complexity cap is the same for everyone
  
• Everything can have an assigned complexity value
  
• Easy to scale speed of evolution be altering complexity cap
  
• Not necessary to make arbitrary triggers during gameplay yield an "evolutionary currency"
  

However, this system would also mean that we would have to make reproduction something the player can't spam, because otherwise the player could reproduce a lot and evolve very fast (because without having to obtain a currency, it becomes easier to evolve).

I fully support this approach, but I would like to hear what you guys think.

That seems quite doable, we can limit editing to once per (global) generation.

Well, how is the game going to calculate the global generation, take an average of the generation times of all species? That sounds CPU intensive. Thoughts?

I think that's something to ask in the Auto-Evo thread, considering what I'm about to post.

Any issues left will need to be addressed after ironing out some concepts.

Episode 1: Organism Editor

Before you read, here are some more important threads on evolution, not posted in the OP:

https://thrivegame.canadaboard.net/t1014-evolution-of-body-structure
https://thrivegame.canadaboard.net/t933p30-population-dynamics#19733

These are optional, but greatly help if read. (Thanks for providing the latter Oliver)

So, I was considering how to make the Organism Editor and the Tech Editor seem more consistent, and I think that the triple-S system mentioned by I think The Uteen a long ways back works best. Structure, Systems, and Surfacing (Decorations).

*In the OE, Structures is where you place the bones, muscles, and fat on your organism, with some alternatives for bones like arthropod parts, wormacles, etc. Systems would be where you place organ systems (using tubes and nodes). Surfacing would be where you brush skin, feathers, scales, fur, colours, textures, and designes on your organism.

*In the TE, Structures would be where you place walls, roofs, frames, platforms, and basically any shapes to hold/support your Tech Object. Systems would be where you place Function Parts, the "Organs" of your Tech Objects (enabling them to do specific actions or processes). Surfacing would allow you to change the colours, designs, and textures, as well as place embellishments (something I'll discuss in the future, but are basically models that only add to the appearance and cost nothing).

Anyways, that means the OE would have three tabs, the Structure, Systems, and Surfacing tabs. Let's begin with Structure.

Part II: Skeletal Structure

The basic foundation of any organism is it's skeletal structure. Now in LAWK (Life As We Know it), there are three different classifications for this.

1. Endoskeleton - A skeleton of bones on the inside of the organism (think mammals).
2. Exoskeleton - A shell or casing on the outside of the organism (think insects).
3. Hydrostatic Skeleton - A tube filled with water on the inside of an organism (think snails).

With use of the OE CC, let's try and nail down everything there is to this, to get a working GDD for the Organism Editor.

The Origin of the Skeleton

First, we must decide how skeletons will originate. I think the best time is after the game perspective has transitioned from 2D to 3D. At this point, the player's organism is basically a blob, having just been a large congregation of conjoined cells in a 2D tidepool. At this point, the Microbe Editor is replaced with the Organism Editor. The first time the player passes to a new generation and enters the OE, the player should be able to start to evolve a skeleton. They could place a group of three vertebral bones, an arthropodic abdomen, or a wormacle (with a maximum of three rings).

Here are some questions to answer:

Endoskeletal Systems

How much complexity does it cost to add or remove a vertebral bone?

I was thinking 33 Complexity Cost (CC). This would mean a maximum of 3 vertebral bones could be added or removed in a given generation with a Complexity Meter Cap of 100.

What are the properties of bone?

From some searching of the web I found that most organisms have a bone density of 1.6g/cm^3. The total volume of all the bones in the body would be multiplied by our predefined bone density to get the total mass of all the bones in a body part (head, body, limb, or tail). This would contribute to the total mass of the body part, which would be it's "health".

The vertebral bones of the spine, the bones of a limb, the skull and jaw, and the bones of a tail are all composed of the compound "Bone". This compound would have the density of 1.6g/cm^3. However, another interesting fact I found was that in the human body, each kilogram of bone in the body consumes 0.11 J/s of energy, at rest. Would it be fair to apply this to all bones for all organisms? Also, how will we find out how much energy specific actions will cost?

What would be the movement restrictions of bone?

To do this, I think that it would be important to define an "Anchor" vertebral bone, or a vertebral bone that would not move and would be the reference point for all other vertebral bones. The first vertebral bone placed in an organism would be the "Anchor" bone. If the anchor bone is removed in the OE the player would have to define a new anchor bone. If an anchor bone is removed in an AI org during Auto-Evo, the next closest vertebral bone becomes the anchor bone.
All bones above the anchor bone would be able to turn up to 5 degrees in any direction, with the point at which it attaches to the bone before it being the pivot point.
All bones below the anchor bone would be able to turn up to 5 degrees in any direction, with the point at which it attaches to the bone after it being the pivot point.
These are the basics I can think of for movement limitations of a spine.

I'm going to stop here for now to get some feedback. I feel like this is starting to get terribly complex, but at the same time we need to remember that the goal of the OE is to be able to create a wide array of organisms of diverse nature, and every time the computer needs to be able to analyze them, find how they can move, what animations to give them for moving, how fast they run, if they can fly, swim, climb, how much "health" each body part has, how to animate them eating, and a bajillion other belgiuming things.

For the sake of simplicity, I suggest that we don't even include exoskeletons or hydrostatic skeletons in the initial releases, and just stick to trying to get an implementable model for endoskeletal organisms.

Immortal_Dragon wrote:

Well, how is the game going to calculate the global generation, take an average of the generation times of all species? That sounds CPU intensive. Thoughts?

Actually, taking an average is trivial. Generation time is just a set amount of real time, say 10 minutes.

Good post, nick.
A necessary precursor to bone should be implemented- it's a complex tissue that doesn't just arise out of nowhere. Therefore, I'd say we have to implement another tissue- cartilage.
According to this very useful page, cartilage has a density of ~1.1 g/cm³ (btw, this source lists bone as having a density of 1.8-2.0 g/cm³. Where is your 1.6 from?)
I would like to have it so that you can't become bony immediately as you become 3D, so I would like bone to only come from a cartilage or chitinous (exoskeleton) base- meaning you have to have one of those tissues before you can have bone.

I think a CC of 33 would be appropriate for removing or adding a vertebra. We also need to worry about editing the properties of vertebra in groups, but we'll deal with that later. Your base (I assume dorsoventral/lateral) flexibility of 5° seems pretty good, I'd add to that an axial flexibility of 5° if that wasn't already assumed. I like the idea of an anchor vertebra as well.
Keep in mind that there is a bossibility of vertebra structures being used as legs, etc. The system currently works well for this application and I want to keep it that way.

Addition of vertebral processes should be fairly easy: all vertebra begin with lateral, dorsal, and ventral processes (4 total) with lengths of 0. The lengths of the processes can be adjusted click by click (by cm/ whatever the lowest possible measurement for bones is)
I'll begin writing a more detailed OE GDD, complete with organ evolution, mutation costs, specific construction requirements and details like these, and so on.

Okay, adding cartilage as that intermediary step sounds nice. What would be the differences in properties between a cartilage spine and a bone spine? Less health?

For the density of bone, I actually found several different sources. One said that 1.8 was surprisingly the standard amongst all organisms, while another said that some bones are around 1.4-1.5, while others are 1.6-1.8, so I took 1.6 as a compromise. However, with the addition of cartilage, I think 1.8 would be more appropriate.

Quote :

Keep in mind that there is a bossibility of vertebra structures being used as legs, etc. The system currently works well for this application and I want to keep it that way.

Do you mean a body/torso which is also a leg? Because I was thinking that legs would be a joint to be attached onto the spine, like arms, to help the computer identify them as a separate body part from the body (for defining animations and health values for the different body parts).

NickTheNick wrote:

Quote :

Keep in mind that there is a bossibility of vertebra structures being used as legs, etc. The system currently works well for this application and I want to keep it that way.

Do you mean a body/torso which is also a leg? Because I was thinking that legs would be a joint to be attached onto the spine, like arms, to help the computer identify them as a separate body part from the body (for defining animations and health values for the different body parts).

I think this is probably better.

NickTheNick wrote:

Okay, adding cartilage as that intermediary step sounds nice. What would be the differences in properties between a cartilage spine and a bone spine? Less health?

For the density of bone, I actually found several different sources. One said that 1.8 was surprisingly the standard amongst all organisms, while another said that some bones are around 1.4-1.5, while others are 1.6-1.8, so I took 1.6 as a compromise. However, with the addition of cartilage, I think 1.8 would be more appropriate.

Quote :

Keep in mind that there is a bossibility of vertebra structures being used as legs, etc. The system currently works well for this application and I want to keep it that way.

Do you mean a body/torso which is also a leg? Because I was thinking that legs would be a joint to be attached onto the spine, like arms, to help the computer identify them as a separate body part from the body (for defining animations and health values for the different body parts).

You'll see how it all works when I publish the OE Endoskeletal GDD that I've been working on.
I think 1.6 may be a good value for bone density, since bones aren't totally solid structures. If only I had the equipment to take some measurements...

~sciocont wrote:

You'll see how it all works when I publish the OE Endoskeletal GDD that I've been working on.

Okay. :) I look forward to seeing the finished product!

So, ~scio, Seregon, and I have collaborated to draft up the first copy of the Organism Editor Game Design Document (or OE GDD).

This document is open for study, analysis, and revision.

What's more, using this document I want to create a specification for an Organism Editor Prototype. So far we've only had Microbe Stage prototypes, so this will be the first one for a later stage or game feature, and the OE at that. At the moment, the specification will only contain details for a structure tab, for an endoskeletal organism. It will just be a modified version of the OE GDD. Later updates can add in other types of skeletons, and then later other tabs of the editor, until we could even get a final working prototype of the OE.

Until then, here is the download link:

http://www.mediafire.com/download/5sqr5byw3leiis3/Organism_Editor_GDD_2.2.docx

This basically wraps up the current part on skeletal structures. Tomorrow I'll post with the download link to the specification, and answering any loose ends there are still left on this part. Next part we will be discussing muscle, and fat, a relatively simpler topic than bone structure and placement.

Just read through this and it looks like you got it sorted. Couldn't really think of anything you missed.

Inca wrote:

Just read through this and it looks like you got it sorted. Couldn't really think of anything you missed.

QFT

Okay, so after a long time of having this thread suspended I think it's time we pick it back up. I split off the last three pages of the thread which got quite off topic and put them here. Although we are currently focusing on the Microbe Stage I think that it will be helpful to nail down such an important concept sooner rather than later, and it will definitely help us in designing the Multicellular Stage (which isn't too far off anymore).

I'll wait a day for anyone who wants to participate to read through what's been posted so far and check out any related links. Also be sure to check out the Organism Editor GDD linked above. After that we'll resume where we left off.

I've had some ideas recently about evolution and the OE that will make auto-evo better, organisms better-looking, editing less complex, and everything more realistic to boot. Will post soon.

When I hear organism development I immediately think of Hox (as the representative example). Is painting embryogenetic gene expression patterns what you have in mind? It happens to be what I have in mind, but I'm tired so I'll elaborate later.

If it isn't though, that's totally cool -- more ideas!

Edit for elaboration:
Much as how many developmental processes involve a particular mix of signals triggering the creation of some structure, a player could put a new developmental signal in a certain area, and link that to the development of a certain feature. The form of the feature would then be controlled by its own sub-smorgasbord of sub-signals linked to sub-features. Then, much as how real-world experimenters can induce the growth of legs where a fruit fly's antennae would usually sit, mutations would allow you to either put new patches of a growth signal down (and thus cloning the feature), convert growth signals into others (switching between features), and place new signals entirely.

There would have to be more than just point signals available -- for example, the development of the segmented body plan (whether the vertebra+ribs arrangement most evident in snakes, or the segmented body of a millipede, or even the shape of an insect head), which I alluded to above in my mention of Hox, would be a very useful tool for driving lots of cheap complexity, much as it did in the Cambrian explosion. You'd paint one signal along the body to create many similar segments, and then using point signals, you could specialize each segment, or groups of segments. We could easily include signals for plant-like development as well, with signals being painted onto a meristem-like structure to define growth.

The player would be able to develop/unlock these new development signals in Early Multicellular, since that's the stage that takes you from an undifferentiated colony of cells into a structurally complex organism.This will give us a clear distinction for what makes Early Multicellular gameplay unique, since, as in real life, the early stages of multicellularity are filled with experimentation of new body plans and loads of evolution involving intercellular signalling.

Last, but not least, though -- keep in mind that this suggestion doesn't mean we must make ontogeny recapitulate phylogeny. Quite the opposite, since evolution will involve the movement of many signals, changing all the little bits of the organism over and over again.

The intended evolution process is actually quite different from what you suggested. I'll think about it overnight, then I'll have to make a megapost tomorrow covering the evolution process and also an intro to the next part of the thread.

That I imagined, but when I considered the problem of not having something well-defined for the focus of multicellular stage, and when I considered the technical problems involved in making auto-evo do good-looking and also not unreasonable things, I decided to do some research and design a mutation model that would solve those problems.

Now, since I have heard nothing on here yet of a mutation model that affords realistic mutations and makes unrealistic (think Spore) mutations difficult; I eagerly await your megapost.

So the way player controlled evolution works in the current concept is based off of the idea of mutation points. Mutation points are a currency the player uses to mutate their organism every generation, and the limited amount of MP ensures a limit to the amount of mutation each generation. Now on the surface this does sound quite gamey, and earlier it was called Complexity Cost to represent the maximum possible complexity of a mutation in one generation, but somewhere down the line it changed to mutation points. Having said that, I think MP are handled in a way that they are not as gamey as they sound.

For one thing, mutation points cannot be gained by anything you do in-game. Every time you enter the Organism Editor, you have 100 MP to spend. This means that the player can't "grind" for MP by doing things in-game, rather they can do whatever they want, as long as they survive, and don't have to feel like they are falling behind in evolution. Second of all, this is meant to simulate the maximum degree to which offspring can be genetically different from their parents from random mutation. No species can evolve more of less than another species if both live equally long lives and reproduce at the same time in their lives. Shorter generations will mean quicker evolution, but that is a realistic pattern we see in nature. 

Now, in the editor, the player sculpts their organism in three different ways. In the structure tab, they place or remove bones, reshape them, and brush muscles and fat stores across the body. Muscle strength is based on the size of the muscle (we actually found a mathematical relationship online for this, but it's not certain), which is based on the shape of the bone it is attached to. In the systems tab, the player places the organism's organ systems using a node-tube system. In the surfacing tab allows the player to embellish their creature with skin, scales, fur, colours, camouflage, etc. Lastly, the behaviour editor allows the player to edit the behaviour of their organism in a currently completely undecided manner. 

All these actions in the editor have MP costs associated with them, and the greatest cost never exceeds 100, so the player must choose how to allocate their MP to evolve their creature as best they can.

Also, nothing is locked upon first using the editor. Instead, certain mutations require a previous mutation to attach to, which itself might require a previous mutation. For example, when the player first starts the 3D portion of the multicellular stage, they are basically a blob of jellyfish. When they first enter the OE, they cannot simply place a spine. Instead, they must place a cartilage proto-spine. Then in a future generation they can evolve that into a bone spinal cord. To place limbs they must first place a girdle, and then they can place limb bones onto that girdle afterwards.

From my understanding of your suggested method, the player would not directly change the organism at that moment, but rather guide the future of that organism's evolution with signals, such as brushing the signal of a horn on an organism, and watching it slowly develop as the generations pass. Also, as you said certain signals are unlocked until later points in the stage. 

I only really have two major concerns with what you are suggesting. Firstly, I feel like directly editing the creature at that moment is better than placing signals, because I feel like placing signals is just automating the computer to make all the edits for you over a given period of time, whereas letting the player directly make the physical changes at that moment is much more interactive and rewarding. It also doesn't make sense to me why, when you are in the OE, you should be able to make the change at that moment, because you have already reproduced so are already going to have evolved.  

My second concern is regarding unlocking parts. I think a more natural way of preventing access to later parts, as I suggested above, is preferable.

One way we could implement this in the above system is to make it very expensive to add or remove bones, and much cheaper (relatively) to divide bones, merge bones, and lengthen/shorten them. This would encourage the player, and auto-evo, to focus more on segmenting and repurposing existing bones, rather than adding new ones and removing old ones. For example, if we look at vertebrates many of them have very similar bone structures in their hands/fins/wings.

Spoiler:

I'll hold on introducing the next topic for now, I think we can have some interesting discussion on this.

Ahh, now I understand your issue with my solution -- I didn't explain myself nearly well enough. The signals you would place/paint describe, more or less, how any one individual of your species develops (from egg to birth/hatching). The signals should not be, as you've said, places where gradual change will happen over a few generations, as we've already established that the feedback loop of organism modification should be pretty tight to make for fun gameplay. 

More or less, the development signal system is an elegant solution (and scientific backing) I came up with to the problem of templating. Many creatures in nature have structures, organs, and whatnot that are copied many times throughout the creature. Each of these copies can be modified by itself, and all the copies can be modified together at the same time; at what should be more or less the same MP cost.

As for unlocking -- signals wouldn't be used for unlocking parts, but for making structures easy to copy. Your suggestion for making bones very expensive to create anew and so on is good for some things, but will only go so far. What happens when I try to turn my lobefin fish into a tetrapod? If I don''t have templates, then I'll have to mutate front and rear fins separately, which is unrealistic as the front and rear fins are near-clones of each other. What I want to be able to do is change all my limbs at once by modifying the template.

Here's another way to think about it: We already include templating in our OE plan -- bilateral symmetry. When you modify something that's under bilateral symmetry, you modify both copies, because it makes sense -- they develop by the same patterns of gene expression. What I want to do is to make more of this templating available, so, for example, you could give your creature a segmented body plan, or a plant-like L-system body plan, etc.

Early multicellular would then be the stage where you explore these different body plans -- become a bilaterian, see how that goes, maybe try using L-systems for your limbs, maybe make your body segmented so parts are easy to clone over it, etc.

Example: You've just entered Early Multicellular. You want to eventually be a flying snake. You don't care much for following evolutionary history, so you aren't bothering to add and then lose limbs. Snakes are (apart from most organs) bilaterally symmetrical, so first things first, you spend some MP to become a bilaterian. This way, you can spend fewer MP later to develop eyes and stuff, because any mutation you make can be chosen to template over on both sides. Then, after a while you decide it's time to give your creature some lengthwise structure, so you mutate yourself some body segmentation. There aren't any outward changes to your appearance yet, because you haven't actually tied any mutations to segments. So next, you decide to develop some hydrostatic musculature. You make a bunch of muscles on one segment that can bend any which way, and then you template those muscles over every segment. Boom, you have a consistent pattern of muscles running from head to toe, and you can swim. Later, when you work on acquiring a spine, your notochord, then cartilage, then vertebrae all develop by templating along your segments. Fast-forward a couple hundred million years: you're a snake, and you want to fly. Now the power of templating is apparent -- ages ago you made all your ribs templated, and now that you want to fly, all you have to do is add a hinge to the template.

Oh, and I wouldn't say jellyfish -- they still have a whole bunch of internal complexity. Perhaps say a placozoan, or something with even less structure (placozoans already display differentiation, after all).

Now, the important part: how much would change if we included templates? Well, judging from what examples made most sense, templates would see the most use in the structure tab. So, the first step of the structure tab can be the picking of body plans, and then any changes made later can be templated onto the body plan.

There, I hope I've clarified things.

Moopli is thinking in the same direction I am. If we present editing and shape formation in terms of patterning on the genetic level, we can make larger edits, store the organism using less information, and include pleiotropy in the game. It's straightforward win-win. The specifics are the only problem.

What Moopli didn't mention, but that I think is very important for this to work, are the effects of morphogen gradients.

If you're unfamiliar with morphogen gradients, this paragraph contains a quick rundown of what they do. If you are already familiar, go ahead and skip this. Morphogens are genes that produce proteins (or, more usefully, the proteins themselves) that pattern development spatially. The downstream effects of a morphogen on cell growth produce different types of cells which go on to produce different amounts of different types of cells which create the structure of the organism. The reason that there are different types of cells is that morphogens have different concentrations at different positions in the organism at different times. The biology behind how morphogens are positioned and how their gradients form is super interesting and a bustling area of research, but we don't need to worry too much about the specifics. What you need to know is that there are a lot of different gradients that you can form using one or any number of interacting morphogens.

My ideas on implementing morphogens are still developing, but suffice it to say I want to move the editor away from a model where you can individually position every single bone in space and tweak it infinitely to one where if you, for instance, want to reshape a hand, you'll do so by modifying a morphogen gradient that controls the number, lengths and types of fingers. If you want to add another set of arms to your animal, you'll duplicate the arm-bearing region or duplicate the limb bud within the arm-bearing region and get a second set instead of dragging some bones onto your skeleton. Keep in mind, I still want to stick with an editor that focuses on the skeletal structure of the creature to determine shape, but I want to move away from tiny edits that would be difficult for a computer to replicate and towards a model where a computer can change one number and suddenly you have another finger on each hand.

Coding an organism's phenotype with morphogen gradients and similar signals lends itself very well to hierarchical and programmatic data representation. Since a lot of development involves large-scale gradients triggering formation of features that are then at the mercy of more local gradients, and since there's a clear ordering of the formation of different features, we can represent the phenotype of an organism in code. The phenetic code would behave like a mostly-functional language (ie, recursion, subfunction calls, little in the way of global state, etc).

As far as I can tell, there are two important datatypes:

• Morphogen gradients are multidimensional splines. 3 of those dimensions represent spatial position (somehow, perhaps in some local coordinate system), and the rest represent different values that this morphogen controls -- for example, finger length along a hand. Technically, we could do without the extra data bound to the curve (and just have each morphogen drop smoothly from 1 to 0 from one end to the other), but I figure it will reduce the amount of calculation triggers do.
  
• Triggers are sets of development actions (for example, painting muscle in an area between certain bones), and the corresponding morphogen concentrations required to cause the development to happen. Actions are all the things we've already outlined as changes players can make (likely simplified greatly since much of the structural complexity can be stored in term of relationships between gradients). Actions, of course, will also include the painting of subgradients.
  

What happens if we need a 2D/3D gradient? We could use two/three splines.

That categorization seems quite good- a few things I forgot to mention:

-gradients are meant to stay relatively simplistic. I imagined any gradient profile as having either an entirely positive or entirely negative slope or having a central max/min and peripheral max/min values and consistently positive or negative slope between the center and the edge. In order to get more complex gradients, like, say, you have to stack gradients on top of each other and have them interact.

-To achieve this, we can have a set library of gradient types, each with a few parameters that can be easily tweaked.

-In order to make this understandable to the player, we're going to want to focus on 2D gradients rather than multidimensional ones.