keithley@apple.com (Craig Keithley) (02/02/91)
I've been reading the various postings about languages, and I'm not ready to decide for or against any one language (Lisp, C, C++, or something new). I am interested in fine tuning my virtual environment object behavior concepts. ********************************************************* What I'm envisioning is a virtual environment (a subset of a virtual world) that contains virtual objects. Each virtual object will need a physical description. Since not everyone will be able to draw a detailed image, the physical description will need to be layered. This layering would describe progressively more complex details of the virtual objects. Conclusion #1. Virtual objects will need a standardized description syntax. Layering will provide the ability for first generation systems to draw the simple version of an object description. My Macintosh IV would draw the most complex view. ********************************************************* Another issue is defining object behavior. Some objects are rather quiet, a bookcase for example would probably not do much during the virtual day. Other objects would be rather active, for example a wind up toy would bounce around, etc. Conclusion #2. Definition of object types. To start with, some objects would be *static*, and the object file would only contain the object description. Another object would be *dynamic*, with the object file would contain both the object description and some form of a script that describes object behavior. ********************************************************* I'd also want to be able to share my objects with other Virtual-World experimenters. Conclusion #3. A standardized object description syntax and object behavior syntax. I view this level of standardization as very important. ********************************************************* Interaction of objects with each other and the virtual environment. There needs to be a definition of how this occurs. Right now, IUm focusing on the mechanism by which messages are sent from object to object and from object to the virtual environment engine. For example, a clock object would need to send a message to the virtual engine to request the time. The virtual engine would reply with a time message to the virtual clock. (note: the virtual clock would be a *dynamic virtual object*) Static object would not respond to messages. When the *virtual-Me* presses the play button on a virtual VCR, IUd want the virtual VCR script to receive a message indicating where I pressed, and how hard. When the virtual VCR starts to play the tape, IUd need it to send a message to the virtual environment to update the object description (the play light comes on). Conclusion #4. We need a standardized inter-object message syntax. ********************************************************* A dynamic object might be doing something while *IUm* not looking at them. Therefore, the dynamic object script must be capable of executing concurrently with other objects. For example, I might be in my virtual kitchen when the VCR tape runs out. The virtual VCR should stop, and send a message to the virtual engine to change the virtual VCR object description. Conclusion #5. Objects scripts are multitasked. ********************************************************* Virtual environments will need to be networked to build up a virtual world. For example, I donUt think your machine needs to contain all the objects in my virtual office. If you visit my office however, youUll want to see them and interact with them. My virtual engine will send your virtual engine the object description (so it can be displayed) but not the object script. When you interact with it, your virtual engine will send an inter-object message to my virtual engine. My engine will then send the message to my object. My script will respond by sending an object description update message to my virtual engine, which will in turn send the object description update to your virtual engine. If you pick up my virtual VCR and carry it out (Thief!!!!!), then my engine will have to send the object script. Another scenario might be that I have too many object scripts to handle, and IUll pass them off to another processor in my deck. Conclusion #6. Extend the inter-object & object-environment message syntax mechanism to work in both an interprocessor and interprocess hardware environment. ********************************************************* Your virtual environment (deck) might have a different CPU. Conclusion #7. Object scripts should be passed around in a source code (ascii text?) format. Whether you interpret them or compile them, I donUt care. See conclusion #3 ********************************************************* That about covers my concept of a virtual environment. Its multi-tasking, and supports interprocess and interprocessor communication. I have object files that are sharable with your deck (even if it contains a different CPU). I have a method of telling my objects what IUm doing to them. I donUt need to create a single file containing all my objects and their scripts. Adding objects should be a matter of drawing them using a simple CAD program and writing the script. I'd want to drop that VR *object* file (yes, I use a Mac) into my VR object folder and have the VR environment begin to use it. You can also interact with my virtual environment without needing my operating system or objects. Comments anyone? Craig Keithley, Apple Computer keithley@apple.com [standard disclaimers apply!] [special disclaimer: My work has nothing to do with this newsgroup]