Virtual Seasons
This article is reprinted from my Virtual Nature blog on September 11, 2006.
The most often requested feature I recieve is to code automated seasonal changes into Fate Gardens plants. Landscapers want trees that grow, through a lifespan, quickly in the highly accellerated time sense of a virtual world, while displaying arbitrary seasonal changes. There are no seasons in Second Life so the timings must be randomly assigned. Many requests include a phoenix-like death sequence of lightening, flames, a charred stump and rebirth.
The most confusing aspect of such a request is that we can all build what we individually consider to be an ideal environment inworld. Adding a random element, programmed by somone else, that can radically change the overall surrounding, seems an odd notion to me. But it also begs the point of why we strive to produce the presense of natural wildness in a virtual, ideally improved, or “better” environment. Will the next request be mosquitos flying around randomly biting avatars and periodically terminating their accounts?
My background, education nor experience grant me a clear answer to the human perspective. However I can address some of the practical points of the programming. The primary difference in real world nature and virtual world nature is the number of processors supporting the mechanisms. In the real world, each plant and animal contain their own timers and code processors. In fact, each organism maintains a copy of their inherent programming and multiple processors to execute that programming in every single cell. In a virtual world, everything that happens must be calculated and conducted by a single processor or, at most, a very few. Adding timers for seasonal changes and random movements can easily place a tremendous strain on a system already busily shuffling data for thousands of static objects and the constant updates imposed by avatar movement and user initiated commands.
Taking a lesson from the real, “not better” world, the obvious answer seems to be process distribution. Our Second Life clients currently process such elements as prim flexibility on the GPU in the local PC. If scripting processes, such as timers, can be executed locally, and allowed to issue update commands to the servers periodically, a good portion of the overhead will be transferred. No more appreciable bandwidth will be required. Security will not have to be an issue if the system only allows a script, operating on the server, to initiate a timer in the client and if the resulting call back to the server is built into the client and non-negotiable. Essentially, the client will tell the server to do something in the same way it does when we select a menu item. The client can even calculate its own random timing. The sim can then simply sleep a script and waken it on queue without having to operate another local timer or random generator.
Another technical concern is the processing of movement, especially the random wanderings of virtual fauna. Again, in the real world, each animal moves under its own power supplied by its own method of ingestion and digestion. This is not so easily distributed not because it’s difficult to code, but because it requires that we accept that our world views may not duplicate each other. Consider a camel placed in a Second Life sim as a virtual virtual item. Virtual virtual simply means that each present avatar client downloads the camel settings and the movement script then begins moving the camel around using its own local processes and data. The camel may wander north in my client but west in someone elses. This is truly random virtual nature; but it’s not the same for everybody. People have a very hard time adjusting to such an idea. Philip Rosedale calls it “tripping on acid.”
A slightly modified version is to allow one of the present clients to calculate the movements and signal those bits of data to other present clients. At that point, the fear of differing world views is replaced by the fear of other people’s clients talking to my client. It’s no more “intrusive” than using music sharing programs, playing pier-to-pier online games, or running web applications using java scripts that use cookies as distributed storage devices. But the perspecive when we’re browsing a virtual world, and staring people in the face, is that any access their client has to ours is intrusive and wrong. So we’re back to people finding it very hard to adjust to such an idea.
Still one wonders if the demand for automated seasonal changes and life-like virtual fauna will result in Linden Lab finding ways to sufficiently distribute simulator processing to accomodate us. There may be enough consumer request for it now to chart the effort in the black. Perhaps if we can express the need all at once, the mass will reach a tipping point and get someone’s attention.