Sunday, February 6, 2011
Jeffrey Ventrella's GenePool is pretty incredible.
The physics of movement is beautiful, the "genetic" material is satisfyingly crunchy, and the experience of watching tiny "dramas" unfold is far more fun than El-Fish, though it is similarly soothing and pleasant to watch. Bots experience different types of selective pressures: natural (dominated by the bots' ability to actually reach food), sexual (interestingly, the bots are by default attracted most to those which share their own colors, but this can be changed), and artificial (you can save a bot's genotype to disk and do stuff like drag them, or food around, to ensure their survival. I'm guilty of saving a few inept but charismatic ones this way). As far as I know, this is the only artificial life simulator to include sexual selection (maybe you know of others?)
Given that evolution can be a difficult concept for students to grasp, I can imagine great benefits from inviting them to watch it actually happen in a framework like this.
Thursday, February 3, 2011
While playing it, I did feel a sense of panic when a germ ambled toward one of the prey objects. But the "eating" itself passes almost unnoticed (a little blood is in order). This is just one example of how this project lacks satisfying visual, auditory, and tactile feedback.
Maybe a bigger issue is that it's poorly tuned. The game has only two stable states, and so it's easy to run out of antibiotics and watch the game field become totally overrun with germs. It is actually the complete opposite of adaptive difficulty.
There is also the problem of what happens when you run out of points to buy antibiotics - since points are awarded every second, but the antibiotics are purchased each frame, there is a strong "popping" effect that does very little damage to the germs and also fails to communicate bankruptcy to the player.
I think what Vincent really means is not that the model itself is boring, but that the game is boring. We need to work on that.
Three months ago I wrote rather glibly that games are, by their nature, educational, and that all one need to do to capture this educational power is to replace the in-game models with whatever scientific or real-world model you were interested in teaching. If you wanted to teach evolution, then you integrate the rules of evolution into your game, and people will come to intuitively understand the phenomenon.
I'm not a game developer, but I am a scientist. It's appropriate, then, that I overemphasized the ease of integrating scientific models into games without really appreciating the difficulty associated with making the resultant game fun. My first foray into game development (my first foray which has reached a finished point, at any rate) is an apt demonstration of the problems integrating games with models.
Because I'd never completed a project before, I aimed for what I thought was the simplest possible gameplay. "Monsters," represented by round polygons, make their chaotic way from the left part of the screen to the right, bouncing off the top and bottom edges. True to the genre, the player constructs a series of impediments and offensive weaponry to destroy the incoming "bugs." These objects cost money, which is awarded when a bug is destroyed and which is lost when a bug manages to make it to the other edge of the screen. Unlike many Tower Defense games, you build and defend at the same time, and can place a new object at any point in the game. When you run out of cash, the game ends.
How is evolution integrated into this basic framework? Well, each pathogen has four "force fields" around its central core, each a distinct color. The four colors represent different antibiotics, and the thickness of each line represents how resistant the individual bug is to a particular antibiotic. A bug with a thick green line is very resistant to the green antibiotic. If a bug has a very thin red line, its very susceptible to the red antibiotic. I've assumed that there is an energetic cost associated with maintaining each resistance, so a bug cannot be highly resistant to one antibiotic without decreasing its resistance to the others. This is meant to represent the actual costs of maintaining resistance for an organism, as well as the tendency for genes which are not actively selected for to deteriorate by natural mutation. The impediments and offensive weaponry are also each loaded with a different mixture of antibiotics. The amount of damage a cannon does against a bug is based on the strength of the dose of each antibiotic that cannon is loaded with adjusted by the resistance profile of the individual bug. Likewise with "bandages," which slow bugs down and deal damage to them as long as the bug overlaps the bandage. The medical metaphors wear quite thin, I admit.
When a bug makes it to the other side of the screen, in addition to costing you some money, it enters the reproducing pool of bugs. Every three minutes or so, the bugs in this pool undergo virtual cell division, each producing new offspring with slightly different immunity profiles. These bugs then join the march of bugs entering the screen on the left.
Finally, the player is allowed to adjust the dosage she is using to fight the bugs off via an in game menu. The hitch is that drugs which are particularly effective (calculated by examining the live bug pool) are more expensive than drugs to which most bugs are resistant. The intent is for the player to have to manage both the resistance profile of the bug population and the cost of buying effective drugs. It seems like a relatively elegant model, in my mind.
There is just the simple problem that the game is incredibly boring.
Let's break it down.
First, the game is highly abstract, so immediately upon starting the player is greeted with a little animated "battle field" upon which nothing is obviously controllable directly. I've recently added a small in game tutorial text which gives instructions, but I think the take home lesson is that players want to interact immediately. A surrogate for this is an engaging set of instructions, perhaps already embedded in the game's metaphor. But its better to let the player run to the right.
Next, the whole game model (beyond tower defense) is actually pretty complicated. Even though we are able to explain it clearly in a few paragraphs, the game itself is remarkably uncommunicative about how things work. For instance, how are we to know that there is even an economic model at work for drug prices? The in game tutorial tells you that, but how does the game show it? How are we to know that the bugs are reproducing (besides a little message saying so?). Part of this could be remediated by the inclusion of more visual indicators of game state. A persistant measure of the average bug immunity in the corner of the screen would probably help, along with a representation of the "survived bug breeding pool" where offscreen bugs milled around more and more excitedly before reproducing, perhaps one by one.
But this would be polishing on an essential flaw in the game design, which is that the model is out of temporal sync with the game. Tower Defense is a coffee break game. You play for ten minutes at a time, and I don't think most people devote much attention to it. It is just barely a game, in a way - you set up your little defenses and then sit back and watch. Evolution is an incredibly slow process, even in the abbreviated and form that its presented in Biological Tower Defense. I'd imagine that it would take upwards of 20 minutes for interesting variability to develop in the bug population. It's hard to imagine someone with the patience to play a game with so few rewards and so simple a system for so long.
DF is paced for long play, and so the model of evolution, which is based roughly on Mendellian discrete gene inheritance, fits naturally into the gameplay. If you want to build muscular guard dogs, you set some dwarfs1 to the task of killing all but the strongest dogs each generation2, and then go about your other business. In 20 minutes, which might be 10 dog generations later, you've got only big dogs.
There is obviously a lot else to learn about games and models, but I'd like to leave off with two simple ideas. The first is that the game has to provide an entertaining context for the model and the second is that one way to do that is to make sure the model is "paced" at around the same speed as the game. Otherwise, the player will struggle to even notice the model is there.-V