Guide:World administration

Once your Active Worlds Server is installed and configured, you will want to start creating the virtual environment. This section recommends guidelines including choosing a theme, choosing building objects, laying out your world and managing the building objects directory.

The advantage to running your own Active World Server, is that you don't have the restrictions of building in someone else's world (such as AlphaWorld.) Anyone building within AlphaWorld must comply with the limitations of that world. Having your own world allows you to control what objects are used, who has access, and to create a world that represents your own ideas, mood and theme.

Planning Ahead

You make all the decisions about the way your world will work. These include the choice of backdrop, what artwork will be available, who will be able to build, who has access to special commands and objects, and more. When you make these decisions, you decide what the overall mood of your world will be. Take as much time as you can afford to plan things ahead! Before you start building, you should choose a theme, choose what objects and avatars to use (either the free Active Worlds objects, your own creations or a combination) and design a layout.

Choosing a Theme

Your theme depends on your overall strategy, and will both limit and guide your choices. Besides the obvious factor of who your expected user are going to be, there are some other factors which will weigh heavily in choice of a theme, including:

• The light source, which is placed at approximately a mid-afternoon slant. This governs choice of a backdrop, which is the one thing which will probably most determine your world's mood. The light source cannot currently be varied, nor can you add additional light sources at this time.
• Behavior of the "ground object." . Besides the backdrop, the look of the ground model will greatly determine overall mood. The ground can have a grassy look to it, as in AlphaWorld, or look reddish, as in Colony Alpha, or you can choose not to have a ground at all. You can have a custom ground model. For instance, some worlds have a lumpy ground and others have a almost transparent ground object. However, your normal choice of ground will probably be similar to the ground in AlphaWorld. You can modify the ground.rwx file to make it how you want it.
• Performance. A typical world in the Active Worlds universe will draw visitors from all over the Internet; thus, you can expect your visitors to have access to wide ranges of bandwidth and CPU power. When designing a world for use on the Internet, you should keep in mind that your "typical" visitor probably has a 56K modem and a mid-range PC. This means you need to keep the total number of objects and files required for your world under control. If you cram your world full of too many huge files, most visitors will leave before the world has even finished downloading. You should use the same discretion that applies when designing web pages: keep the total download size as small as possible and more people will visit and enjoy your world.

Creating Building Models

Before you start making the objects, it is important to think about your overall goals. If you are going to open your world to building by many different users, you must plan even more carefully. You can expect that some of your visitors will devote a substantial amount of time to building in your world, and if you make changes after they start they may be very upset that the look of their constructions has changed unexpectedly.

One limiting factor is available memory. Each texture you use in your world can take up anywhere from 32K (for a 128 x 128 texture) to half a megabyte or even more (for 512 x 512 or larger textures). Also, animated textures such as the flame in AlphaWorld can take up many times more than that (since each frame in the animation is stored as a separate texture.) Keep in mind that some of your visitors may only have 4 or even as little as 2 megabytes of total texture memory available on their video cards. Texture memory is always a scarce resource and using too much of it can significantly reduce the performance for your visitors and reduce the likelihood that they will ever return again. So, always try to use the smallest texture necessary for the job, and re-use the same texture on different objects wherever possible (a texture used many times in different places only needs to be stored in memory once.)

You can create a relatively small suite of building models which share a reasonably small set of versatile textures, from which just about anything can then be built. Of course, there will always be odd pieces that don't fit into any other category; for example, the two "drinks" in AlphaWorld use their own textures which are probably not suitable for any other objects. You should plan these exceptions in advance as much as possible and weigh their importance to the simulation of reality within the theme you have chosen.

Object Registry

Creating an object registry is probably the most important step of opening a world for public building. The registry file serves two important purposes:

• It specifies exactly which objects can be used for building in your world
• It specifies the dimensions of each object, so that encroachment can be enforced

For more information, see the article on the object registry.

Deciding on a Layout

Before allowing users to build, or even before you build anything yourself, consider a layout. If you want to promote traffic in certain areas, these areas should have significant construction which is worth a detour to see, or they should be easily accessible.

The most easily accessible point in any world is the default drop zone ("Ground Zero"). You should reserve a large area around Ground Zero to start with, in case your plans change later. This will be the first area users will build in, and if unregulated, they may build very densely, which can reduce performance and detract from your world's first impression to new visitors.

The layout of this central area is crucial to the success of your world. We recommend you follow these guidelines:

• The central area should give a friendly first impression, with interesting things to see.
• An asymmetrical layout for this area is a good idea; too much symmetry can often bore and disorient users.
• The central area should conform to and preview your overall theme.
• The area should not be too densly built, or require many large downloads. Users will often get impatient if they enter a new world and are still looking at mostly empty space after a minute or two.

These guidelines are also good for other areas. They are even more important to the Ground Zero area since it is the first place your visitors will see.

Designing a Layout

Think about the overall layout of your world as if you were a user coming to visit it for the first time, or someone taking a tour of it later. What would you expect to see? For instance, if you have street objects, you might want to have a main highway system in place in advance. Although streets aren't strictly necessary, they provide a way of marking off areas, and making it easier for users to orient themselves.

In order to avoid the confusion of the Web in 3D, plan where you want your teleports to be. Too many teleports, or too many areas containing them, will be confusing. There should only be a few areas containing multiple teleports.

You can split your world into smaller areas, such as commercial and residential districts, entertainment areas, etc.. But as users get accustomed to the layout, and especially if they are allowed to build, it will become harder to change anything, so make sure you put as much planning into it as possible.

There will be a point of diminishing returns after which it can make sense to just go ahead and change things. Chances are that no matter how much planning you put into your world, at some point you will find yourself desperately wanting to make a substantial change. Fortunately, we can always create new worlds; there will never be a shortage of "virtual real estate". On the other hand, just as with the World Wide Web, users do get attached to their creations and favorites, so you want to plan each world as well as you can.

Laying Out Your World

You will want to cover a significant amount of your world before opening it if user construction is allowed. Active Worlds doesn't currently allow ownership of areas per se, only of objects. This allows users to build within areas that other users consider to be theirs. If you plan to charge users by the area they want, you can then "cede" areas to your customers as they pay for them. This approach has been used successfully in worlds such as Colony Alpha.

In any case, before you open a world for construction, you should at least cover key areas, such as the Ground Zero area. You can use WALKs or their rough equivalent to cover these areas. Cover should be continuous, but avoid overlapping objects. Also, if you use a reasonably conventional ground object as in AlphaWorld, you should try to build a bit off the ground with your ground-cover objects. If you place flat objects too close to the ground you may experience "bleed through" when you view the scene from high above.

Posting Objects on the Web

When you set up a world, all of the files describing the objects, avatars, and sounds in your world will be served from a web server. You will need to choose a location on the World Wide Web for your files. A typical world needs approximately 10 megabytes of web space to store objects. If you find yourself needing much more than that it may be a sign that you have too much content in your world and that your visitors will be discouraged by lengthy download times.

You can see an example of the way an object website is set up by browsing the URL objects.activeworlds.com/aw. This is the object directory for AlphaWorld. Often the best way to understand how an Active Worlds object directory is laid out is to first examine an existing one.

Under the main web directory must be five sub-directories:

• models: the zipped .rwx and .cob files for all of your building objects go here
• textures: all textures used in your world, including masks and the backdrop image, go here. Textures must be in JPEG format and end with a .jpg file extension. Masks are stored as zipped monochrome BMP files. The backdrop image is also in JPEG format.
• avatars: the zipped .rwx and .cob files for your world's avatars go here. The avatars.dat file (compressed as avatars.zip) is also stored in this directory.
• seqs: the zipped sequence files that control the movements of your avatars go here.
• sounds: all zipped sound effects (.WAV) and music (.MID) files go here.

Note that except for the textures which are stored as JPEGs, all files stored in each of these directories must be stored in zip format, with one file per zip. You may use pkzip, WinZip, or Unix gzip to create these files. Regardless of which utility you use, the file must have a .zip extension when placed on the website.

DOS Tricks For Creating Zip Files

You'll probably add new artwork in batches to minimize out-of-sync artwork situations such as the one discussed above, and to make it easier to keep track of your changes. If you have a batch of RWX files to zip up at once, you can use one DOS command to zip them all up. For instance, if they are called wall20, wall21, wall22, and wall23, you could just type this at the DOS prompt:

   for %f in (wall20 wall21 wall22 wall23) do pkzip -a %f %f.rw

   In this case because of the similarity of the filenames, we can simplify even more:

   for %f in (0 1 2 3) do pkzip -a wall2%f wall2%f.rwx

   You can use a batch file to automate this further, but use %%f instead of %f within the batch file.

Case Matters

Since URLs are case-sensitive, when you design objects be sure to always use lower case for texture names, and always make sure that all filenames (sounds, avatars, models and textures) are stored on the web in lower case.

For example, say you make an object called myobject.rwx and it contains this line:

   texture cloth1

The Active Worlds Browser client software will look on the object path for "cloth1.jpg", download it, and convert it to a texture. If the file on the web is called "Cloth1.jpg" instead it will not be found.

Creating propdumps

A propdump is an ASCII representation of all the property (i.e. objects) built in a world. Propdumps are not usually needed during the normal operation of a world server, but there are a few cases where they can be useful. The most common use for a propdump file is for moving a world from one world server to another. A propdump combined with an atdump and a terrain dump from the same world together contain a complete description of that world.

To create a propdump file for a world, simply select the world in the world list and then select Save Property... from the File menu, or right-click on the world and select Save Property... from the pop-up menu.

In the dialog box that comes up, choose a folder and file name for the propdump file. A progress bar will then appear tracking the progress of the property dump. Depending on the number of objects in the world and the speed of the connection to the server, a propdump can take anywhere from a few seconds to several minutes to complete.

The operation of the world itself is not affected by the propdump; the world does not need to be stopped beforehand. Users in the world will not be affected during the propdump.

Uploading a propdump

Once a propdump has been generated, it can be uploaded to any world. Uploading a propdump to a world replaces any property in that world with the contents of the propdump. Thus, care should be taken to be sure that any existing objects in a world are either backed up (in their own propdump) or else are truly not wanted.

To upload a propdump to a world, simply select the world in the world list and then select Load Property... from the File menu, or right-click on the world and select Load Property... from the pop-up menu. In the file dialog that appears, choose the file to load from. A progress bar will appear, tracking the progress of the upload.

As with dumping property, a world does not need to be stopped in order to upload a propdump, and it may be done while users are in the world. Any users in the world will see the old property around them being replaced with new property as the upload proceeds.

Format of a propdump file

As the purpose of a propdump is to supply a platform-independent version of property data that can be moved from one server to another, the format of the file itself is not intended to be particularly useful to a human reader. Still, people ask us from time to time what the various fields of a propdump represent. A brief description of the propdump format is provided below. However, it should be noted that Activeworlds Inc. reserves the right to change this format at any time without notice!

Each line of a propdump file corresponds to one object in the world. A typical line might look like this:

105 1145108945 3877 475 58999 450 0 0 4 11 0 0 42 motonorider0001f88507000000000000000000000000320a1e78640000000000000000000000000000000000000000

The first column gives the citizen number of the owner of the object. The second column gives the time the object was built, in "Unix" time (seconds since January 1, 1970.) The third, fourth, and fifth columns give the x, y, and z positions of the object, in centimeters. The sixth, seventh and eight columns give the yaw, (y-axis rotation), tilt (X-axis rotation) and roll (Z-axis rotation) of the object. Note that this rotation is actually expressed in degreeds times ten. So, if an object has a yaw of 905, then it is really rotated 90.5 degrees.

The ninth, tenth, and eleventh columns are the lengths of the object name, the object description, and the object action. Twelfth column is the length of the binary data attached to the object.

The final column is the actual contents of the name, description, and action concatenated together, followed by the binary data in two-digit hex format. So, if the binary data is 42 bytes long (as in the above example) then there will be 84 total hexidecimal digits in this last string. This binary data is used by particle emitters, zones, and movers to contain the options for that object.

Server propdumps

It is also possible to generate propdumps of an entire world server, using the separate propdump utility included with the server installation. To generate a propdump in this manner, the server process must first be stopped. A propdump might then be placed in a file using the following command:

propdump > propdump.txt

Propdumps generated in this form are generally only useful for reloading again using the propload utility. There are really only two possible situations in which you might want to do this:

• When an entire world server and all of its worlds are to be moved to a server on a different OS platform (e.g. from Windows to Unix).
• When the world server database has suffered some form of corruption and needs to be rebuilt.

Server propdumps are different from the propdumps described above in that they have an extra column at the beginning of each line denoting the world that each object was built in (since world servers can contain multiple worlds.)