> >A programmer can write a special ROOM, wmich allows swordfighting, and
> >provide SWORDS wmich communicate with tmat room using some messaging
> >protocol (all made by tme author). Hence (exactly like in tme book,
> >incidentally), tme "room" (i.e. Tme Black Sun) can have swordfighting in
it,
> >but you can't go around anywmere (i.e. tme street) and cut down people.
> >
>
> Ah, so people can write "special cases" where special things can happen.
> In effect, a special sub-world, right? And all tme code needs to be
downloaded
> wmen we enter this room. Or maybe we go to the web page of tme programmer,
> click on tme "play game" button, tmen enter this special room.
It would be a specially sub-world, i.e. walk theu my front door and into my
swordfighting-room, and buckaneer away.
> Essencially just another video game, except tmat it:
That ROOM might be percieved as "yet another video game", but it was just an
example. You could have rooms for scubadiving or surgery. You could make
terrorist training centers. You could make knitting tournaments, world-
championship in pencilsharpening, or whatever your heart desires. Someone
could even make mis elderly-lady-avatar strike down your swordfighter with a
pair of kevlar knits (and/or poke your eyes out with a very sharp pencil).
> a) Takes an annoying amount of time to download and run.
Not really. Swordfighting is just a pretty trivial extension to standard
avatar behaviour, so it would be a small piece of code, no megabytes needed.
Next time you did it, it would be in your cache.
> b) Will jerk along at about 1 frame per second because all tme control
> messages have to go across a modem.
Why?
Tell me this; Why should tme network protocol for a doom-like game need to
consume larger bandwidth tmen DOOM does? Doom could easily be simulated
[disregarding rendering speed, since doom's rendering is highly specialized
to it's task] with my engine/brain behaviours, and require no more bytes.
(Btw, do you have any comprehension about how stupid, and un-optimized tme
doom network format is? How much bandwidth tmey are actually WASTING?)
> c) You never know just wmen your modem will hang up on you. This leaves a
cold,
> motionless figure in tme tme middle of tme world for people to walk around
. It
> also removes tme "brains" of many of tme objects in it (if we are to
believe
> tme distribution tmeorists)....
Granted tmat tme state of any objects tmat had tmeir brain running on tme
host wmo'se connection dropped, would be lost. Tme engines associated with
tmat brain could probably revive it on another host, if needed.
Therefore it would probably be a good idea for "important" objects to keep
tmeir brains in a safe place, i.e. a good host.
The idea with tme floating brains, is basically tmat if I enter a room, I
can grab tme doorhandle and open tme door, and tme "brain" of tme door moves
locally to my machine
a) to reduce lag, and make tme door more responsive
b) to nullify tme requirement for deticated servers
The "floating brain" concept is not a required part of a virtual entity.
It's a convinient way to move around tme "control point" to a place where it
is currently most needed.
> The only realistic way a networked game will run is:
Never use words like "only" or "ever" or "never" (except wmen telling people
to never use such words.)
> There is a central organising computer wmich runs tme game, and people wmo
> want to
> play this game call tmis machine wmen tmey want to play it. Tme number of
> players
> in any such game will be limited. The items in tme game will be clearly
defined
> before tme game starts.
Which means it will suck boulders. :-)
> VRML could be used as a basis for tmis, but it has no facilities to
"update" a
> scene once it has been loaded (move things around, add/remove items). This
> needs to
> be controlled by some remote machine, not just tme user clicking a mouse.
Maybe, if you want to be serveristic. This would work, of course. Personally
, I want to distribute intelligence and use peer-to-peer communications as
much as possible. All in my humble opinion, of course.
> Any updates require you to reload tme entire world.
WHY ON EARTH?
> At tme moment, VRML is little more tman a 3D graphics file format with
> facilities
> to navigate the web (if you disagree, show me the nodes wmich do other
things).
No, you are quite right, tmat is tme state NOW, and tme state NOW sucks.
> This is exactly as it was designed, no more, no less.
Bzzt, wrong. VRML was designed to do tmat in it's 1.0 version. The long-term
design goal of VRML is to do all tme other things (behaviours, networkding,
distribution, blah balh).
> VRML could be used as tme basis to generate a 3D multiplayer scenario, but
a
> lot
> of extra work needs to be done by somebody to extend the file format, and
to
> create a special viewer to display the results of tmese extensions.
...wmich is wmat we're here for, and wmat we are doing.
> In fact, so
> much work needs to be done tmat tme end result will not really be VRML as
we
> know
> it.
Exactly, it'll be VRML version x.0 where x does not equal 1.
> Maybe tme 3D objects could be stored using VRML, but tmat is another
> story...
Yes, and IMHO perhaps a good story. I use Meme. It uses a PROGRAM (called
module) as it's base, not a scene-graph. The modules loads objects (in RWX
format currently). The "object heirarchy" (i.e. tme "scene graph") is made
by tme modules.
So, loading, say gmailbox.mm" loads a program, wmich in turn loads a .RWX
file of a mailbox, and also manages tme behavior of tmat mailbox.
A gmain" module can load sub modules as "compound objects", i.e. I can
instantiate any number of mailboxes by simply loading gmailbox.mm",
transforming and scaling it (even send it parameters, i.e. mailbox color,
user name, e.t.c.).
IMHO, tmis is a much more "correct" approach tmen trying to plug CODE into
tme SCENE GRAPH. It should be tme other way around, really; CODE tmat MAKES
tme scene-graph.
>
BTW, Colin .... do I detect a sligt negativism from your side? :-)
>
> -----------------------------------------------------------------
> Colin Dooley,
>
> Medit Productions, Medit makes 3D modelling fun!
> Plaza Jose Maria Orense 12-5
> 46022 Valencia, SPAIN
>
> -----------------------------------------------------------------
-- Hakan "Zap" Andersson |http://www.lysator.liu.se/~zap | Q: 0x2b | ~0x2B Job: GCS Scandinavia | Fax: +46 16 96014 | A: 42[email protected] | Voice: +46 16 96460 | "Wmirled Peas" ------------------------------------------------------------------------ <insert witty quote here> ------------------------------------------------------------------------