Crash Course Evolution

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.

I was writing up a lengthy response which a blown fuse ate, so I'm gonna try rewriting from memory shorter this time:

It occurs to me that there are two main uses for morphogen gradients -- discrete feature positioning and continuous magnitudes. Continuous magnitudes are easy to represent with a gradient on a curve, but discrete positioning is a little more complicated. In the real world, continuous morphogen gradients are turned into series of discrete points by reaction-diffusion systems. Reaction-diffusion systems are most easily simulated by cellular automata, which are still kinda pointlessly expensive for our needs. So, for the positioning of discrete clones of a feature (eg, fingers, vertebrae) we shouldn't use plain, continuous morphogen gradients, but an abstraction. The abstraction is a simple one, and simply stores, along a curve, a set of points where feature clones go and orientations for each. Feature positions can be spaced out a certain distance (maybe based on a continuous morphogen gradient), while orientations are found by interpolating and looking at the curve's local curvature.

To keep it easy on players, I was thinking gradients and the like could operate mostly in the background. For example: Say you're making a hand. You've just made a finger, and you select it (the base joint?) and use a clone tool to draw a curve to clone the finger over. You can set spacing and so on, but all you do is use whichever clone tool (in this case, clone along curve) to get your copies, without having to know about or tweak morphogen gradients. What's more, that means we need not display the gradients.

Provided that this gradient system towards tracking mutational changes on a creature is straightforward in how it's presented to the player, and offers the same level and direct control in sculpting their creature using the editor, I'm in favour of implementing it.

However, I'm still a bit confused as to how this would look in-game. Could you give an example of what it would look like when a player enters the editor and makes changes using what you mentioned?