Path: utzoo!attcan!uunet!clyde.concordia.ca!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!dali!milton!pezely@cis.udel.edu From: pezely@cis.udel.edu (Daniel Pezely) Newsgroups: sci.virtual-worlds Subject: Re: Implementing a virtual world Message-ID: <9005311121.aa07914@lazlow.cis.udel.edu> Date: 31 May 90 15:21:09 GMT Sender: hlab@milton.acs.washington.edu Lines: 79 Approved: hitl@hardy.u.washington.edu Hmm... Some of my concerns for implementing a virtual world, or at least building a library of software tools and device drivers for others to build upon, was that we need to get these tools to as many of the hackers (developers) as possible so that we can have sort of a mass- development effort going on. Maybe this is wouldn't work out too well, but let me state my original reasons for it, though. As someone who is still in school as an undergraduate, a few years ago, Borland's Turbo Pascal(tm) for the IBM PC's was the most valuable tool I had. With its `toolboxes' and other third party packages and with other tools that I and other (legal) hackers have developed, we built lots of nifty things. Sure, most of our work was a kludge, but when I moved up to C four years ago, one of those projects evolved into a commercial package. So, my question was, if we give the next generation hackers and ourselves some VR tools, will it benefit the VR community in any way? At first, I thought yes, but after talking to a few people doing VR research and a few likely users, I think maybe not. The reason is that we might be spending too much time -- at this point -- working in the wrong area. The most obvious problem is that not many people have access to the machines powerful enough to do just the base-level VR stuff. Even just building a world which people view through a monitor (having no eye-phones or data-gloves) would require at least a 486, 040, high-end Sparc, etc. Joe Hacker (independent developer) may not have access to it yet. Even the people in universities who might have access, the questions becomes: what platform do we develop on and for? SVR4 is still pretty much vaporware at this point, and every C programmer knows, ``there is no such thing as portable code, just code that's been ported.'' (who said that originally?) ...and software and operating systems is only part of the issue. So, now, I think those of us who have not committed to anything just yet and are still in the design stage, should work towards efforts of protocols and development of *something* that works. This is no new revelation, but I thought if this newsgroup is to be a forum for VR ideas, I might as well let everyone know what stage I'm at.... A few questions come to mind at this point. (the usual ones) What *exactly* do we want to do? What is needed, and what do we need to do? Since funding is always a problem, how can our work be of use to the sponsors? (ie, Why?) What are the various stages of development which will yield something that works? What kind of time frame(s) should we consider? How can we do it, and be realistic? Who is committed, and who can help? What platforms? (ie Where?) for now, where ever we can! Since getting started is half the effort, let's just start with what comes natural and accomplish *something*. (No kidding!) As Mark Evenson says, we can talk the virtual talk, but can we walk the virtual walk? I was going to develop my own tools such as a db engine, but why bother? It's already been done, and with AutoCAD rumored to be released with C programming hooks, we'll have a world prototyping system and db engine all in one. And, it's moving beyond the PC and Mac domains (VAXen under Ultrix, SparcStations under SunOS). Stay tuned... the MEAT is yet to come. -Daniel -- Computer Science Lab, Smith Hall, University of Delaware, Newark, DE 19716 Pezely@cis.udel.edu; Lab: 302/451-6339,fax: 451-8000; Home: 302/368-5931