RapidModel is Here

RapidModel is one of the original in-browser programs. This may be an odd thing to say since it’s only just appearing now, as the fourth project (or fifth, or sixth, depending on how you count the projects in beta) but it’s actually the second in-browser program I wrote. Much like the original version of CamoEvolve it needed some serious fixes. Unlike CamoEvolve it needed so many fixes that it really wasn’t workable, and so I took it down, re-wrote the code effectively from scratch (I kept a few drawing functions), and have now put it back up (having, in the meantime, re-written the whole site).

RapidModel is based on something I did in college. In one of our classes (probably Conservation Biology) we played around with a program where we could link items together and then play with sliders on them and see how they affected other items. I assume we built population models with this system, but I don’t really remember. RapidModel is similarly generic (but also free and does not require downloading).

At its most basic, RapidModel is a bunch of nodes that hold numbers with connections that cause the numbers in one node to influence the numbers in other nodes. The numbers in a node may represent anything – number of caribou, GDP, cans of beets – and the connections can take almost any form. So, without further ado, a brief explanation of the objects in RapidModel.

Nodes

Nodes are just number containers. To create a node select Add/Edit Nodes and click on the black part of the screen. A new node will appear where you click and you’ll be asked to name the node. You’ll also be asked for:

Number: The number the node starts with. When you hit “Reset” the node will remember this number and reset to it as well.

Maximum: The number in the node will not exceed this number. In some cases the maximum is based on a real world constraint and in others it exists just to keep the model in some sane range.

Minimum: The number in the node will not drop below this number. For many real objects zero is a natural choice.

If you edit a node (which you do by selecting the radio button with the node’s name after creating a node) you can also choose to check Round to Integer. In this case the node will never display non-integer numbers. However, it does keep track of non-integer effects. So, for instance, if an integer node held a 2 and you subtracted 0.1 from it ten times in a round the node would drop to 1. If you subtracted 0.1 from it once a round nothing would happen for ten rounds, and then it would drop to 0. For many real-world items rounding to integers makes sense. There are no 0.3 whales or 0.71 consumers out there.

Connections

Connections can only be created in the sidebar. Create some nodes, selected Add/Edit Connections, and select Add New. Connections name themselves in a way that describes exactly what they do (for instance, a recent model of mine had a connection called “Seals-Sharks”) so you won’t be asked for a name but you will be asked for a start node and an end node. Circular connectors are fine. Calculators (which we’ll discuss next) can only be starting nodes. Here’s the important thing to remember: start nodes do something to end nodes. This is easy to think about with additive nodes. You take the number from the start node, go over to the end node, and add that start node number to the end node. What a start node does to the end node is determined by the node type, which is just a mathematical operator. Connection weights can be used modify how much of the start node is used to modify the end node. For instance, to grow a node by 50% a turn connect a node to itself with an additive connection of weight 0.5. You could do exactly the same thing by setting up a node that just held the number 1.5 and using it as the start node for a multiplicative connector of weight 1.

Calculators

You create calculators much like nodes, which calculators are (technically) a subclass of. However, unlike nodes the important things that go on in calculators have to be done from the sidebar menu. Calculators have a set of arguments with exactly the same name as in nodes and these arguments (maximum, etc) function exactly the same way so I won’t re-describe them.

However, while calculators are programatically nodes they are ideologically very fancy connections. Unlike nodes they don’t retain a number for multiple turns, modifying it. Instead they calculate a value fresh every turn. Originally this was done by using dozens of connections and dummy nodes but calculators work much better. It’s the addition of calculators that made RapidModel usable. To use a calculator you must give it an equation. Equations can contains the names of nodes, numbers, and a small set of mathematical operators. Equations are written in a pretty straightforward manner: Squirrels/Trees gives you the number of squirrels per tree this turn. If you type an equation correctly you will see “No errors” when you hit enter. Otherwise you’ll be told what part of the equation was an issue. Calculators will also identify nodes that they draw numbers from and create yellow connections to them automatically.

The equation reader can only handle the following operators: +, -, * (multiplication), / (division), ^ (exponentials). It cannot handle order of operations. All equations are read left to right. So Squirrels/Trees/10+1 is equivalent to ((Squirrels/Trees)/10)+1.

Calculators can also be used to delay effects in a model. The delay time simply puts the calculator X turns behind the rest of the model. At the very simplest a calculator could simply take the value from another node a hold it for a certain number of turns (for instance, price responds to the demand of two turns ago). Because of the delay function the initial number of the calculator can be important. Perhaps you are multiplying by the output of a delayed calculator. If you start with 0 in the calculator you’ll zero out your next node as well, whereas if you started with 1 in the calculator nothing would happen for the turns before the calculator showed its first calculation.

So what does this look like?

Here’s a silly example. I want trees to grow slowly. I also want the squirrel population to grow but to be capped at 2 squirrels per tree. I made this model.

Trees and Squirrels are just nodes, set to round to integers. SquirrelsPerTree is a calculator with the equation Squirrels/2/Trees, which hits 1 when there are two squirrels per tree and stays under 1 when there are less than two squirrels per tree (as in this screenshot). Trees connects to trees with an additive connector of strength 0.1 which causes the population to grow by 10% per turn. (Again, while trees are integers, the accumulation of partial trees still eventually triggers the addition of a tree.) SquirrelsPerTree creates dummy connections (in yellow) that can’t be edited but which show that it uses both Trees and Squirrels for its calculations. Squirrels is divided by SquirrelsPerTree, so when there is extra space around the population expands. The minimum cap on SquirrelsPerTree can be used to lock the squirrel growth rate at some maximum and the maximum cap can be used to prevent the squirrel population from crashing violently.

I have no idea what you’ll use RapidModel for. I’ll definitely use it for population models in ecology this semester, but I deliberately made it extremely open-ended. If you do something fun with it leave me a comment.

CamoEvolve 1.1 is Here

CamoEvolve 1.1 has just been uploaded to the main site. Since I haven’t actually discussed the purpose of CamoEvolve here before I’ll cover both the changes in 1.1 and also the basic idea of the program.

CamoEvolve is an evolutionary simulator designed to run in a small window, making it suitable for tablets and phones (although it continues not to work on iOS touch-enabled devices for reasons that are unclear to me). In it there are objects that have a color, a shape, and a size. Some of these objects are background objects and some are critters hiding from you. The background objects are all generated from the same template and so they tend to be similar in color, shape, and size. The critters maintain there own gene lines and inherit their color, shape, and size (with mutations) from the critters who survive.

Your task is to identify the critters and kill them by clicking on them. For a real-world biological parallel imagine being a bird trying to find camouflaged insects amongst rocks and twigs. Like this hypothetical bird who grabs a stick and has to spit it out you will suffer a penalty for clicking on the wrong thing and will be temporarily unable to kill critters.

A full help file is available and so I want to talk here a little bit about why I wrote CamoEvolve, what I’ve added in Version 1.1, and what you might do with the program.

The aim of CamoEvolve is to model natural selection in a manner that is very basic (no frills to confuse anyone), game-like, easy to interpret, and usable on almost any device. It’s meant to be an easy-to-use teaching tool where students can see natural selection first-hand. I attempted to accomplish each of these goals as follows:

  1. Basic: All objects in the game world have the same properties, of which there are only three, and the only possible actions are to click on things (killing them if they are critters). Critters can’t do anything at all. They live or die based entirely on the player’s actions and the inherent time limit the player is working against.
  2. Game-like: This is the part I think works best. It can be genuinely hard to find the critters (although one gets much, much better with practice). Instead of telling students to try and pretend to select for certain traits you are actually trying to do something that is genuinely challenging, and there’s a fairly harsh scoring system to keep you on your toes.
  3. Easy to interpret: You know when you start having trouble finding critters. You can also see all the elements in the game.
  4. Usable on almost any device: While many of my simulators have a graphics area and a control area CamoEvolve is deliberately built around a single area that is graphics and controls and is made so simple that it can be played on pretty much any reasonable screen size. I was specifically targeting phones here since all my students seem to have them and it’s much easier to say, “Take out your phone,” than to march everyone to a computer lab. However, as noted, there are some crippling issues on iPhones and iPads.

Changes

So what did I change? Well, I ran across two issues in CamoEvolve 1.0. The first was that rendering all of the objects and moving them steadily down the screen took more processing power than many phones seemed to be able to spare. Given my phone-compatibility goal that wasn’t very good and so the first change is that the scrolling-background mode is only one option, and not the default one. Instead, the default mode presents a screen of objects for a set time and then switches to a new scene. To accommodate this change I’ve tweaked the “lockout time” used in this mode, so you may notice that on the same screen the amount of time you are “jammed up” after a mis-click varies between modes. Also, you cannot get locked-out right after the scene changes. In my early testing I kept clicking on a critter as the scene changed meaning that I mis-clicked, got locked-out, and then couldn’t click anything. Now there is a small grace period as the scene changes. Also, of course, critters have a win condition where they are counted as surviving if they live to the scene change, rather than if they make it past the bottom of the screen.

This seems to have reduced the processor burden sufficiently, and this mode seems to work well on phones.

The second change is a simple one. In early usage students were sometimes unclear as to what was going on because it was easy to lose sight of the critters very rapidly as selection pressure made them better camouflaged. There is now a no-background mode to allow you to see how killing off some critters changes the gene pool.

To implement these mode options there is a new button on the main screen, Settings, that allows you to access these options.

What would you do with CamoEvolve?

Simply playing CamoEvolve demonstrates natural selection. A short explanation of how it works (critters that live have children like, but not identical to, them) seems enough to get students off on the right foot and then being able to play around with the game makes the concept clearer.

CamoEvolve also demonstrates genetic drift. If a player stops playing but lets the game run the critters become bizarre and mismatched. Since the critters are asexual each gene-line develops in its own way, and this way is random without a selective agent. I’ve had students switch between playing and not several times to see how a selective pressure steers a random process.

Artificial selection and natural selection are closely tied conceptually. The no-background mode makes it much easier to practice artificial selection. I generally set a random target for the students (red triangles is my go-to, unless someone actually starts with anything like that) and have them compete to get there first.

What would I do with 100 Places?

Having publicized the existence of my in-browser software I’m beginning to get questions. One of the more frequent ones is “What do I do in/with 100 Places?” 100 Places is designed to teach about niches and niche partitioning in ecology. It’s also designed to simplify this a lot so the only way to make organisms different is by choosing how they allocate their energy. All organisms use the same resource (space) and get the same amount of energy per turn (100). Only the allocation of energy (and some human-friendly things like names and colors) can differ between species. So here are some basic things you can do with it:

  1. Demonstrate competitive exclusion. This is simple. I’m going to make four identical species, differing only in color and name. Since I want this to go quickly I’ll up their ability to survive in harsh squares (allowing them to populate the whole board lets runaway ecological dominance runaway properly) and steal that energy from their ability to resist herbivores and disruptive events. See below, complete with totally awesome species names1.So what happens when we start the simulation running? Well, the board almost immediately fills. However, WeaselBait loses out in the mad scramble, and ends up with less individuals than the others.The graph is extremely choppy at this point, since nothing has any resistance to the herbivores wandering through and the disruptive events (let’s call them storms) and so large open patches are constantly appearing and then being filled. But by the mid-200 turns Kataklysm has (somewhat ironically) lucked out and has a commanding population lead. Somewhere around turn 600 Harmaggeddon shuffles off this mortal coil. At this point Kataklysm has a population of 79 (remember, 100 is the maximum population of everything put together) and so any open spot immediately gets spammed by Kataklysm seeds. By turn 750 PoofyPants is gone, too, and only Katakylsm and WeaselBait (which, ironically, looked worst-off at the beginning) are left. Around turn 900 it’s all over – nothing is left but Kataklysm, which is presumably high-fiving its teammates and yelling, “COMPETITIVELY EXCLUDED!” at the other species.
    This example is a particular sort of competitive exclusion in that the winner is random because all species are identical. However, it demonstrates the idea very clearly. Even though all the species function exactly the same and so there is no “best” species2 there is still only one survivor.
    Obviously, one other thing you could do with this is play with the environment and organisms to see under what conditions/what kind of organisms does the resolution of the scenario (i.e., the extinction of three species) take longer. Does apparent coexistence last longer in some scenarios? Probably. I have a suspicion that I should have turned down the rate of disruptions to make things resolve quicker in my example.
  2. Can you make an organism that can push the generalist that is auto-created at the beginning of the simulator into extinction every time? This is also competitive exclusion but of a different sort since here there is a “best” species. This should also be easy since the generalist is literally just allocating the same amount of energy to every task. Some tasks are probably not worth that energy and so it shouldn’t be hard to design an organism that takes energy from these tasks and puts it somewhere more useful.
  3. 100 Places is named 100 Places because there are only 100 Places and places are the only resource the simulated organisms (I think of them as plants) need. How many species can you get into stable coexistence in just 100 places?
  4. Habitat variation should make it easier for more species to exist stably. The default habitat has a harshness range of 0-50. If you up the range to 0-100 can you cram in a few extra species and keep it stable? If you drop the range to 0-20 can you still get a bunch of species to coexists? What’s the effect of absolute harshness, anyway? Is 0-50 a whole different ball game than 50-1003?
  5. What is the effect of herbivores and disruption? They are very similar as game mechanics (although herbivores are constant and hit one square at a time while disruptions are random and hit multiple squares) but since organisms have to allocate energy to deal with them separately you can have organisms resistant to one but not the other. In theory (Intermediate Disturbance Hypothesis) you should be able to balance out a slow-reproducing, highly competitive species with a fast-reproducing, non-competitive species if herbivores/disruptions kill of individuals of the competitive species at the right frequency. Too much disruption and you lose all the slow-reproducing species and too little and the competitive species squeezes the non-competitive species out of existence.

During all of this you will also see some rather classic ecological growth curves.

Random Rules: Observations and the Scientific Method

Random Rules is the newest in-browser simulator on the site and the only one that doesn’t currently have a help file. This is in part because the in-browser simulators on the site right now are all ones I plan on using in the fall semester and so my first priority is to have them done so I can use them. Making them usefully available for everyone else has to come second. This post is, partly, a help file. That section will be clearly labeled in a subheading. Just skip straight there if that’s all you need – I’ll repeat a few sentences of material in both places so that if you skip straight to the help file you’ll be fine.

Read More