Palace Design Tips & Techniques

This section describes various means of adding advanced functionality to your Palace site, and includes an examination of the limitations faced by Palace designers. * Using a new template * Authoring with The Palace Authoring Tool * Linking Palace sites and web sites * Palace limitations and workarounds

Using a new template

The easiest way to change the look of your Palace is to download and use a new Palace template from The Palace website. Templates are the look and feel of your Palace site; they contain artwork, sounds, scripts and a configuration file (.pat) containing information about your Palace rooms. The Palace website has many different configuration files you can download, such as a beach resort or an office. You can download as many of these templates as you like, and change the look and feel of your Palace whenever you want.

Using and modifying a Palace template has the following requirements:

 

• You must be an owner of your Palace site and have access to the server interface.

• You must be running a Palace server version 4.4 or later.

   

To obtain a new template, go to the downloads page and select the templates section. To use this new template, configure your Palace to use the .pat file associated with this template. See the Palace Server Guide for your particular server for more information.

Authoring with The Palace Authoring Tool

The Palace Authoring Tool is a standalone web-based tool that lets you edit your Palace template configuration files (.pat files) in an easy-to-use Graphical User Interface (GUI). You can edit rooms, doors, spots, and scripts; add and remove images from your Palace rooms; and, view the changes before publishing The Palace.

Using The Palace Authoring Tool has the following requirements:

 

• You must be an owner of your Palace site and have access to the server interface.

• You must be running a Palace server version 4.4 or later. However, The Palace Authoring Tool is not implemented for the Palace Server for UNIX 4.4.

• The Palace server must be on the same machine as The Palace Authoring Tool.

   

See The Palace Authoring Tool Guide online at the Palace website for more information.

Linking Palace sites and web sites

In the area of "DTVR" (DeskTop Virtual Reality), the web clearly reigns supreme as the medium of choice. Indeed, with clever use of some advanced htm tags (and "enhancements" to the htm specification), web pages become dynamic documents, capable of not only output functions, but of receiving input as well. With the addition of forms, plug-ins, media streaming, VRML and distributed multimedia applications, the web is becoming more immersive and interactive all the time.

These new technologies are helping to redefine the functional model of the web, moving it further and further from its roots in traditional layup and DTP. This is good news indeed for webmasters. Nevertheless, anyone who's attempted to create a true feeling of environment on the web will tell you that this is still a severely daunting task, the results of which are more often unsatisfying than successful.

In contrast, the functionality of The Palace assumes an environmental design model, rather than a publishing one. For example, it is possible to use Palace rooms as "pages" (by creating background graphics which are full of text), but the cost in bandwidth and the limited area of the View Screen make this a pretty inappropriate use of the medium. Here's an example of trying to use a Palace page as a document page rather than an interactive graphical chat room:

"CyberDictionary" Room, Imaginary (Terrible) Design

If this design approach is carried to an extreme (essentially creating Palace-based hypertext), the "multiple user problem" manifests on another, more obnoxious level. Looking at this image, it's easy to imagine the following dialogue:

USER 1: Could you move, please? I'm trying to read the first paragraph.

USER 2: Yeah, tell that to Tigger - hey TIGGER! Move your avatar! People are trying to READ here!!!

Tigger's user, meanwhile, is busy on another line, or has gone into the kitchen to grab some cookies and milk. Perhaps he's even fallen asleep in his chair! The lesson here is: just because you can do something, that doesn't mean that you should.

HyperLinks: From Web to Palace

With the popularity of the Web growing by leaps and bounds, there will be many users who will want to access your Palace through the Web. The easiest way to accommodate these users is to embed The Palace Viewer (the Web-based Palace client) on your web page. You can also embed a link that starts up The Palace for Palace User Software users.

Providing web access for Palace Viewer clients

Using The Palace Viewer applet (the web-based Palace client), it's easy to embed a link to your Palace on your web page. If you are the owner of your Palace and have the Palace Server version 4.x, you can also make this Viewer more accessible to users, control web-based links to your Palace site, and provide custom avatars for these web-based users.

Embedding The Palace Viewer on your web site and pointing it to your Palace encourages users to visit your Palace. Anybody visiting your web page can instantly then visit your Palace site simply by going to the web page with containing the embedded applet. They do not have The Palace client software installed on their machine themselves.

This image shows a web page containing a link to The Palace via The Palace Viewer applet.

A web page with a Palace Viewer link

When a user clicks the logo, he or she accesses a web page containing The Palace Viewer applet pointing to the owner's Palace. Applets are programs that run inside of a web page, often initiated when you click their link.

To attract even more visitors to your site, you can encourage others to embed The Palace Viewer in their web page and point to your site. They don't have to have a Palace site installed to do this. They also can be any level of user.

* To embed The Palace Viewer on your web page and point to your Palace

 

1. From The Palace User Software, connect to your Palace.

2. From The Palace User Software Options menu, select GoTo Site Page. Your web browser launches and goes to your Palace's site page.

3. On that Palace's site page, click the button Add This Palace to Your Web Site.

4. You receive online instructions on how to embed The Palace Viewer on your web page, pointing to your Palace.

    

Controlling Palace Viewer links to your Palace. Anybody can embed The Palace Viewer in their web page and point to your Palace site. Note that this does have issues. While you might welcome having your Palace linked to by many web pages, you also might want to control the web content surrounding this link. For example, if you operate a family-oriented Palace site, you probably don't want links to your Palace site appearing in web pages containing adult content.

If you are the owner of your Palace, have access to the Palace server interface, and are running a Palace Server version 4.x, you can set security that deals with web-based users. You can specify:

 

• An authorized directory of URLS. You can specify that only certain web sites are authorized to contain pages with a Palace Viewer pointing to your Palace site.

• An entry page for non-authorized access. If somebody tries to access your Palace site through a Palace Viewer that resides in a non-authorized web page, that user will access this page instead of your Palace site. By default, this page is automatically generated by Communities.com. However, you can change it to one of your own. You can customize your entry page to contain any content you want, such as a password form. It doesn't even have to contain The Palace Viewer link.

  Once you specify a custom entry page, your Palace Page in The Palace Directory also points to it when somebody clicks the link to your Palace.

   

For information on setting web-based security, see The Palace Server Guide for your specific server.

Providing web access for Palace User Software clients

You can also provide web-based access to your Palace for users who are running The Palace User Software client. Note that unlike with The Palace Viewer, these users must already have The Palace User Software loaded on their machines.

This image shows a web page embedded with a link to a Palace.

A web page with a Palace User Software link

On your web page, the htm tag for the "Big E" graphic looks like this:

The palace:// identifier instructs the web browser to launch The Palace client to display the URL ecipalace.metawire.com. When web users click on the graphic (or text) in question, The Palace client is shelled (i.e., executed by, or "through," another program). The browser window drops to the background as The Palace client becomes the active window. When the user is finished exploring your Palace, exiting The Palace client returns them to your web page, and the browser becomes the active window again.

HyperDoors: From Palace to Web

You can also launch your web page directly from a room in your Palace using a hyperdoor. You do this by creating a new door and associating an Iptscrae script with it. Only the operators or owners of the Palace can create hyperdoors:

* To create a hyperdoor

 

1. Select New Door from the Operator Menu (or select an existing door while in Authoring Mode).

2. Select Door Info from the Operator Menu (or double-click on the door itself) to bring up the Door Info window as described in Door Info.

3. Click on the Type combo box and select Normal.

4. Click on the Script button to bring up the Scripting window.

5. Insert the following line of code and you're done:

   ON SELECT {
   "http://" NETGOTO
   }

   NOTE: You can also create doors between Palaces using this same command. If the URL specified begins with a palace:// identifier, the door will lead to the indicated Palace site.

    

Case History

In the original design for the ECI Palace a door was placed in the entrance room, labeled Click here for info on downloading the graphics. Clicking on this door sent the user to the following room:

"Get the Graphics" room, Original (Poor) Design

This design seemed like a good idea at the time: it was informative, goal-directed, and fairly neat to look at, but it turns out that users didn't appreciate it much at all. In fact, new users often left this room to go ask a operator for all the same information. Obviously, something needed fixing. Care to guess?

There are many problems with this design, but are all related to its reliance on graphically-depicted text in the background layer. The instructions are literally part of the background image, which of course opens us up to the "blocking" phenomena described previously.

However, the problems don't end there:

 

• Since the instructions are part of the graphic, they do not appear until the picture downloads to the user's hard disk. (

• Since the art is original (i.e., not part of any other Palace site users may have been to), it needs to be sent to practically every user who comes in.

• This room, unlike most, is almost certain to be avoided by those who have been there once before; this further decreases the value of having to deal with it at all.

• The intensely-dithered nature of the graphic creates a larger file, causing the download to take longer than it should for such a utilitarian room.

   

All these little problems add up to one really big one. Simply put, new users would come here to get "quick information" and instead ended up watching a blank screen while they waited for a large piece of art to download. Worse still: if several new users all entered the room at the same time, the sudden rush of server activity would spawn a timesharing cycle (a "daisy-chain of lag"), further slowing an already inefficient process.

The second version of this room addresses the problems raised by its predecessor. The following image displays the changes to this room to fix the former design. There were three main elements to the solution.

 

• The original graphic was replaced with one of the pictures from the Mansion Palace (Spiral.GIF). Since the Mansion Palace is a well-known Palace, it's probable that many users have already visited it, and thus have the room art already downloaded to their machine. This means the image does not have to download again.

• The instructions were moved into chat balloons (of the "excited" variety). Balloons and their text display on the screen whether or not the background picture has downloaded yet.

• The user is instructed to open his or her Log window, where the words from the chat balloons appear once more. Many users (especially new ones) are unaware of how useful the Log window is; this approach allows them to select an address right out of the log, copy it, and paste it into their browser's "Location" box.

   

"Get the Graphics" Room, Second Design

Since we could give users the ability to choose their own preferred downloading method (browser or FTP), this represented an ideal solution; if you cannot provide FTP access, a browser download will be just fine by itself. Of course, as you have already learned, it is also possible to create direct hyperlinks and hyperdoors between Palace rooms and web pages. These are very helpful things for users to have access to, providing them with an easy, familiar way to obtain your graphics and sounds.

However, this is only the most obvious of many possible uses for such links. In fact, Palace rooms and web pages can be interwoven so easily that it becomes quite natural to begin imagining hybrid sites, in which The Palace client and the web browser play equally important roles. Building a network of interconnected Palace rooms and web pages allows you to do all sorts of interesting things that neither The Palace nor htm could support alone.

Palace limitations and workarounds

Creating a basic Palace with individual rooms, doors, and props is a fairly simple project, comparable to creating a web page. After you've got your first Palace up and running, however, you'll probably start imagining ways to make it more immersive, complicated, interactive, and computationally intense. At this point, you'll probably also begin bumping into some of the Palace's hard-wired limitations, which are rigid enough to warrant a special section of their own.

In the pages that follow we will look at some of these limitations, and discuss some of the ways Palace designers have found to work around them. We will also look at the advanced functionality currently being offered by progressive Palace sites, and discover how they were accomplished.

File sizes and preloading

One area of concern for the Palace developer is the sheer size of the images used to depict the rooms. These images are always 512 by 384 pixels. Saving the files as JPEGs produces the most compression. However, to accommodate older Palace User Software clients, many Palace owners choose to also provide 8-bit (256-color) GIF formats. Since GIF images are generally 25% to 50% as large as flat bitmaps (in terms of bytes required for storage), we can determine the typical size of these graphics by applying the rule of thumb for bitmaps and dividing that number by sigma (the range of) two to four:

 

1. Bitmap Size Determination

   ( 512 pixels * 384 pixels * 8 color bits ) / 8 = 196608 bytes

2. GIF Translation:

   196608 / 4 = 49152 bytes (low end)

   196608 / 2 = 98304 bytes (high end)

As you can see, the average Palace GIF will come in between 50 and 100 kilobytes. This is not a "problem" as far as the software is concerned; if a user doesn't already possess the graphics for a room they have entered, the server simply sends them the required files.

This has a few disparaging effects, however:

 

• It forces the user to wait for one to two minutes every time she enters a room she's never seen before. Just as on a web page, this waiting process frustrates many users -- especially those with slower connections -- and may end up negatively affecting their opinion of the site as a whole.

• Sending these images is yet another task the server must tend to in realtime; this causes all other server tasks - like animations in other rooms, etc -- to "timeshare," and goes against one of the general design tenets of The Palace, which is to do everything possible on the client's side of the connection.

   

Another consideration is that The Palace has no built-in way of determining when a download has ended. You can't write code that uses a "download completed" signal as a trigger of any kind. In complex auto-activated rooms (rooms containing constantly-looping animation routines or the cyclic triggering of alarms, for instance), the Palace script will dutifully continue flipping graphics even though the user isn't seeing any of this activity yet. In effect, the server's "timesharing" approach works directly against the downloading user, dragging out an already-undesirable process.

If your site uses a lot of "spot art" or animations, here's how you can minimize this problem right now:

 

1. Compress all your original Palace graphics (and sounds) into a single file, using a common archive format such as .SIT or .ZIP. You'll probably want to do one for each platform (SIT files are created by Stuffit, while ZIP files are created by PKZIP or WinZIP).

2. Make these files available via your web page or anonymous FTP site.

3. Do one of the following:

   Use the 'fileserver command to move these to a web server other than the default one provided by the Palace. This eliminates the load on your Palace server. See 'fileserver ["URL"] / for information.

   Or

   Place a message or script just inside the "front door" of your Palace, informing people where they can go (usually via the web) to "preload" the graphics and sounds. For ease of use, it's a good idea to build a "hyperdoor" to your archive's URL right there in the same room. For an example of creating a hyperdoor, see Providing web access for Palace User Software clients.

   When the user clicks in the hyperdoor, The Palace client automatically launches the web browser and heads out to the URL specified in its script. Once there, the user can download your graphics and sounds simply by clicking on the appropriate link.

    

Conversely, it's also a good idea to provide a link into your Palace from your web page. The easiest way to do this is to embed The Palace Viewer applet into your web page. See Providing web access for Palace Viewer clients for more information.

Art and Palette Limitations

This section describes image limitations for the Palace.

The Palace Palette

The Palace Viewer, the Palace User Software for Macintosh 2.2.1 and the Palace User Software for Windows version 3.5 can view JPEG formats of your room art. Macintosh and Palace Viewer users can even see these images at photographic quality. JPEGs are preferable for your room art, though they might be larger than other file formats.

Other Palace client versions, however, can only view GIF files. In addition, this GIF art for rooms, and also avatars and prop images is done in 256 colors. The same 256 colors. To allow fast, platform-independent color fidelity, The Palace has a special Palace Palette. This contains three intergradiated ramps of red, green and blue values, a fourth ramp of white-grey-black values, and the twenty colors of the windows system.

Despite the possible creative frustration felt by 24-bit-color purists, the Palace Palette is a very good one; you can use it for all sorts of stuff besides Palace design, it works very well for color reduction (from 24- or 16-bit to 8-bit).

The Palace Palette is easy to obtain. It is recommended that you download the palette from the Palace website. You can also log into any Palace Site and download one picture. After that, use a quality graphics editor like Adobe's Photoshop or JASC Inc.'s Paintshop Pro to extract the palette from this picture (you'll find the downloaded GIF sitting in your Pictures folder, which is located by default inside your Palace folder).

To avoid unexpected color performance and extra work, be sure to apply Palace Palette to your new images before you go too far with them.

Maximum Pixels per Room

When you begin designing room-based animations in your Palace, you may run into another limitation: there is a maximum on the amount of graphic data that can be associated with a room. This limit is hard-coded into the system, to ensure that users on slower computers don't get completely bogged down. Without getting into the technical details of CRC-checks and other related factors, this limit is roughly three or four times the total graphic area of the View Screen, or up to 1024 by 768 pixels.

1024 by 768 pixels is a nice amount of space to play with; quite adequate for your typical exploratory environment (e.g. a "Myst"-like experience). If you can live within this limit, you can do some pretty cool stuff. For instance, you could do an 8-frame animation filling half the View Screen -- in one room. Or you could create an animated character about the size of two props (44 by 88 pixels) and give it 32 possible positions!

The best defense against running out of graphic space is cleverly designing individual elements of your art so that they cooperatively display, hide and reveal what you want to, using the smallest number of pixels possible.

Props

Props, especially new ones, are the single largest cause of network traffic related to a Palace site. This is because the more users there are in a room, the more people need to receive graphic information every time you don a prop they haven't seen before. All of this prop activity can create a noticeable amount of lag.

If your Palace site is lagging badly, you can try this simple experiment to determine if prop traffic is to blame: simply turn custom props off on the server (you should warn your users before doing this). If the lag decreases while carrying a normal amount of users, props are the problem. You can enforce prop control using the command 'propcontrol on.

Since you probably don't want to leave the custom props flag off indefinitely, there's little you can do about this situation (short of getting more bandwidth, closer to the Internet backbone). Of course since your users are the people most affected by the lag, it may help to explain the cause of the problem to them and ask if they could let up on the new props a little.

Audio limitations

he Palace software supports .wav and .mid (MIDI) files for both Macintosh and Windows platforms and .au files for The Palace Viewer. The sound files which come with The Palace software -- they're in the WAV format, even though they have no file extensions -- were sampled at 22 kHz in 8-bit mono. The samples can be of a slower rate, but should always be 8-bit monophonic.

Like graphics, any new sounds you create can be made available via web-based hyperlink or FTP site, as explained in File sizes and preloading. Here's how to prepare them:

 

1. Mix and edit your sounds down to the lowest fidelity you can (without utterly destroying the sound quality).

2. Save them as WAV files.

3. Change their names to remove the .wav extensions.

4. Compress all your soundfiles together into a single archive file, such as ALLSOUND.ZIP or AllMyWaveFiles.SIT. It's a good idea to do an archive for each platform (SIT files are created by Stuffit, while ZIP files are created by PKZIP or WinZIP).

5. Make your compressed archives available via your web page or FTP site, just as you did with your graphics. You might decide to compress both sound and graphics into one massive file.

    

Code limitations

This section describes current Iptscrae implementation limits. In general The Palace Viewer version of Iptscrae is limited only by the memory available in the browser, so these limits only apply to the Windows and Macintosh clients.

The limits are divided into two sections, those that apply while a particular event handler is executing, and those that apply to GLOBAL variables. In this context, it should be noted that a SELECT operations runs the ON SELECT handler for the selected spot as a subroutine. The ON SELECT script shares non-global variables and limits with the calling script.

 

• The maximum length of a string constant or AtomList is 16384 bytes.

• The maximum length of a string generated by GREPSUB is 16384 bytes.

• The maximum length of a compiled GREPSTR regular expression is 1024 bytes.

• The maximum length of a compound string (one created by concatenation or SUBSTRING) is limited only by client storage.

• The maximum number of variables in a single handler is 64.

• The maximum number of nested AtomLists (IF, WHILE, EXEC etc.) is 64.

• The maximum number of alarms that can be queued at one time is 64.

• The maximum number of data items that can be held on the stack is 256.

• The range of spot states is -32768 to 32767. The maximum number of states with associated pictures is still 32.

• The maximum number of array elements is 256.

• The maximum number of global variables is limited only by client storage.

   

There are some situations that will limit this further. For instance, you cannot do the following:

string that's 4096 big SAY

This will get truncated to 254 character. This is because SAY denotes chat speech. The Palace is a chat application and speaking huge amounts of text at once disrupts the nature and experience of a chat room.