New Land and some thoughts on Software Architecture … (09/04/09)
So I now own 1/8 mainland sim (8192 sqm), plus a couple of small extra-prim parcels on the same sim. I have a total of almost 2000 prims to play with.
here it is after a bit of landscaping …
I chose this land because it is on a quiet sim with not many scripts running and it has some water and some land on a range of levels. One of my extra prim parcels (96 sqm) is next to a Linden road (unbuilt). I may put a teleporter there and an information point with notecards, images, landmark and web links.
The next question is, what is my "fair share" of script resources?
The ecosystem is going to use a LOT of scripts so I need to work out how to script it as efficiently as possible. It's quite difficult to find straight information on this as all the advice is that it "depends". One bad script can cause as much of a problem as 100 good scripts, mono is not always the best way to compile. Listeners and sensors can be "bad" but they are essential for communication between creatures. I am on the mainland so I have neighbours to think about and have fewer tools to inspect script performance than if I was on estate land.
Why this is important
- sl scripts can be a bit flakey at the best of times. The simpler and more efficient I can make mine the less chance there is that they will malfunction.
- if I lag the sim I may get complaints, AR's, my stuff returned or in the worst case, a ban.
- sl are introducing parcel limits for script memory. If I don't sort this out my stuff may poof when this is introduced.
- I just want to be a good neighbour.
Things to consider
- number of scripts: although it's not the most important consideration, it's somewhere to start. When I was looking for land, I decided that 4000 scripts on a sim seemed to be about as many as you'd want. It's a bit arbitrary, but that seemed to be a high average for the places I looked at. So, based on that, my "fair share" would be 500, more or less. Working from this I am able to make a guestimate of the maximum number of creatures to have in the system…
- script time: This is very important, and the best measure of lag. - llGetScriptTime could be a useful tool, but I don't yet know what values I should be aiming for with this many scripts running.
- script memory: This is also very important, especially as LL are going to limit this by parcel in the near future. If I understand correctly, I should compile to mono if I am using multiple copies of the same script with the same UUID. This way, all the copies can share script memory. This would seem suitable for the creatures' scripts. Where I have only one copy of a script, eg. the HTTP request script, it might be better not to use mono unless it speeds things up as mono scripts use more memory per unique script.
- states and events: lsl is structured quite differently from other scripting languages I have used. I am assuming that if I use states and events well it will minimise lag, so I need to learn more about this.
- listeners and sensors: I need to make sure these are switched off when not in use. I need to minimise the number of these that are running at any time.
- script range (96m): Is anything to be gained by hiding the non-creature scripts way up in the sky and using llRegionSay? I could use this as the main listener and turn on and off listen channels with various creatures/species from here when the creatures request one.
- where to put which scripts. As well as the creatures' individual scripts I need a way to keep tally of how many creatures there are, a store for "energy" which is not embodied in the creatures and a script to communicate with Pachube. The biggest challenge is the energy store. It has to keep full control of the amount of energy in the system as well as get the energy out to the creatures which need it. Where the energy points are sent will influence the whole physical shape of the system.
Up to date project description (19/02/09)
For my main project I am making an interactive art installation based around a programmed ecosystem. The system is influenced by a variety of sources of data, including feeds from a weather station installed at the college. Populations of virtual organisms will inhabit a Second Life environment where they will form a complex adaptive system. Footage of the Second Life environment will be screened or projected into the college space and video of the real life college environment will be streamed back into the Second Life installation.
Audiences at the college and in Second Life will also have some influence over the system, but just as in real life, it may be difficult for them to tell exactly how they are affecting the environment through their actions.
Visual interest in the ecosystem will be generated by populations of species and by interactions between species, producing emergent effects such as flocking, population cycles and symbiotic relationships. The system will be calibrated in such a way that very subtle changes in data will be capable of producing dramatic effects throughout the system. I aim to produce something that will be visually interesting regardless of knowledge or understanding of the processes at work, while at the same time providing enough information for those who wish to explore its workings more deeply. My target audience ranges from babies to biological scientists.
This project sits at the intersection between interactive art, a-life science and data visualisation. It seeks to explore the nature of life and of life-like processes as a source of creativity, along with notions of authorship: to make an a-life artwork is to highlight the paradox of “playing god” (the ultimate in authorship) by inventing virtual lifeforms, while simultaneously stepping back and allowing a system, over which one has only partial control, to author the work.
Older stuff
My Big Idea
Sketchbook Pages (pdf)
Some thoughts since I wrote that …
- I am now thinking of using the economic crisis as a source of data. With this in mind, I would like to build a simple web-based "thing" to explore ways of visualising this data ASAP - while it's still in turmoil!
Project Description - updated 30 October 2008
a more detailed Project Plan
Research to do …
- find out what data is publicly available, including refresh rates …
- find out how to import this data into another programme, e.g. Processing
- have a look at what others are doing
Possible data flow diagrammes …
This PDF slideshow succinctly explains a lot of the issues I am interested in:
