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

[Yaka St.Aise]

Chris:

I fully susbcribe to the idea that standardized, commoditized
languages and protocols are the way to go to both lower the costs of
entry and foster innovation by enabling more widespread and
effective use of middleware and modular components for gamaking.
Obviously here, open source tools are an invaluable asset, while
proprietary solutions - providing they comply with "standard
standards" offer some incentives that are of real value (like the
ability to fund costly specialized tools in view of some temporary
exclusivity over the revenues).

At 11:06 -0400 03/09/09, Chris Duesing wrote:

> [...] 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.

Unless I misread you, your take on crossmode game design (meaning
games playable both as text-only and 3D mode) seems limiting itself
to scale down gamestate description and commands from 3D to text.
While it sure offers some challenge, I fail to see how it would be
attractive from the text side of things, be it as a prototype
solution or a production one.

A textual description written only from the cold 3D facts without
real interpretative room for the text engine and the player commands
would be about as much fun to read as your average phonebook, and
would indeed qualify as "graphical MUDs without the graphics" which
is not an enviable position. ;)

What you would get from scaling down would most likely be to the
movie what a postfact moviescript would be to the theatrical
experience, and nothing like a good novelisation of a movie, because
text games aren't just the same minus graphics, and are seemingly
differnt in nature.

 From a production stage commercial game, I fear itwould offer only
 a "poor man's" fallback option, most likely way less entertaining
 than playing a full-featured text-mode game and probably wouldn't
 justify the effort unless there is actually a standardized sintax
 and language that allows the translation for cheap.

 From a prototype perspective, it would probably be even worse
 because the game high concept and valid features would be at risk
 of being discarded along with the implementation because of its
 lack of entertainment value.

To stick to the analogy of movies and novels, what I was proposing
erlier was more on the tume of: writing a novel to flesh out a movie
script in the works.  Meaning designing a text MUD you plan to
*adapt* later into a 3D game, by retaining the key elements and the
ruleset, yet knowing the implementation will not be a true-to-word
translation (that gives you VCR docs, last time I checked).

Rather, let's try figure out what needs more detail in the universe
backstory, look again on fast-drawed plans - what is not consistent
in words will most likely not survive the scrutinization by
dedicated players - etc.

I see it more like a way of improving overall quality of worlds and
rulesets design, and to test the "plan aginst the ennemy", as well
as an opportunity for the early team to get a feel for the bigger
game to come, thus helping the building of a stronger and better (as
in more mature) vision shared by the core development team which
hopefully will smooth some of the difficulties of the longer 3D
development cycles and help adress both the issues of butchering and
dilution that arise when key features go back to drawing board (or
to the bin) 1 year into development, up to the point nobody
remembers anymore what this darn game was supposed to be about in
first place .

All in all, it sounds to me like a way to spend more time with more
flexibility - and possibly at lighter-to-no cost - on the
pre-production and design stage, rather that the current "3 month
design then crunch away" style of development of MMOGs.  And nobody
prevents the text-game to stay alive and evolving once the 3D
"sequel" is on the market.

Best,
	Yaka.
--

	_________________________________


	Best viewed with your glasses :-)

	_________________________________
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev