Asymptote’s Zombie Infection Simulator — Version 2.0

NOTE: I submitted the model to the NetLogo website, and it can now be found in applet form (and downloaded) here.

After discovering that my previous Zombie Infection Simulator post had gotten a mention on SquidTalk, and found that they were expecting a release in a few weeks, I thought I ought to try not to disappoint them. However, my previous simulator was, to put it nicely, rather rough around the edges, so I spent a lazy afternoon re-writing it. Without all the extra garbage cluttering up the code, it ran a little faster, and exhibited some new behaviors I hadn’t seen before. I also built in a simulator mode that includes the walls seen in the original version of the simulator, although that mode is somewhat broken.

Flocks of humans form as they did in the previous version. Nothing new, really.

The infection has started. I don’t know if it’s visible or not, but the zombies are displaying a great deal more organization, thanks to a greatly improved directional targeting method. Thank goodness for towardsxy.

The infection is spreading rapidly, and, as seen in the previous version, social order is beginning to degenerate. I know it’s not exactly obvious in this still picture, but note the dense little group of humans just above the large group in the center, to the upper left of the cluster of zombies. This group actually broke away in a coordinated fashion when some of its members panicked and fled. I’d expect to see runaway parties like this in a real zombie infection.

Social order begins to falter. Human flocks are beginning to be broken up by panic, and there aren’t enough fighters to rally them.

The little simulated society begins to break down. A few groups are still together, but they’re beginning to collapse as the onslaught continues. The zombies are much more organized in Version 2.0, which actually puts them at a great advantage over the humans. Not only do they form flocks, but they are much more effective hunters, so they tend to infiltrate human groups and pick them off and infect them before panic can disperse them.

As I said in the introductory paragraph, I added a secondary mode to the simulator complete with walls. Since there is still a bug in my simulator, and all the flocks tend to become oriented towards the South, the flocks tend to get “stuck” to the Southern walls of the buildings, where they become immobile. Also, panic is able to spread through the walls. So, I guess I’ll leave fixing these bugs for Version 3.0.

AZIS 2.0 (sounds like the name of a guided missile or something, doesn’t it?) can be found in applet form at here.

Evolving Behavior

Well, since my previous posts about my various NetLogo models have been so popular, I thought I’d write another one about one my most unusual — and in-depth — NetLogo models thus far: one to simulate the evolution of behavior.

This particular simulation sprang from a desire I’ve harbored for a long time to create “digital organisms,” as Wikipedia calls them: organisms whose behavior is controlled by internal programming instructions, which evolve over time in a simulated environment. Of course, it’s notoriously difficult to both manipulate text and run it as program instructions within a programming language (at least for me), unless you’re willing to code a mini-compiler within your program, but nonetheless, I thought I’d give it a try.

As it turns out, NetLogo already comes with a built-in method called run. When called with a string as its argument, run interprets the string as it would any other stream of NetLogo commands. Given that, and the elegant modular simplicity of the NetLogo language, it seemed that even a merely casual programmer such as myself might have some chance of building a digital-organism simulator.

Thank goodness for one of NetLogo’s other commands, namely, carefully. Carefully has two arguments: an instruction to run, and a procedure to run if that instruction causes an error. With that in mind, and NetLogo’s modularity, I threw together a simple list containing a handful of symbols (such as “=”, “if”, and “+”), as well as the names of a few methods I’d pre-coded myself (methods that tell the organisms to do things like “eat” and “reproduce”). I had to do the latter because, the only way I could get around the errors that carefully would otherwise cause, at least for the time being, was to make any error-producing organism die immediately. After some fiddling to make the program-mutation procedure work properly, and to fix some other stupid little errors, I finally managed to get it to run. Here is a sample image from the result:

Those little labels you see hovering over each organism are the organisms’ programs. As you can see, they’re neither very varied or very complex. I had hoped to evolve the organisms into greater complexity (note: all of the methods you see here are not built-in to NetLogo, but are references to methods I coded myself. I did this for the sake of simplifying things a bit, and for “chunking” the program, so that it was less likely that a mutation would break the code, since the NetLogo language isn’t terribly mutation-tolerant, I discovered).

Over time, unfit programs died out, and the more fit ones reproduced. After a fairly short run-time, I got this:

Notice how the organisms all have essentially the same code. This is an unintended side-effect of the fact that I spawned so few organisms at the beginning of the run, for the sake of visual clarity. Although, I have noticed that a lot of my randomly-instantiated populations tend to do the same thing, in all of my evolution simulations: most of them will prove unfit, so the world will end up being populated by a group of genetically-similar descendants of the few highly-fit originals.

I let the model run for a little while longer, knowing full well (from other runs) that it wouldn’t do what I was hoping. Apparently, I didn’t make the environment complex enough, or the selection process harsh enough, to necessitate the evolution of interesting programs. The fact that interesting variations almost always die out — since even a misplaced parenthesis or bracket will cause a syntax error, which, as I said above, automatically results in the organism’s death — sort of selected against novel programs. What I was really hoping to see were some strange loophole exploits or programming workarounds (for example, an organism that, say, re-set its own energy level so that it wouldn’t have to trouble with actually eating food) of the kind that I talked about in my previous post “Unexpected Consequences”. What, instead, I ended up with, was this:

(For the sake of readability, I’ve only printed the program of a randomly-selected ten organisms.)

As you can see, every organism has essentially the same program. Oh well, I guess that’s a problem to be tackled in Version 2.

Here are some of my goals for the next rendition:

• Streamlining of the code: When there are more than about twenty-five organisms, the simulation slows waaay down. I don’t know if there’s a way to execute the organisms’ programs faster, but I’ m hoping that I can figure something out.
• Make the programs less fragile: The main roadblock to interesting programming variants is the fact that any “broken” code dies immediately, rather than, perhaps, getting repaired. Figuring out how to do that is going to be complicated, but it seems that every time I think I’m not going to be able to do something in NetLogo, I still manage.
• Make the environment more complex: as it is, the organisms are only competing for two things: energy, and, to a much lesser extent, space. I’d like to see if I can make the space-competition harsher, and perhaps introduce some new resources for them to compete over, such as mates (the current version uses asexual reproduction, since I didn’t want to bother with the nightmare of trying to prevent errors in sexually-combined programs).

More later, as events warrant.

Zombie Infection Simulator

Yesterday evening, as I was wiling away some hours at the computer, a thought struck me. I realized that my knowledge of NetLogo has finally reached the point at which I could build something I’ve wanted to build for a long time: a simulation of a zombie outbreak. Ever since I saw the cool simulator on this page, I’ve wanted to build my own version in NetLogo, but I’ve never been competent enough to program it. Now that I’ve got some experience under my belt, I was finally able to pull it off.

Here are the basics:

• Humans show up as blue dots. They walk at a leisurely pace, and flock together with other humans.
• Panicked humans result whenever a human sees a zombie or another panicked human. Panicked humans run faster than normal ones, change directions more often, and don’t flock. If there’s nothing threatening about, and the general panic level has died down, they turn back into normal humans.
• Zombies are green. They lack any sort of intelligence and wander around randomly. If a human gets too close to them, they may attack, resulting in infection.
• Fighting humans are humanity’s only hope to resist the zombie hordes. They show up as yellow. Fighters flock together with other fighters, and also seek out any zombies nearby. They also have a rallying effect. That is, they have a tendency to make panicking humans calm and urge calm humans to fight. Sometimes, fighters break under the strain and panic, or, if there are no immediate threats, they go back to normal.

These rules are fairly simple, but I’ve been working with StarLogo and NetLogo for long enough now to know that emergence can perform feats of magic with simple rules. And I did indeed get some fascinating behavior.

As I toyed around with the simulator, I discovered the importance of scaling. With a small map and a large population, the behavior seemed to resemble that one might find in an urban setting, and as the map size increased, the behavior seemed to be more like that of a county or a small country, with the groups of humans representing cities, or something to that effect.

The first run I did for this post was an urban one with an initial human population of 300 (THIS IS SPARTAAA!!! Sorry…couldn’t help myself.)

The humans have organized into “flocks”. For some reason, there seems to be a bias that causes them to favor moving down the map, rather than in some other direction. I’m still trying to fix that particular bug.

Now the fun part begins. I cause one human to suddenly become a zombie, and the infection starts. All the people nearby start to panic, except for a small group of renegades who become fighters and start hunting down the zombies.

As the epidemic begins to grow out of control, panic spreads throughout the “city”. Groups of fighters attempt to rally the panicking citizenry, but their efforts are for naught, as the growing zombie horde continues to inspire panic.

Groups of fighters still try valiantly to keep the infection under control, but it’s already too far gone. By this point, social organization is beginning to decay.

As the situation continues to spiral out of control, social order breaks down, and humans stop forming flocks. Groups of fighters are overwhelmed on every front.

It is the end of days (well, at least the end of the “city”). There are few humans left, and those survivors are panicked and running for their lives. Note the single fighter still trying to kill zombies. Unfortunately, this is not an actual zombie movie, and so there’s pretty much no chance that a ruggedly good-looking male protagonist is going to rally a ragtag group of comic-relief-spouting survivors and save the day.

This program is incredibly fun to play with, and I’ll put it up for download as soon as I get around to it. In the meantime, I’ll do a larger run, one that represents more of a “nationwide” zombie epidemic. But since, for some reason, this simulation is pretty CPU-intensive, it’s going to take me a while to get around to running that one.

Many thanks to Kevan Davis for the inspiration for this simulation!

And, once again, many thanks to the makers of NetLogo. I know it sounds like I’m on their payroll or something, but NetLogo really does make programming multi-agent simulations pathetically simple.