[DGD] DGD Commercial Licensing?

[David Jackson]

At 09:43 AM 9/21/2004, you wrote:
>Par Winzell wrote:
>>Seriously, as I'm sure you are quite aware, DGD is every bit as suited to 
>>driving a large graphical MMO as are the incestuous offsprings of python 
>>scripts and RDBMS's that litter the commercial field.
>
>That's something I've been considering myself, albeit in a whimsical 
>"wouldn't it be great if..." sense - are there any projects using DGD as a 
>graphical MMOG engine, or is it still in the realm of the theoretical?  If 
>not (or even if so) has anyone considered how such a thing would proceed? 
>I'm rather afraid that I've become too entrenched in the "DGD as a MUD 
>engine" mindset!
>
>Mordengaard (Yhared MUD)

 From what I understand, one of the bigger MMORPGs uses a MUD engine 
beneath it (but at the moment, I can't recall which one).

But, if you think about a MUD as just a way to manipulate data - what's the 
difference between a room description and an image tag?  Even more abstract 
than that is - what's the difference between an object manipulated inside 
the mud, and an object manipulated in a 3D engine?

Very little, except how we view the location of the object in the MUD.  If 
you were to add a height value, and X/Y coordinates to every object 
(besides rooms, which are, after all, merely an object that contains other 
objects) then you could easily monitor it's position in the 3D world.

Of course, this example is crude and doesn't account for the necessary 
message passing between processes, but using DGD as the basis for 
controlling certain processes or interactions within the game allows for 
painless parallel-operation/clustering.  The client becomes a window on the 
world, handling the barest of colllision detection, while the MUD can 
handle everything else.

Here's a good concrete example;

Let's say that you have a lift, with a button, in a 3D game.  You press the 
button, the lift goes up.  Press the button again, the lift comes down.

The behind-the-scenes MUD can monitor the status of the lift, communicating 
with the client the current position of the lift, what happens when you 
push the button, etc.  Suddenly, things start to get very easy.

The practical upshot is that this kind of thing is incredibly easy to 
implement inside the MUD.  And it's processed by a seperate machine that is 
not the server or the client, which can then take reduced roles, thus 
increasing the efficiency of the entire server cluster.

I am losing my train of thought, as my mind is swimming with ideas...but I 
think you get the point.

David Jackson


_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd