Using the open source code devloped in this textbook: http://eloquentjavascript.

Question

Using the open source code devloped in this textbook: http://eloquentjavascript.net/07_elife.html

I need help adapting a small scope of the project. For this question only the code discussed up until the "It Moves" section need be used. The 1 change i'd like to see encompassed would be to change: "o" BouncingCritter's to each have their own representative number rather than the "o" character. So when animateWorld(world); is called in the "It Moves" section instead of "o" BouncingCritters moving around the BouncingCritters are EACH represented by a distinct number.

Explanation / Answer

The grid that models the world has a fixed width and height. Squares are identified by their x- and y-coordinates. We use a simple type, Vector (as seen in the exercises for the previous chapter), to represent these coordinate pairs.

Next, we need an object type that models the grid itself. A grid is part of a world, but we are making it a separate object (which will be a property of a world object) to keep the world object itself simple. The world should concern itself with world-related things, and the grid should concern itself with grid-related things.

To store a grid of values, we have several options. We can use an array of row arrays and use two property accesses to get to a specific square, like this:

Or we can use a single array, with size width × height, and decide that the element at (x,y) is found at position x + (y × width) in the array.

Since the actual access to this array will be wrapped in methods on the grid object type, it doesn’t matter to outside code which approach we take. I chose the second representation because it makes it much easier to create the array. When calling the Array constructor with a single number as an argument, it creates a new empty array of the given length.

This code defines the Grid object, with some basic methods:

And here is a trivial test:

A critter’s programming interface

Before we can start on the World constructor, we must get more specific about the critter objects that will be living inside it. I mentioned that the world will ask the critters what actions they want to take. This works as follows: each critter object has an act method that, when called, returns an action. An action is an object with a type property, which names the type of action the critter wants to take, for example "move". The action may also contain extra information, such as the direction the critter wants to move in.

Critters are terribly myopic and can see only the squares directly around them on the grid. But even this limited vision can be useful when deciding which action to take. When the act method is called, it is given a view object that allows the critter to inspect its surroundings. We name the eight surrounding squares by their compass directions: "n" for north, "ne" for northeast, and so on. Here’s the object we will use to map from direction names to coordinate offsets:

The view object has a method look, which takes a direction and returns a character, for example "#" when there is a wall in that direction, or " "(space) when there is nothing there. The object also provides the convenient methods find and findAll. Both take a map character as an argument. The first returns a direction in which the character can be found next to the critter or returns null if no such direction exists. The second returns an array containing all directions with that character. For example, a creature sitting left (west) of a wall will get ["ne", "e", "se"] when calling findAll on its view object with the "#" character as argument.

Here is a simple, stupid critter that just follows its nose until it hits an obstacle and then bounces off in a random open direction:

The randomElement helper function simply picks a random element from an array, using Math.random plus some arithmetic to get a random index. We’ll use this again later because randomness can be useful in simulations.

To pick a random direction, the BouncingCritter constructor calls randomElement on an array of direction names. We could also have used Object.keys to get this array from the directions object we defined earlier, but that provides no guarantees about the order in which the properties are listed. In most situations, modern JavaScript engines will return properties in the order they were defined, but they are not required to.

The “|| "s"” in the act method is there to prevent this.direction from getting the value null if the critter is somehow trapped with no empty space around it (for example when crowded into a corner by other critters).

The world object

Now we can start on the World object type. The constructor takes a plan (the array of strings representing the world’s grid, described earlier) and a legend as arguments. A legend is an object that tells us what each character in the map means. It contains a constructor for every character—except for the space character, which always refers to null, the value we’ll use to represent empty space.

In elementFromChar, first we create an instance of the right type by looking up the character’s constructor and applying new to it. Then we add anoriginChar property to it to make it easy to find out what character the element was originally created from.

We need this originChar property when implementing the world’s toStringmethod. This method builds up a maplike string from the world’s current state by performing a two-dimensional loop over the squares on the grid.

A wall is a simple object—it is used only for taking up space and has no actmethod.

When we try the World object by creating an instance based on the plan from earlier in the chapter and then calling toString on it, we get a string very similar to the plan we put in.

this and its scope

The World constructor contains a call to forEach. One interesting thing to note is that inside the function passed to forEach, we are no longer directly in the function scope of the constructor. Each function call gets its own thisbinding, so the this in the inner function does not refer to the newly constructed object that the outer this refers to. In fact, when a function isn’t called as a method, this will refer to the global object.

This means that we can’t write this.grid to access the grid from inside the loop. Instead, the outer function creates a normal local variable, grid, through which the inner function gets access to the grid.

This is a bit of a design blunder in JavaScript. Fortunately, the next version of the language provides a solution for this problem. Meanwhile, there are workarounds. A common pattern is to say var self = this and from then on refer to self, which is a normal variable and thus visible to inner functions.

Another solution is to use the bind method, which allows us to provide an explicit this object to bind to.

The function passed to map is the result of the bind call and thus has its thisbound to the first argument given to bind—the outer function’s this value (which holds the test object).

Most standard higher-order methods on arrays, such as forEach and map, take an optional second argument that can also be used to provide a this for the calls to the iteration function. So you could express the previous example in a slightly simpler way.

This works only for higher-order functions that support such a contextparameter. When they don’t, you’ll need to use one of the other approaches.

In our own higher-order functions, we can support such a context parameter by using the call method to call the function given as an argument. For example, here is a forEach method for our Grid type, which calls a given function for each element in the grid that isn’t null or undefined:

Animating life

The next step is to write a turn method for the world object that gives the critters a chance to act. It will go over the grid using the forEach method we just defined, looking for objects with an act method. When it finds one, turncalls that method to get an action object and carries out the action when it is valid. For now, only "move" actions are understood.

There is one potential problem with this approach. Can you spot it? If we let critters move as we come across them, they may move to a square that we haven’t looked at yet, and we’ll allow them to move again when we reach that square. Thus, we have to keep an array of critters that have already had their turn and ignore them when we see them again.

We use the second parameter to the grid’s forEach method to be able to access the correct this inside the inner function. The letAct method contains the actual logic that allows the critters to move.

First, we simply ask the critter to act, passing it a view object that knows about the world and the critter’s current position in that world (we’ll define View in a moment). The act method returns an action of some kind.

If the action’s type is not "move", it is ignored. If it is "move", if it has a direction property that refers to a valid direction, and if the square in that direction is empty (null), we set the square where the critter used to be to hold null and store the critter in the destination square.

Note that letAct takes care to ignore nonsense input—it doesn’t assume that the action’s direction property is valid or that the type property makes sense. This kind of defensive programming makes sense in some situations. The main reason for doing it is to validate inputs coming from sources you don’t control (such as user or file input), but it can also be useful to isolate subsystems from each other. In this case, the intention is that the critters themselves can be programmed sloppily—they don’t have to verify if their intended actions make sense. They can just request an action, and the world will figure out whether to allow it.

These two methods are not part of the external interface of a World object. They are an internal detail. Some languages provide ways to explicitly declare certain methods and properties private and signal an error when you try to use them from outside the object. JavaScript does not, so you will have to rely on some other form of communication to describe what is part of an object’s interface. Sometimes it can help to use a naming scheme to distinguish between external and internal properties, for example by prefixing all internal ones with an underscore character (_). This will make accidental uses of properties that are not part of an object’s interface easier to spot.

The one missing part, the View type, looks like this:

The look method figures out the coordinates that we are trying to look at and, if they are inside the grid, finds the character corresponding to the element that sits there. For coordinates outside the grid, look simply pretends that there is a wall there so that if you define a world that isn’t walled in, the critters still won’t be tempted to try to walk off the edges.

It moves

We instantiated a world object earlier. Now that we’ve added all the necessary methods, it should be possible to actually make the world move.

Simply printing out many copies of the map is a rather unpleasant way to observe a world, though. That’s why the sandbox provides an animateWorldfunction that will run a world as an onscreen animation, moving three turns per second, until you hit the stop button.

The implementation of animateWorld will remain a mystery for now, but after you’ve read the later chapters of this book, which discuss JavaScript integration in web browsers, it won’t look so magical anymore.

More life forms

The dramatic highlight of our world, if you watch for a bit, is when two critters bounce off each other. Can you think of another interesting form of behavior?

The one I came up with is a critter that moves along walls. Conceptually, the critter keeps its left hand (paw, tentacle, whatever) to the wall and follows along. This turns out to be not entirely trivial to implement.

We need to be able to “compute” with compass directions. Since directions are modeled by a set of strings, we need to define our own operation (dirPlus) to calculate relative directions. So dirPlus("n", 1) means one 45-degree turn clockwise from north, giving "ne". Similarly, dirPlus("s", -2) means 90 degrees counterclockwise from south, which is east.

The act method only has to “scan” the critter’s surroundings, starting from its left side and going clockwise until it finds an empty square. It then moves in the direction of that empty square.

What complicates things is that a critter may end up in the middle of empty space, either as its start position or as a result of walking around another critter. If we apply the approach I just described in empty space, the poor critter will just keep on turning left at every step, running in circles.

So there is an extra check (the if statement) to start scanning to the left only if it looks like the critter has just passed some kind of obstacle—that is, if the space behind and to the left of the critter is not empty. Otherwise, the critter starts scanning directly ahead, so that it’ll walk straight when in empty space.

And finally, there’s a test comparing this.dir to start after every pass through the loop to make sure that the loop won’t run forever when the critter is walled in or crowded in by other critters and can’t find an empty square.

This small world demonstrates the wall-following creatures:

A more lifelike simulation

To make life in our world more interesting, we will add the concepts of food and reproduction. Each living thing in the world gets a new property, energy, which is reduced by performing actions and increased by eating things. When the critter has enough energy, it can reproduce, generating a new critter of the same kind. To keep things simple, the critters in our world reproduce asexually, all by themselves.

If critters only move around and eat one another, the world will soon succumb to the law of increasing entropy, run out of energy, and become a lifeless wasteland. To prevent this from happening (too quickly, at least), we add plants to the world. Plants do not move. They just use photosynthesis to grow (that is, increase their energy) and reproduce.

To make this work, we’ll need a world with a different letAct method. We could just replace the method of the World prototype, but I’ve become very attached to our simulation with the wall-following critters and would hate to break that old world.

One solution is to use inheritance. We create a new constructor, LifelikeWorld, whose prototype is based on the World prototype but which overrides the letAct method. The new letAct method delegates the work of actually performing an action to various functions stored in the actionTypesobject.

The new letAct method first checks whether an action was returned at all, then whether a handler function for this type of action exists, and finally whether that handler returned true, indicating that it successfully handled the action. Note the use of call to give the handler access to the world, through its this binding.

If the action didn’t work for whatever reason, the default action is for the creature to simply wait. It loses one-fifth point of energy, and if its energy level drops to zero or below, the creature dies and is removed from the grid.

Action handlers

The simplest action a creature can perform is "grow", used by plants. When an action object like {type: "grow"} is returned, the following handler method will be called:

Growing always succeeds and adds half a point to the plant’s energy level.

Moving is more involved.

This action first checks, using the checkDestination method defined earlier, whether the action provides a valid destination. If not, or if the destination isn’t empty, or if the critter lacks the required energy, move returns false to indicate no action was taken. Otherwise, it moves the critter and subtracts the energy cost.

In addition to moving, critters can eat.

Eating another critter also involves providing a valid destination square. This time, the destination must not be empty and must contain something with energy, like a critter (but not a wall—walls are not edible). If so, the energy from the eaten is transferred to the eater, and the victim is removed from the grid.

And finally, we allow our critters to reproduce.

Reproducing costs twice the energy level of the newborn critter. So we first create a (hypothetical) baby using elementFromChar on the critter’s own origin character. Once we have a baby, we can find its energy level and test whether the parent has enough energy to successfully bring it into the world. We also require a valid (and empty) destination.

If everything is okay, the baby is put onto the grid (it is now no longer hypothetical), and the energy is spent.

Populating the new world

We now have a framework to simulate these more lifelike creatures. We could put the critters from the old world into it, but they would just die since they don’t have an energy property. So let’s make new ones. First we’ll write a plant, which is a rather simple life-form.

Plants start with an energy level between 3 and 7, randomized so that they don’t all reproduce in the same turn. When a plant reaches 15 energy points and there is empty space nearby, it reproduces into that empty space. If a plant can’t reproduce, it simply grows until it reaches energy level 20.

We now define a plant eater.

We’ll use the * character for plants, so that’s what this creature will look for when it searches for food.

Bringing it to life

And that gives us enough elements to try our new world. Imagine the following map as a grassy valley with a herd of herbivores in it, some boulders, and lush plant life everywhere.

Let’s see what happens if we run this.

Most of the time, the plants multiply and expand quite quickly, but then the abundance of food causes a population explosion of the herbivores, who proceed to wipe out all or nearly all of the plants, resulting in a mass starvation of the critters. Sometimes, the ecosystem recovers and another cycle starts. At other times, one of the species dies out completely. If it’s the herbivores, the whole space will fill with plants. If it’s the plants, the remaining critters starve, and the valley becomes a desolate wasteland. Ah, the cruelty of nature.

Exercises

Artificial stupidity

Having the inhabitants of our world go extinct after a few minutes is kind of depressing. To deal with this, we could try to create a smarter plant eater.

There are several obvious problems with our herbivores. First, they are terribly greedy, stuffing themselves with every plant they see until they have wiped out the local plant life. Second, their randomized movement (recall that the view.find method returns a random direction when multiple directions match) causes them to stumble around ineffectively and starve if there don’t happen to be any plants nearby. And finally, they breed very fast, which makes the cycles between abundance and famine quite intense.

Write a new critter type that tries to address one or more of these points and substitute it for the old PlantEater type in the valley world. See how it fares. Tweak it some more if necessary.

Predators

Any serious ecosystem has a food chain longer than a single link. Write another critter that survives by eating the herbivore critter. You’ll notice that stability is even harder to achieve now that there are cycles at multiple levels. Try to find a strategy to make the ecosystem run smoothly for at least a little while.

One thing that will help is to make the world bigger. This way, local population booms or busts are less likely to wipe out a species entirely, and there is space for the relatively large prey population needed to sustain a small predator population.

Related Questions

Navigate

• Browse (All)
• Browse U
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.