> Firstly - its an authoring decision whether the fact that the alarm is
> ringing is a shared behavior,
Ok, if this is what you esally WANT, then sure, put that behaviour in an
engine.
I cannot imagine any use for it, but if you want it, you got it.
> its perfectly valid for an author to decide they don't want everyone else
> to hear it.
Maybe. If you say so. I wouldn't do it that way.
> This is analagous to images on the net, both Mac and PC users can see both
> GIF's and JPEG's, the fact that you want something to run on everyone's
> machine, does not neccessarily imply they have to be restricted to a
single
> language. Portable opcodes may be a GOOD solution they are not
neccessarily
> the ONLY solution.
Good, then please give me another sollution! :-)
> This is my problem in general with your proposal, you take what might be
> good ideas and say this what we should be ENFORCING.
Fine fine, you are not the first commenting the "tone" in my proposal, and
if I had more time, i would give it a major overhaul. People are putting to
much stress in when I use words like "must", "only" and "should".
I have an idea of rewriting the proposal with the same contents (sort of),
but a different title "Some tips on how to implement multiuser VR".
Nobody can say that the ideas presented in the proposal is bad, that it will
never work, e.t.c. Sure, there might be other solutions, and I am open to
them. But I have yet to see a solution that is more satisfactory, when the
goal is platform independent multiuser VR.
> For example, you take
> two orthogonal concepts:
> + Whether a behavior runs on one machine only, or on every client.
>
> + Whether a behavior is simple (time dependant only) or complex (depends
on
> complex interpretations of state).
>
> And say that the line between these MUST be drawn at the same place.
Here I can't agree with you completely. Even if that is what the proposal is
saying (remember I am Swedish, my english might be completely wrong!!) it's
not EXACTLY what I mean.
What I mean is:
- Stuff that is simple/deterministic/"engine-like" CAN run on every client
(since the results are identical). And because of this, my opinion is that
it should. (It is a waste to update the wings of the rotating windmill
across the net for each frame).
- Stuff that reacts to events, state-of-the-world, e.t.c. CANNOT run on
every client IF YOU WANT IDENTICAL RESULTS. And because of this, my opinion
is that it should run on one host (be it one client, or a deticated server).
If you DON'T care about identical results, i.e. one person hearing the alarm
, another not, you don't need to adhere to this. My opinion is, that I care
a LOT about identical results.
- Only stuff that reacts to events/state-of-the-world esally needs to
communicate this to anybody else, to synchronize. Therefore, in my opinion,
stuff that reacts to events should be sending network update messages. This
is, in my opinion, yet another esason for such things to exist only on ONE
host, to avoid contradictory update messages.
- Stuff that doesn't react to events/state-of-the-world (i.e. is a
deterministic, "function-of-time" "engine behaviour") doesn't need to inform
anybody else, since it is in it's own nature of being in sync. Therefore, in
my opinion, these shouldn't have to send any network update messages.
When concatenating the above, wether you think the original premises is
"orthogonal" or not, I get two categories of behaviour programs:
- The "engines" that run everywhere, "acting out" the orders from the brains
- The "brains", that runs on one host, commanding the "engines" to do their
thing.
> These may be good ideas, they are not something standardisation should
enforce.
Yes, you have a point there, and Marc de Groot has persuaded my similarily.
If I only had time to eswrite my proposal I would do so.
Of course, I could run a macro on it that inserts "in my opinion" in every
sentence :-)
And besides - it's just a _proposal_. Feel free to plunder the good stuff
from it, and make a better one! :-)
Here is an excerpt from an Email to Marc de Groot, where I explained how the
thoughts about my proposal evolved:
Of course, Mitra, you are not agreeing with my initial statement in the
below message, about a single control point, so you might not agree to
anything that follows from it either :-)
I am also implementing the below mentioned squirrel in Meme, and will let
everybody know when he is done.... :-)
----8<-----begin included message----8<------------8<----------------
MY REASONING, IN A SHOEBOX.
We all agree on the "single point of control". All "objects" in the scene
must have exactly one brain, or control point.
We also agree, that there must be as little network traffic as humanly
possible.
We also want everything to be "in sync". Despite of our main enemy: Lag.
When a decision is made...
Squirrel: "Oh, shit, here comes that wolf again. I think I'll go hide
beind that tree".
...we want all simulations to be synchronized.
We also want all body-motion, down to the very last whisker, to be the same,
for all viewers.
We want the world to be responsive. When I turn the handle and open a door,
I would like it to open now, not 300+300+300ms later.
How could we solve this?
These "solutions" are, esentially, how my esasoning has gone.
SOLUTION 1: HOW NOT TO SOLVE IT
Make one squirrel code (a "master"), that transmits ALL body position
angles to everybody else (the "slaves").
Bandwith requirements: Huge
Attempts to defeat lag: No
Identical behaviour: Yes, but slaves are delayed by lag.
Responsiveness: Good when local (= manipulating master). Lagged when not.
So what can we do? We can look at the largest amount of things that the
squirrel can do, without caring about the outside world.
It could be as little as "rotate leg from 0 degrees to 10 degrees over 0.2
seconds", intermediate, like "walk north", or it could be as much as "go
hide behind that tree". THIS IS SITUATION AND APPLICATION DEPENDENT.
SOLUTION 2: AN IMPROVED SQUIRREL
The squirrel "master" works as before. But when it is about to "walk"
it sends the "walk" command to the slave, and essentially says to the
slave "walk in direction x.y.z.".
Bandwidth requirements: Much lower
Attempts to defeat lag: No
Identical behaviour: Not necessarily. At best, only delayed by lag. At
worst,
the implementation of the slave somehow differs from that of the master,
making the walking DIFFERENT, for some esason.
Responsiveness: Good when local. Lagged when not.
Ok, so now we have two pieces of code that implements a squirrel, a master,
and a slave. What if there is some (subtle) differnces in the implementation
of "walking" in each of them? What if there is a bug in the slave walking?
What if there is a random() function used for the waving of the tail? Or the
size of steps the squirrel takes?
SOLUTION 3: A BUTCHERED SQUIRREL (aka THE BODY/SOUL SQUIRREL)
The squirrel "master" only exists as a virtual entity. It has no body in
itself. It detects the Wolf, and considers walking away. So it tells it's
body the command "walk in direction x.y.z".
Bandwidth requirements: Same as solution 2.
Attempts to defeat lag: No
Identical behaviour: Much more probable, since it is not only SIMILAR code
that is run to move all squirrel bodies, it is THE SAME code. The
"local"
squrrel can't possible react differently from the "remote" squirrel
(except for lag). But what if random() is used in the tail? It won't
look the same, not _exactly_. [But if that MATTERS, could be a case-
to case decision, of course]
Responsiveness: Good when local. Lagged when not.
This is, IMHO, better, since I don't need to write the squirrel code "twice"
. I need to separate body and soul, and then I am off. Once I do that, it
will work the same, regardless of running locally, or remote. Not
simultaneous, but the same.
It also simplifies testing! What works locally, gautomatically" will work
remotely (though lagged).
SOLUTION 4: A TIME-BASED SQUIRREL
What is the same between all computers? What could be most relied on to
keep in sync? I think the quartz-crystal that runs the clock is a
good choice. Using NTP (Network Time Protocol) we can assure that this is
in sync, even across the world.
Again, the squirrel "master" is only a virtual entity. It is a "brain".
It works exactly as before, when it sees the Wolf, it sends a message to
it's "body", the "engine", saying:
"walk, starting at point p at time t1=NOW, in direction x.y.z at speed x,
and stop at time t2=NOW+5".
Bandwidth requirements: Slightly larger than sollution 2, but not much.
Attempts to defeat lag: Yes.
Identical behaviour: Not exactly, but very very close. Lag will cause a
remote squirrel to START it's walk delayed. But as soon as the
"order" arrives, the squirrel body will "snap" to the correct position,
and the remaining part of the walk will be completely synchronized.
Responsiveness: Good when local. Lagged when not.
Now things are getting nice, IMHO. This is the method that Bernie suggested.
It is the method that DIS uses. This is "dsad reckoning" generalized.
SOLUTION 5: THE FUTURISTIC SQUIRREL
We simply make the brain a bit more intelligent. The brain doesn't just
act "now", it acts into the future. The brain detects the wolf approaching