These are all really great ideas -- there's too much here to reply in detail (I'd be up all night) but rest assured that I'll be incorporating a lot of this into the requirements document. I'll post the new version with everyone's suggestions in a few days.
On Wed, Jan 31, 2007 at 11:18:03PM -0800, Ken Taylor wrote: > > 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 -- [ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ] [Lead Programmer][Interreality Project][Virtual Reality for the Internet] [ VOS: Next Generation Internet Communication][ http://interreality.org ] [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
signature.asc
Description: Digital signature
_______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
