[Home] [Groups] - Message: [Prev in Group] [Next in Group]
16360: Re: [MUD-Dev] A new MUD-standard
[Full Header] [Plain Text]
From: "Kwon Ekstrom" <justice@softhome.net>
Newsgroups: nu.kanga.list.mud-dev
Date: Wed, 28 Feb 2001 01:22:51 -0700
References: [1] [2] [3] [4] [5] [6] [7] [8] [9] <-newest
Organization: Kanga.Nu
----- Original Message -----
From: "Ben Chambers" <bjchambers@phoenixdsl.com>
> however, is that some people (including me) feel that graphics take
> away from the imagination aspect of a text based MUD. What I was
I agree, graphics will take alot away from a text based game, which is
why I like css, it's simply defining colors, boxes, and font-sizes and
decoration. Sure, you can add graphics, but I would probably limit
that to a greeting screen, and use fairly small graphics.
> thinking is that if you define a standard for parsing inbound
> messages, for example the server tells the client that it should
> have four windows, a list, a scrolling box, a coordinate display
> (for maps) and a stat box, then sends messages to these you would
> have a very useful system. the client of course could rearrange
> this, the server
What I am thinking of is using xml as the data source, pretty much
send a header pointing to a default web-site, the client loads that,
frames, etc... additional data is sent using xml and parsed using
xsl, cache the xsl sheets, before long you're just sending data. You
separate a presentation layer, so it's easier to make minor changes.
The header should contain information about options like compression.
> simply sends a reccomendation. I think that the only thing that
> would be desirable is to have sounds. You could use a sound package
> and just tell the client <play_sound name = "hit" volume = "LOUD">.
You could embed sounds in the html, that would take a little while to
download unless it was a midi.
-- Kwon Ekstrom
_______________________________________________
MUD-Dev mailing list
MUD-Dev@kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev