|
This is currently a work in progress, and may have more detail added and significant changes made. The idea behind what you're seeing is simple. It's a world similar to ours, but it is not ours. It contains people, but not humans like us. They're a simple folk, only about 2 feet tall and hairless. And unlike us, they have a big problem with the dead rising from their graves. In fact, the undead tend to account for nearly as large of a population in this particular land. Like our world, days are 24 hours long, the summers are warm, the winters are cold, and there is a single moon. Unlike our world, the moon has only an 8-day cycle, and a year is only 45 days... together that means that there are 5.625 lunar cycles per year. Thus the people consider a month to be 9 days, and there are thus 5 months in a year. Also, their planet is pummeled by significant meteorites every few days. There are some basic differences between the two species that are battling for territory in this world. The Living prefer daytime, as well as clear and warm weather. The Undead prefer the dark, and like cold and rainy weather. Because of these things, there may be weather-related advantage bonuses awarded to one side or the other. These advantages can be cancelled by it being the wrong time of day. The advantage is subtle, but real, and in some cases may tip the balance in one region or another. Sometimes the Current Weather and the Forecast will not agree. This doesn't mean the forecast is wrong. Remember, the weather changes as a gradual curve, and the "Current Weather" is showing what it is at this precise minute of the day, whereas the "Forecast" shows what the weather is in the morning, near to sunrise. I guess the meteorologists are morning-people. :) Each side has a headquarters... a single castle, a bastion of hope. It's represented by a small white square in the map. The castle can not be captured or destroyed, and will always stand as a launching point for more people. The map shows the regions controlled by each race. In relation to the simulation itself, each dot actually represents one "person" that is counted in the population. Since population fluctates by the hundreds as a matter of course, it's really the number of thousands that indicates how well one side is doing. The borders are fluid and organic, and change over time. It's possible for the weather forecast to miss a meteorite strike. This is rare, and oddly enough, on such days there will be two strikes. The reason for this is that strikes are determined by interfering sine functions, and where the curve crosses zero is when the strikes happen. On occasion, the curve can barely cross zero and then back again quickly enough that to the 24-hour scale used in prediction it appears to have stayed on one side of the line the entire time.
CONCEPT AND PURPOSE I've made a variety of A-Life projects (Artificial Life) as a hobby over the years. Unfortunately they've been few and far between lately, with my most recent one being nearly 4 years prior to this one. I wanted to get back into it in a different and unusual way as compared to my past creations. The primary purpose of this particular endeavor was to create an online simulation. One that runs in the background on my server without taxing its resources, and with its only human interface being a web cgi script. Of course, it also meant that there needed to be a general concept for the type of simulation it would be that would allow for it to be open ended enough that there would be a reason to let it run for a long period of time, and yet be stable and sustainable enough to not stagnate or collapse in a short period of time. So far this appears to be stable, and require long periods of time to see any significant changes. (though admittedly, simple CA's tend to be rather predictable). It seems to have fulfilled its purpose-- a "proof-of-concept" in terms of making an online web accessible alife project of some kind, and I'll probably take it to another level at a later time.
Since this was a first attempt at writing an A-Life project completely in Perl, running on a Linux server, and with merely a simplistic web-interface, I kept it simple in several ways. The simulation itself is a cellular automata model, which took some inspiration from Conway's Game of Life. It resembles Conway's automata in that an individual cell (or person in this case) can die either from isolation or from overcrowding. It differs in that random probabilities are used to determine when a cell is spawned or dies, and the probabilities are different for differing numbers of adjacent active cells. Likewise, there are two "teams" in the simulation, each processed in a seperate iteration in which the other team is treated like blank space. This allows them to overwrite each other and constantly push back and forth on one another. Cellular Automata are always worth falling back onto, since even a simple model can display interesting emergent behaviour. For instance, it's refreshing to see a rigidly cartesian cellular system capable of generating spherical growth patterns. For those who are interested, here are the cellular state rules... A single update of the entire grid consists of two passes, one for each team. Valid cell values are 0 - 2. For each pass, the opposite team's number is treated as if it were 0. A tally of how many friendly adjecent cells is made versus how many "empty" cells are adjacent (which as previously stated, includes cells owned by the other team).
The 3x3 "castles" are treated as "always on" cells. I've written a small DOS program (will work fine under windows in full-screen) that will allow you to see in a compressed time scale how the two sides grow and spread. Since it doesn't have the weather system incorporated, you won't see as much variation, but it's still a good example. I wrote it as a "proof of concept" sort of thing, to test out the CA rules. It runs considerably faster than the online simulation for several reasons... 1) It's compiled into machine code, instead of running as interpreted Perl code, the latter of which is inefficient for maniuplating large arrays of numbers. 2) It uses a smaller map (320x200 instead of 400x300, and thus is only 53% as large). 3) The online version only does one iteration per team every 6 minutes as a cron task, to minimize impact on the other duties of the server. 4) It doesn't go back after every iteration to count population and collect other such data. Here's the program:
|
