Portals between A3DL sectors could come in two basic types:
- Simple Portals, which contain a hypercard to the destination sector, and information on the coordinate transform through the portal
- Dynamic Portals, which contain a hypercard to a "portal entry" object. The portal entry object will then contain the link to the destination sector and coordinate tranform information
The idea is that Simple Portals are used when the sector designer has control over the destination sector and can ensure that the portal "links in" to a reasonable spot. For example, they can be used to construct large areas made up of several sectors on one server. Dynamic Portals would typically be used to link to a different server, where content is not controlled, and the "portal entry" object gives the destination server some flexibility in re-directing or placing the incoming connection properly. Portal entry objects could also redirect to other portal entry objects.
There could also be several options applicable to all portals:
- Suggestions that direct the client to open or close the portal (of course the user preferences or resource limitations can override these):
- Default state (opened/closed)
- Open on load (when the object is enumerated by the client) or on visibility
- Open on proximity
- Is a portal backtraceable (when walking through it, should a "return-portal" be automatically instantiated by the client for the user to return to his or her previous sector... obviously clients might limit how far this back-trace goes, or at least how many connections they keep open).
- When the portal is closed, is it opaque or transparent? (Transparent portals could be used for "zones" in a large outdoor area -- when the portal is closed, a stand-in version of the next zone is visible behind it. When the portal opens, the real destination zone appears in its place)
- Is there geometry associated with the different states of the portal (and perhaps animations between those states? Like a door opening and closing? Or should this be done with scripting...)
- Suggestion on whether the client should listen to talkative events from adjacent sectors (it's ultimately up to the client whether to do this or not, and how many adjacent sectors away to allow talking events to be heard).
Some other suggestions about portals:
- Clients should display error messages on or near the portal object for connection and permission problems, and for things like requiring a login/password, instead of popping up a dialog or something equally disruptive.
- When scripting comes around, opening and closing portals should be scriptable actions. (Client-side scripting only?)
- Portals should send out messages to interested listeners whenever objects leave through them, and perhaps what the destination of those objects is. (This will require the object to tell the portal on the server that it's using that portal, since passing through a portal is generally a client-only activity). This can be used by other clients to display the object's transition in a smoother manner than just removing it and adding it in the new location (assuming that the other clients are seeing the same destination location through the portal).
- A user may have a different avatar on different servers, or even a different login name. This might make synchronization when other users watch them pass through a portal more difficult...
- Note that different users may see the same portal going to different destinations. Portal Entry objects, for instance, could give out different destination locations for different users, for load-balancing or other purposes. Also, even though you can see a destination sector through a portal, users in that sector may not be able to see you as there may not be any portal back to your location. Finally, some portals are only seen by one particular client (eg, backtracing portals).