[MUD-Dev] [DGN]: Ludicrous scheme.

[Chris Duesing]

Yaka St.Aise wrote:

> The goal was a noble one: giving the players the choice of fully
> experiencing the game in a anime-style up to photorealistic
> graphical rendering, but most people here can already see what a
> hog it was bandwidth and CPU wise, and why it was eventually
> forgone...

...

> Additional interfaces, suited to limited/specific tasks are a
> growing trend already, but gaining the ability to plug on the game
> various full-featured interfaces would require something text
> games have done pretty well for ages yet 3D games have no clue how
> to: a language as a protocol.

> Meaning a syntax and grammar to describe and act upon facts,
> events, actions and objects at an abstract level, turning the game
> engine and world simulation into a black box with a strict
> server/terminal architecture, and using said language as the mean
> of communication between clients and server.

I actually quite think this IS the future of MMO as long as the
momentum of open source and fanatical game developers continues. Let
me explain... In today's world it is becoming more and more
expensive to develop a large scale MMO. Each major project reinvents
the wheel concerning graphics, physics and rendering. It will become
increasingly less likely for the average programmer to get involved
in a large scale project. This is where open source can get the ball
moving. What we need is exactly these standards for describing a 3d
environment in a mathmatically based protocol. The concept of a web
browser best encapsulates this concept at least initially. We design
a protocol, a 3DML* if you will, and publish a specification for how
to implement it. We then only need an open source client to
implement the standard (though more than one would of course be
preferable). Now we have made the possibility for each game
development team to publish a game without worrying about the client
beyond customization. This could be accomplished with standards for
plugins or scripting languages. Again nothing revolutionary.

On the server side the legacy of MUDs have conceptually paved the
way. We need only a few projects to publish frameworks that others
could take advantage of. We already have one in Java (eXtensibleMUD
- hosted on sourceforge). Here again protocols could radically
simplify things. By creating published standards for framworks one
project could be to add a physics engine, or AI, etc. Now you can
plug your favorite AI engine into your favorite framework, add your
game logic, create your textures and models for the client and away
you go. Want to write your own server framework or client? go right
ahead, just make sure it supports the standards.

This is the commoditization of low level protocols we have seen
since the telephone and through the WWW. The only thing that is
holding us back is, as you pointed out, technilogical constraints
(bandwith, processor speed). But you have to figure that, in time,
bandwith and processor speed will no longer be constraining factors,
and that time can be significantly reduced with lean and
intelligently designed protocols. If we start now, by the time these
technologies are ready for the mainstream (5-10 yrs?) we should be
headed into an era where they are more welcome and less limited by
technology.

> A third issue, if we were to acknowledge the limitations of each
> type of I/O systems, was to be satisfied with some versions of the
> client that could only grant access to a subset of the features
> supposedly available of the client program.  While you don't
> expect a plug-in type IM or email interface to allow you fighting
> realtime furball, the line got blurred when it came to 2D vs 3D,
> or diifferent same-xD clients, leading to a lot of frustration
> because the player could do this, this, and that, but not this,
> and only barely that.  Designing features you know will prove
> frustrating at the utmost is digging the grave of player
> enjoyment, so it was a big-time stopper, too.

Sorry I cut out quotes somewhat randomly from your post, I believe
the point you were making here is that different interfaces to the
same game are problematic for reasons of what information is
neccessary for each. I think in a graphical realm the problem more
or less works itself out by keeping your standard as rich as
possible. In our case by giving the client all of the information
they require for a 3D view of the world, it becomes an issue of the
browser maker or plugin writer to decide how to scope that down to
their intended format. As long as they are consistent, they have all
of the information they need. They cannot make a player do anything
a 3D client cannot (as this system would require sanity checking and
security on the server side). If they did a bad job no one would
play. I am a big fan of Darwinism :)

Text could of course be more problematic, but certainly not
impossible. Of course if the 3DML[1], for lack of a better term,
only encompased a mathmatical representation of the world, then much
of the richness of context would be lost. It would be easy to say
"the ground rises steeply to the east" it would be possible to
describe a beautiful mountain range, but what if this particular
game was set on pluto? Here our options are to expand the protocol
for contextual information, leave this to the game writer to handle
in a plugin, or just ignore text clients and allow any game that
wanted it to account for it in their design and write a seperate
client (or just support the current ones). I dont think this should
be a show stopper.

Chris Duesing

  [1] After I wrote this it struck me that i was very unlilely the
  first person to use the term 3DML, and of course it is true. I do
  not however have time to research what exactly it is as I am at
  work, writing this took more than enough time. It may be possible
  that this is the language we need, perhaps it does not even come
  close. Since I do not know I am just leaving my post as it
  is... More information can be obtained at www.3dml.org, and I will
  of course be looking that up after work :)
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev