|
|
|
|
|
Creating an Active World
|
Once your Active WorldsServer 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 WorldServer, is that you don't have to conform with the restriction imposed in AlphaWorld: these restrictions have to do with choices Worlds Inc. made in building the first virtual reality world with Active Worlds. Anyone building within AlphaWorld must comply with decisions made by the AlphaWorld team. Having your own world allows you to control commerce and access, and to create a world that represents your own ideas, mood and theme. Although Active Worlds imposes some limitations, you can override many of the choices made in AlphaWorld.
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 must choose a theme, decide on and design a layout, and lay out the basic building plan.
Your theme depends on your overall strategy, and will both limit and guide your choices. Besides the obvious factor of the target users, some factors which will weigh heavily in choice of a theme include Active World Browser's current fixed light source, behavior of the ground object, and what kinds of textures will be necessary for the theme:
The process for creating building objects is discussed in "Making Active Worlds Building Objects". However, before you start making the objects, it is important to think about your overall goals. If you allow building by users, you must plan even more carefully. Users will devote much time to building, and if you make changes after they start they may be very upset that the look of their homes, businesses, etc., has changed-even in apparently small ways.
Two limiting factors will be disk space and memory. Each bitmap texture you use for objects will take memory; since textures and objects are both cached in memory, performance can be affected drastically by using too many of either. On DOS/Windows machines the typical cluster size may be 32K, so each texture and each building model will take at least 32K, no matter how small. Furthermore, each object is stored twice, as a textured object and as a non-textured object. So if you create 1,000 models for building and a user has them all stored twice on disk, disk space has decreased by approximately 64 megabytes not including textures.
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. There will be odd pieces that are exceptions, which don't fit into any across-the-board scheme-for instance, 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.
Important: If users have building rights, they may accept small changes in texture, surface or color values later. However, make sure you are happy with the size and placement of objects before making them available for building!
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 will build very densely, which can impede rendering speed tremendously and adversely affect first impressions.
The layout of this central area is crucial to the success of your world. We recommend you follow these guidelines: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 at which it makes sense to just go ahead and do it. VRs haven't been around very long, and there are no real precedents to follow yet, so chances are that no matter how much planning you put into it, things will go awry at some point. Fortunately, we can always found new VRs-there will never be a shortage of VR space. On the other hand, users do get attached to their creations and favorites, so you want to plan each VR as well as you can.
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 is the approach used in 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 more-or-less conventional ground object as in AlphaWorld, you should try to build a bit off the ground with your ground-cover objects. When you build too close to the ground you may experience "bleed" (the ground shows through) when you view the scene from high third-person mode.
You should plan your world so that if users have built with certain objects and textures, they don't have to be changed afterward. However, if for some reason you do need to make changes, you should not need to bring the server down. If working on a remote UNIX system, it may be best to put the new files in another directory on the website and then rename them to the directories they go in. This will minimize the possibility of interrupted downloads.
For users who are online and active within your world at the time you make changes to the artwork, the object refresh time (determined for each at the time they enter) and their offset within that cycle will determine when they get the changes. So one user may come in and download some art for the first time just before you change it, while another comes in for the first time right after the change: If your object refresh is eight hours the two users will be seeing (and possibly conversing about) different things for almost eight hours.
You can see examples of the way artwork websites are set up by browsing the URL http://awweb.worlds.net. Several communities are set up underneath this directory, including the main AlphaWorld objects. Each directory containing objects for a world looks like this:
When you set up your world, you choose a location on the web for dynamically downloaded files. Under the main directory you choose, create a directory tree including models, textures, avatars, and sounds:
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.
When you design objects we suggest that you 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. The contents of ZIP files need not be lower case as the client ignores the filename within the zip file. For instance, 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 web for cloth1.jpg, which it will decompress to cloth1.bmp. If the file on the web is called Cloth1.jpg, no match will be found. This will result in a persistent problem, where the object will not render.
