Codebase: ActiveWorlds 4.1
The ActiveWorlds codebase is designed to offer a foundation for graphical multi-user worlds. Traditionally used for mostly static worlds, the 4.1 codebase marks a clear turning point away from that.
Uniquely, ActiveWorlds codebases have two different modes which can be applied:
ActiveWorlds is not a perfect codebase by any means, and it has stark limitations which will frequently annoy. Whilst progress is made from version to version, that is ever present, as no version has all the features you would like. However, it does provide a solid basis for simple graphical worlds, including the wrapper program, and all back end services.
Stability of ActiveWorlds based worlds was not an issue in the past; the codebase was surprisingly adaptive and dealt with a variety of networking and software faults internally. That is not the case with 4.1, which is more or less a scratch rewrite. At time of writing, 4.1 is on offer to the general populace, and yet it still feels like a beta version.
The client crashes out sometimes with MFC virtual function conflict errors, which suggest internal error checking is somewhat sloppy, and possibly a little rushed. If you lose connection whilst in an ActiveWorlds world, it will not pick up your connection has re-established, unlike previous versions. It also has an annoying tendency to pull you to the help world when you first log in, rather than to the world you desired, when using the Universe server set-up.
Compulsory upgrades continually pop up, forcing you out of ActiveWorlds, and whatever world you are in, to upgrade then and there. These happen two or three times a week. It certainly shows that the company are working on the issues, but does leave customer service lacking.
Brushing these concerns aside, the capabilities of 4.1 are greatly expanded, the worlds themselves load a lot more swiftly, and the graphical quality has been much improved.
Pay for Space
An ActiveWorlds world consists of a grid of cells, each 10m on a side. The number of cells your world has is determined by the 'P rating'. A P1 is four cells; at the centre you are only one cell away from the edge. A p5 is a square of one hundred cells; at the centre, you are only five cells in a straight line away from the edge - or 50 metres. Common world sizes are P5, P10, P20, P30, P40, P50, and P100. However, any size up to P32,000 will be supplied. By the time you reach that size, you are talking a medium sized country.
As you might expect, the number of cells increases logarithmically as the P number increases. The price of the world also increases in line with the P size.
Size of world is not the only cost for an ActiveWorlds based world. ActiveWorlds will charge for the number of concurrent users your world can have. The default is five, but you can purchase licenses for additional concurrent users in packs of five. Thus you can have 10 users in your world at once, or 15, 20 by the time you reach meaningful numbers for a commercial world, you are in the realms of silly money. This, unfortunately means large-scale commercial projects are best looking elsewhere.
Cells and RWX
As covered earlier, ActiveWorlds worlds are made out of a grid of cells. This grid is 2D, there is only one plane of cells. Cell corners can be raised or lowered as of codebase 3.6, allowing a crude terrain to be formed. Additionally each cell will take a separate texture file, which can be any thing you desire, or alternatively, the cell can be turned into a 'hole'. Holes function like ordinary cells, except they are transparent and you pass straight through them.
Each cell serves as a micro database with a set limit of characters. Within the cells, *.rwx files can be placed. These are scripted instructions for creating and texturing 3D objects. It does not matter how complex the rwx file is, all that matters is the filename: house1.rwx uses 10 characters, regardless of the complexity of the script that creates it.
However, once placed, the rwx can be modified by AW Action scripting which can be typed into the properties box for that instance of the rwx file - called an object.
Action scripting allows a wide variety of special effects to be added after the fact, with different instances of the same rwx file having different action scripts.
However, action scripts come with a price. This script is added to a door object to make it rotate when clicked with the mouse:
'activate rotate 0 0 15 time=1 wait=3'
This script is 36 characters long, and this adds <I>directly</I> to the cell's character count, so the more scripting you add, the less each cell will hold.
New in 4.1, ActiveWorlds vehicles or movers, are finally what other graphical platforms have had for a while - 1,2, or more person vehicles, built from a single model, which can be piloted by a user around a world, then abandoned at the destination, eventually fading out if not picked up by another person, and returning to the start location.
These movers are equipped with premade scripts that can be selected and mix and matched at will, as well as being detectable by 3rd party code. The predefined actions will enforce user-selected laws such as always stay on water, stay on land, or fly freely. All movers are capable travelling beyond the limits of a world, into the infinite spce beyond; allowing social activities en-masse beyond the world limits - especially as terrain too can expand miles beyond even the smallest world.
The one limitation movers do have, is while they are capable of leaving their home world, they can never enter another world, so whilst AW is more and more starting to resemble the VR prophecy Otherland, it is not there yet.
The second new feature, is the particle fountain. These are emitters designed to generate long streams of particles - textures, lighting effects or entire 3D objects, one after the other, with a wide range of special effects, flowing and churning.
They allow such effects as totally realistic fire, fog and smoke, water ripples and flowing waterfalls, atmospheric and elemental effects that do not, can not exactly repeat and add chaotic life to a world.
Particle fountains can even attach to moving objects to produce vapour trails or engine exhaust.
Another new feature, zones are invisible 3D spaces which allow for atmospheric effects to change in different parts of a world. They come in three flavours: Cuboid, sphere, or vertical cylinder, each sized to whatever dimensions are required. Zones allow for a completely different atmosphere inside them, than in the rest of the world. Outside the zone could be sunny, and as soon as you cross the border you are enveloped in fog, or sink into muddy brown water, 100 ft above sea level. Zones can overlap, and have designated priority levels as to which one - or a mixture - takes effect.
ActiveWorlds worlds are designed to specification, and compiled before they are given to the client. Each world has a lifespan of one year, after which a new executable is sent out, making extending the code directly, next to impossible.
All is not lost, ActiveWorlds is designed to be extended. This is done via bots.
A bot is an agent, which can bolt onto ActiveWorlds. Not as efficient as a plugin, bots use the ActiveWorlds SDK to add as much functionality as is desired, at the cost of execution speed. They are essentially external programs, which are permitted to override different aspects of the ActiveWorlds server.
ActiveWorlds is limited. Both the server and the client demand Microsoft Windows to function. Extensibility is solely by external program, and pricing is often exorbitant. Most damning of all, ActiveWorlds is not designed to be a collaborative environment, so doors opened or objects activated by one person will not have their effects seen by any other visitors.
However, all that said, ActiveWorlds is a way of rapidly deploying a VR environment. It is ideal for art projects and creative masterpieces, static backdrops and sets. The universe servers allow many different worlds with different themes and audiences to pool communities and attract visitors from one another.
Bots may be slow, and inefficient but there is a massive archive of previously made bots, and scripts to control them. All of this code and scripting is near-guaranteed to work, as the codebase is standardised.
Many friendly veterans of the codebase exist, and hang around the universe servers. Most are often willing to impart knowledge free to new users.