Just a long brain-dump of some ideas I had while reading through the list of the requirements for the VOS/Interreality 3D suite. I'm sure you will think some are blatantly obvious, or redundant, or that some aren't quite within the scope of VOS -- though perhaps they are something that could be implemented by an extension/plugin to either the server or client (or both). In fact, one could argue that any robust extension system should be able to support all these kinds of features if they aren't already in the "core." Also sorry if it's a bit disorganized.
1.1 Mission Statement Should emphasis be put on the interconnected aspect of "online"? In other words, the worlds can and should connect to other worlds, either though links or direct portals. Under "platform" should it mention commerce in the list of possible applications? 1.2 Multiuser Requirements Should users also be able to form "subgroups" or "channels" with other users on a server which they can send messages (or other data) to? Should users be able to send messages directly to another user (not through the server)? I echo Reed's suggestion not to specify VOIP directly, but rather audio streams in general. In fact, perhaps users should be able to stream multimedia in general (face-to-face video, for instance). Users should have the option not to receive certain kinds of multimedia or have it limited in bandwidth. Users shall be able to ignore messages or other traffic from any other user at the server-level (ie, the server won't propagate it to them any more). Administrators shall be able to grant and rescind Moderator privlidges to users. Should users be able to transfer virtual world object to other *servers*? Should content be flaggable with age restrictions or NSFW, and users be able to filter by content classification? Should users be able to suggest that content be flagged (including, for example, other users' avatars)? Should servers be able to create independent "instances" of the same space, so a space doesn't become overcrowded (or to provide a private experience -- for example, when shopping or doing research)? -- Should users be able to "invite" other users into their instance, or all go into an instance as a group? (private meeting room, or game, or collaborative research). Should they be able to set more general permissions on who can access their instance and how (ie, some have full access, some are read-only/observers, some can instantiate their avatar and some can't, etc) 1.3 Online Networking The client shall support intelligent caching of data from recently-visited servers Partial downloading of the world (ie, only currently visible/important features plus intelligent precaching) shall be supported Should there be user preferences to control the amount and types of bandwidth the client will receive from the server? Should the server have features to impose quotas on user resources such as bandwidth, server cpu time (scripts), number of objects, storage space, etc? (this is probably covered in other sections) Servers can link to content on other servers (and other servers can limit such remote linking) Clients can perform parameterized queries for downloading data or receiving updates (I swear I thought of this before the recent discussion ;) ) 1.4.1 Scripts Should the server and client have standard frameworks for "plugins" or "extensions" which can extend the interreality 3d platform in various ways? Should the client be able to query the server for the features it supports and plugins it has installed, and vice-versa? Should the client support extensive user-customizable macroing/scripting capabilities? 1.4.2 Interactivity Should there be "movable" objects which can be manipulated by dragging the mouse or another input device? The user shall be able to move around the virtual space through a variety of control schemes and input devices. The movement may be constrained by the client or by the server. In either case, a physics system may be imposed, and in the case of a server-side physics system, client-side prediction will be supported (this requires representing movement as user input actions, timestamping them, and keeping the timestamp synched between server and client -- maybe some of this should go in the "Networking" section?). Server-side movement restriction may also disallow a user from entering a certain area based on other factors (such as permissions or rules of a game). For support of games etc, should the server (or a script on the server) be able to restrict which VObjects the client can access or change based on where the user is in the world, or what the state of the world / current game is? (ie, to prevent cheating / spoiling -- to ensure proper progression of game logic - or outside of games, to force the spacial metaphor to be followed, etc) Scripts/extensions should be able to specify other kinds of interactivity with the world. User ability to see everything that's going on in the client, cache status, currently connected servers/users and currently active objects, bandwidth usage, cpu, etc. A feature in the client to "browse" your own local PC in the 3d interface? To run local 3d applications or browse the web or view files inside the 3d interface? Having a "home world" that you can set up locally with common links/portals to other worlds? (the ability to log on remotely and browse your pc or home world from another client across the network? maybe even invite friends into your computer as well, except they'll have restricted access? ok, this has gone out of the scope of interactivity...) 1.4.3 Authoring I like Reed's idea of being able to "sign" the objects you create. Perhaps vobjects should have a built-in facility for providing "signable" data for the object and a signature that can be verified against it. Content should support (require?) levels of detail / scalability for different client capabilities and bandwidth situations. Revision control / edit history of user-editable objects? (sorta like a wiki, where you can roll back if someone screws it up) Objects should have a physical model for servers or clients which support physics-based animation / interaction / movement. The server should be able to specify limits for the data size of objects, their physical size or other properties. Should users be able to author an object on a server that only selected other users can see/ know about its existence? Should users be able to "author" an object that is sent directly to another user, not through the server? This way, they can share the existance of the object in the current space, but no one else is aware of it? 1.5.1 Meshes and Effects "Portals" is more than just an effect. There's a lot you could do with portals between servers, and perhaps this should go up to "Online networking" but I'll put my thoughts here. A server can choose to accept incoming portals, and have several locations specified to be "portal inputs" where the portal "door" appears to be. Servers may load-balance incoming portal connections across instances or across physical servers (as with any incoming connections, really). A client, upon seeing a portal object, will open a connection with the destination server, but won't instantiate its avatar there yet. It will render the scene aligned with the "incoming portal" on the destination server. In passing through the portal, it will remove its avatar from the old server and instantiate it in the new -- perhaps requiring some additional signaling so that onlookers see a smooth transition. Upon passing through a portal, the user can leave the connection open to the old server (if it allows it) or at least remember which portal went back to which server so they can re-trace their steps (therefore, on a server, every outgoing portal should also be an incoming portal, but not necessariliy vice-versa -- a server can have "incoming-only" portals which receive users from many different places). If two servers have outgoing portals to each other it can be a kind of bi-directional portal, but this sh ouldn't requrie any additional logic. Users can also open "temporary portals" for themselves only (simply a graphical nicety, no interaction with the server), or instantiate one on the server if they have permission to add objects. Portals can have permissions set as to who is allowed to "go through" them (really, who is allowed information on where it links). Servers can restrict who can arrive via portal and where. Perhaps a user can create a temporary portal that only certain other users can see, with the intent that they can follow him/her. Temporary portals will disappear after a timeout after their last use. A result of all this is that portals may not necessarily be seen the same by all users -- but that's probably OK. The client should limit the number of portals "opened" at the same time to save bandwidth/memory. Some portals could by default be "closed" and need to be requested to open before a connection is made. Finally, portals should display messages to the user while connecting or during error / access denied situations. Wow, I rambled enough about those! User options to adjust lighting in the world, turn off shadows and other features, etc. 1.5.2 Avatars Servers should have the ability to restrict various parameters of user-uploaded avatars (just like content) Other users may choose not to download custom avatars -- therefore, a "fallback" standard avatar should be available. Models should support various levels of detail/bandwidth requirements Model articulation can be based on canned animations that are triggered, or by "streamed" bone animation data (if the server allows it, and the clients request it). For example, a head-tracking device may be linked to the position of the model's head. Or a motion-tracking glove may be linked to the model's hand. Avatars may be created on the server by scripts, with appropriate permissions (in other words, bots/agents). User permissions limit the total number of bots a user may have on the server at once. 1.5.3 Animation Support not only canned/pre-recorded animations, but also "streaming" animations? Procedural animation (ie, have this block follow a sine wave, have this object spin in a circle, etc)? Physics-constrained animations? Animated textures / procedural textures animate other object properties (have lights pulsate or vertex colors change over time?) User option to stop any animations in the world in case they're annoying. Also second Reed's suggestion of sound effects. Also ambient sound. And perhaps sound environmental qualities (amount of reverb/damping/etc)? User options to "mute" anything in the world that produces sound, or control volumes. Ok, that should be enough thoughts for now :P -Ken _______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
