In the “zone” and feeling moody
One issue with a “world” is the global settings – particularly lighting. Now if you are outside, this is fine, you would consistently want the sun/moon in the one place [although a multi-sun world might represent a challenge still]. The ambient light [that which generally soaks everything non-directionally and the directional light that originates from the major light source [the sun] as a global setting lets you pick intensity, angle and colour. These effect objects differently using the SUBTRACTIVE colour model – let me explain.
We see objects in the real world as a particular colour because the surface of those objects are reflecting THAT colour light into our eyes. A red shirt looks red in white light because white light contains some red – the shirt absorbs all but the red which it reflects and we see it – got it? In-world objects have colour schemes also – if the grass, for example is to be seen as green, then there must be some green in the directional or ambient light, else it will not appear green. Lighting in a virtual world [activeworld and secondlife] model this same system so some interesting moods can be created and commonly recognised objects can take on new qualities if illuminated using different colours to those it would naturally appear under white light.
… however
If you create a chamber, with a roof and solid walls, say, the world light settings seep through and plainly illuminate the inside space just like it is doing the outside – this is weird to say the least.
Zone object being placed
Activeworlds combat this issue by allowing you to create zone objects [rectangular prism, cylindrical and spherical] that let you apply local settings. In the above illustration, I have created and sized “red zone” to fit inside my airlock [but have yet to lower it in place]. Its ambient and direction lighting gives the user a feeling of being de-contaminated – red and dangerous looking. I also changed the local friction and gravity in this zone so it behaves like it is viscous to travel through. Similarly, inside the dome, I made a large spherical zone that filters outside light and lets my local lighting do the job it was placed to do.
So what? Zones will be very useful – we can make “holes” through our landscape but the global water table is just below the surface which by default means all stuff below that is full of water. To make a subterranean [or indeed a submarine or some breathable space below surface] you surround it in a zone that excludes the water and presto. Zones will let us make detailed and moody interiors as well which will greatly add to the sense of space.
Ground detailing and second floor
With a simple concrete “plinth” in place, the dome looks a lot more like it belongs there [a narrow collar would also help from an engineering perspective given the inside struts etc – the beauty of a virtual world however is that the rules of building are not restricted by the forces of gravity or tightly bound to the laws for physics, popular culture or bad taste so we can get a little liberal with the building regulations depending on the culture we are depicting. I floated a second floor donut [well, technically it is a torus, but it is near lunchtime so donut is fine] as a circular viewing gallery – I will re-wire the lift to take you up and down I think and it might be useful practise plotting waypoints.
I added some programmed light sources to see if I could [I wonder how often exploration is justified for “shits and giggles”] and we start to get a feeling for the place. Above the the outside airlock there is a red light – when you activate the door, the door tells the light to go green [to indicate all is ok to enter]. When you travel beyond the threshold of the door it closes and changes the light back to red. I will leave my magic carpet parked outside, but might see if I can find a Dalek exoskeleton to travel around in [I am a geek if nothing else 😛 ].
Movers and shakers
I am working on a bunch of ideas, but common things like “airlocks” and doors are the first to get a guernsey. In our homebase, we will need airlocks – little intermediary chambers in between sectors.
An airlock with an "activate" pair of doors
There are a bunch of building primitives, so i made an elongated tunnel, purloined a “fence” segment [looked sort of industrial] and programmed it to slide down on activation – nothing new here. In the production airlock there will be a wall-mounted button to do this also, that would look more natural. It did however get me thinking about moving objects in general.
Now I have seen vehicles, lifts and other essential things in other Activeworlds, so decided it was high time I understood how these things work. It seems there are 3 “classes” of objects termed “movers”.
Server-controlled movers are objects that users ride but do not have any control over the path they take. Lifts and busses are examples of this sort of mover – you “hop on board” and initiate the trip somehow [activate = click, bump = coming in physical contact with] and the object then follows the pre-set path with the user on/in it. All movers let you “detach” yourself from them via a button-bar icon, but it would be normal to go for the full ride and have the mover detach itself from you automatically when you are safe, at your destination and most importantly stationary.
Lift via a "server-controlled mover"
There are some nifty controls available when defining these things. The movement is controlled via a “waypoint editor” – you control the world coordinate displacement in XYZ, velocity, as well as the bumpiness of the ride [rock and roll] with pitch, yaw and roll. There are some complications using “add on bump” when you try to get off the mover – each movement is another “bump” whilst on the surface of the mover which can get interesting [or less so if you do not want to re-take the journey].
The amount of control you have here is quite feature-rich and if you choose a suitable “pad” object, quite natural movements can be achieved. This sort of mover has natural applications for lifts, travel tubes, roller coasters and so on where you get on, strap in and hang on.
Magic carpet ride via a "user-controlled mover"
User-controlled movers are a lot of fun – naturally I decided I needed a “magic carpet” and decided you would need to climb on board and then click to say you were ready for a ride [and again click when you wanted to get off]. Walking [and flying] unassisted is necessarily tedious in most virtual worlds – a user-controlled mover lets you go fast and can make the journey much more entertaining. Essentially, a user-controlled mover “enhances” player movement – speeding it up, making flying much more risky – the control you have over this form of transport is fairly detailed – I had the carpet dipping and rolling, banking and flapping on tight corners, so violently in some trials that it actually flung me off when I banked too hard. It is rare that I howl with laughter whilst experimenting but this was fun – the avatar and the object are also separately configurable – this means that, although the carpet is wildly flapping underneath me, my avatar is steady … or the other extreme where you lean, tilt and get chucked about.
Cars, spaceships, skateboards and gliders are but a few obvious applications of this type of mover. The world has a bunch of cars but I could not find one in the Q2 sim that actually let me drive – it might be that the config is confusing for little kids – I am sure however we can come up with “vanilla” recipes of setting for types of vehicles.
"Pick-up" mover locations from http://wiki.activeworlds.com/index.php?title=Mover_(Pickup_Item)
The third class of mover is a “pick-up” item that is attached to some part of the avatar [as per location tags above] – they are similar to user-controlled movers except you carry them around and choose when to wear them. I can see jet-packs, helicopter beanies and rocket-powered rollerblades as applications for this sort of mover. Because they are attached to the avatar, seeing them to remove them is problematic [indeed – server and user-controlled movers need to be big enough for you to see if you are relying on using activate to use them]. These become active when you attach them to you or hold them. Will play some more here when an application surfaces – they do not appear that different to user-controlled movers to warrant time now.
So what? I can see movers being very useful – transporters between locations, walk-through and guided tours of facilities, personal transportation and a bit of fun – if an oldie like me gets the giggles trying to hang on on a magic carpet ride, then I think our punters might like it also – especially if they can make and configure them themselves. Races take on a whole new meaning if you limit their speed setting but let them play with other parameters and get them to take to an obstacle course.
Ready to Rok
So I was determined to play around with sound in-world…
A Real Rock Band
and built a rock-based apparatus [this is, after all, Rockshop 101 in da Henge, man] and experimented with the “noise” command and the “sound” command which, on external appearances seem quite similar.
Both trigger samples [wav, midi or mp3], but in different ways.
Using “noise”, you can trigger it, by activating an object, say, [clicking on it] – you can wait until it finishes playing before you click on it again, or you can use an “overlap” parameter to let many concurrent noises [including multiple copies of the same one] play until they finish. In no time a wonderful cacophony results from overlapping samples.
So … I embedded the following script in one rock:
activate noise http://www.wonko.info/wOnKoBUZZ/samplesRus/percussion/drums/bigconga1.wav overlap
then chose other sounds [from my own online sample collection] for the other rocks, and a nice long sample for the big rock. I even did a dodgy flash capture [the sound quality is a bit mashed]: RokandRoll Flash Capture
The SOUND command is a bit different – there can only ONE sound playing for each citizen, that sound comes from the sound-enabled object closest to you. Nicely, that sound is “spatial” in that it appears to come from the direction the object emitting the sound it which is nice. You can LOOP but I have yet to work out how to programatically STOP the noise [I can go to the menu system and stop it there, but I am sure there must be a command that lets me do this].
I changed the “activate” script for the big rock to:
activate sound http://www.wonko.info/UoD/objects/aural/UoD8.mp3 noloop
and now when you click it is directional – as you walk around, it moves in the stereo picture [left to right], not yet sure of the range though I notice that the volume increases as you get closer and diminishes when you move away – nice for creating ambient noises and atmosphere, although I suspect it impacts a little on the bandwidth as the sound downloads before it starts playing [unlike other technologies that can stream it as it arrives].
The sound/noise can be from any accessible URL – I am hoping the new proposed “Mytunes” upload and share thingy that The Learning Place are developing will have sufficiently exposed URLs of the sounds stored in it so that we can link to them in-world – that way juke-boxes and other interactive sound-art is possible.
Imagine, building a sculpture and linking it to hand-made noises – audio performance art harnesses a number of intelligences [and is a lot of fun]. More practically, things like buttons [that need to sound like they have been pressed], doors that creak as they open, water splashing as it falls and so on are now all possible – this is a good thing if we are to create a sense of place and immersion.
Rockshop 101
One of my favourite authors of all times, Douglas Adams, once coined an expression encapsulating the basis of evolution – he said “The secret is to keep banging the rocks together guys”.
I love this sentiment – chipping away at stuff that is not clear to seek clarity; being accurate to seek accuracy … thank goodness my brain is still accommodating enough to let me learn new stuff. So I delve [all be it tentatively] into the murky depths of object scripting for the first time …
wonko-henge, rockshop 101
So I needed a workshop, and found a collection of rocks in the standard object bin, so decided to partially construct WonkyHenge so I could sacrifice things in the name of the new deity – knowledge.
My mission was to begin to explore object scripting, because that is where the smarts of an interactive environment will lie. Deftly I delved into the object properties and in minutes was scaling objects in X, Y and Z, easy peasy.
To something new…
Actions are applied in the object properties
There are a number of things an object can “detect” – events for those of you familiar with event-drive, object oriented programming. The “Create” event is useful – you can tell the object to do stuff when it is first rezzed [encountered] by a player – useful for size, initial appearance etc. Scripts can be “stacked inside the action field
command; command; command or
command part, other part, other part; command part, other part etc.
Annoyingly, a de-bugger is NOT present, so if there is even ONE error in the script, none of it works and you get NO error message, no on-screen display [and oddly sometimes your object even disappears into an unreachable place], nothing except a non-working object [if you are lucky]. From a noob perspective this is fine because you do not get beaten up as normal programming/scripting languages do with pages of indecipherable error codes … but, some feed back would be nice.
programmed movement - translation in 2 axes - doors etc
When an object is “Activated” [left clicked on], it knows – you can get it to do stuff when it detects such a click – very useful. The first thing I tried was the “move” command.
activate move -2 2 0 noloop time=5 wait=3
= when clicked on, move backwards 2m in the x direction, up 2 m in the y direction and do not change your z position, do this thing once, take 5 seconds to do it, wait 3 seconds before un-doing it.
Nice, slidey-door [think star trek, and an accompanying and very satisfying “wooshing” sound] sorted. Automatically translating objects is nice, fairly easy to control and it can be done on create or triggered by a click also.
A programmed rotation "onclick"
Translation is not that dissimilar in concept to rotation, except the controls that Activeworlds use are a little interesting [different from what I was expecting, but manageable]
activate rotate 0 0 5 time=3 noloop wait=3 smooth
= on click, rotate at 5 rpm on the z-axis, do not keep repeating this, rotate for a total time of 3 seconds, smoothly, wait 3 seconds before un-doing the movement at the same speed. Easy – the opening door thing sorted. Just gotta learn how to move the axis of rotation – some objects have their axes plumb centre and so a door that has a “hinge” in the middle is a little odd.
objects that "know" other objects and communicate
Objects, on create, can be named – this name can be used programatically. In the above rockshop experiment, I spawned a big rock and called it “fred” – conveniently I could call other things “fred” as well – the name does NOT have to be unique in the collection of things that I create. Also usefully, a thing called “fred” that I make is DIFFERENT to a thing called “fred” that some one else makes – this is a good thing as side-effects caused by scripts someone else wrote using names you did not were already taken would be really really annoying but more importantly, very difficult to debug.
I then made 2 other rocks, and programmed them to reach out to things called “fred” and change their appearance:
activate color name=fred red
= when you are clicked on, look for objects owned by this citizen that are called “fred” and apply a red texture to them.
I rinsed and repeated to make a blue one, and added into “fred” an activate command that re-applied “granite” as a texture to it when you clicked on “fred”, itself so you can do a colour cycle and return to the base state if you wanted.
That objects can be aware and effect others is a terrific discovery [well, I say discovery, because it was for me, I know accomplished Activeworlds builders will be wondering what this dweeb is lathering on about].
I had convinced myself that the land of scripting must be pained and difficult, so was avoiding it. Having some success and more importantly finally getting what is happening, I am now eager to beaver away in the rock shop to see what else the world can let me do
I can see you quiver with antici …[wait for it] … pation…
