[MUD-Dev] [DGN]: Ludicrous speed.
Michael Chui
blizzard36_2002 at yahoo.com
Wed Sep 10 13:00:15 CEST 2003
--- Chris Duesing <cwac5 at hotmail.com> wrote:
> Actually I think, given that we include contextual information, it
> is theoretically possible to create a game that is as rich to the
> text player as it is the graphical client. It is largely a matter
> of design. We simply need to follow some rules about what
> information gets presented where.
> The first technological hurdle is moving away from the typical
> concept of MUD rooms, where a description is attached to a
> physical space. You would need to move to a system that generated
> descriptions based on location, terrain type, proximity to
> objects, etc. This of course would not be useful to tell a story,
> as some MUDs use the room concept, but is much more akin to the
> concept of the world in a MMO. You 'see' in a MMO what we will
> tell you in our text MUD. In a MMO the means of telling a story is
> moved elsewhere, and is frequently presented as printed or spoken
> text. This is no problem to present on your text client
> either. the UI for movement might require some tweaking on the
> text client, but there are roomless, coordinate based MUDs out
> there already... (aren't there :)
> The second technological hurdle is Natural Language Generation,
> which closely ties in to the paragraph above. In our case it is
> fully a matter of how dynamic you want your descriptions to be,
> current muds do not do this, so we dont HAVE to put in much more
> work if we don't want to.
I had responded to this earlier on top-level, but it didn't get
through the wash.
The single largest difference (as far as I can see) between
textual MUDs and graphical ones are the Room concept. If you
eliminated it, then many textual MUDs would essentially be
graphical MUDs without the graphics. (A coordinate system would
probably solve this.) The next largest difference would be
Interface. Streamline that to work for both worlds and you'll
practically have a game that can be graphical or textual.
I would assume that if you removed the Room concept, it would follow
that you must already have some unorthodox way of executing the LOOK
verb anyway, so the Natural Language Generation problem is solved
here, rather than on the translation layer.
And yes, I am working on a text-based game that can potentially be
translated into a graphical game. :) My current strategy entails
detailing all pertinent (affect-able) structures visible and finding
some way to transform that into a comprehensible paragraph(s).
> I am not a professional game developer, so I cannot truly speak to
> your concerns. However, I do not see this as improving anything,
> since you would need all of the information you originally needed
> for the 3D client plus more. Now if your game was completed on the
> server side and it was going to be 3 months before the client was
> finished, then I could see this as a useful means of starting QA
> early to test game mechanics. Does that ever happen?
Actually, it might be more useful as an audience net. Some people
can't/don't want to run a graphical game, but don't mind something
similar to telnet since it's cheap on CPU resources. Others have
taken sides on the graphical vs. textual argument and want one or
the other. If you pull this off correctly, you just got yourself the
best of both worlds.
I stand on the textual side of the graphical vs. textual
arguemnt. In my game design, though, I'm forced to agree with my
friends in saying that graphical is undoubtedly better in terms of
marketting and "the future". Then again, we can't make one anyway,
so I get my kicks anyway. Add this discussion Yaka started, it also
means that if we begin with the idea of translation possibility in
mind, we might be able to re-launch the game as graphical after some
client adjustments, tons of art, a pinch of 3d programming, and a
dash of music.
Or this is yet another flight of fancy. :)
-Michael Chui
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list