|
Thoughts on ZMP.Color
General Discussion
|
|
|||
|
So in the course of implementing ZMP I wanted to run something by you. It seems to me that the ZMP color thing is a bit harder to use than, say, Ansi color. The ability to define colors is awesome, but it seems (I hate overusing the word) like the best use of the feature is when combined with a 'custom' structured ZMP packet. For instance, I've been thinking of letting the client do the formatting of the room description. It would be easier to pass it a ZMP packet with the various bits of info, each 'section' prefaced with a color ID, and then let the client formulate it into the right format. If the client doesn't do the ZMP subset required then the server would format everything using Ansi color which could still be re-mapped on most clients. ZMP .define, on the other hand, is still superior because it lets you plan colors based on intelligent context rather than red = green. Anyway, just a random thought as I get ready to face the work day. It would probably be negligent to implement color.define and not color.use in any case, but thats about the only place where ZMP (or any protocol) seems a bit superfluous, one argument is that you can define 'a lot more colors' but really if you need that much color it will probably not look very good. --- V |
||
|
|||
|
Hey Vassi, So far as the room description stuff, I'm actually of the opinion that if you want to go with a structured way of defining that for the client, the server has no need to specify color at all. Let the client figure it out. Regarding the define/use commands, the biggest purpose of those was again to let the client over-ride colors. I don't think any MUD needs the full 24-bit color specification; it's just there because it seemed silly to arbitrarily limit to the ANSI colors. Especially when a very simple mathematical formula (which I might add to the spec for convenience' sake) can take any hex color code and convert it to the nearest ANSI color. There are also a lot of MUDs that shit rainbows all over the screen, which I intentionally wanted to NOT support. Using color.define and color.use for such a purpose is practically impossible. Perhaps there is a case for having a simpler way of using the stock ANSI colors, though. |
||
|
|||
|
|
Well, I was thinking about this a little more, and how about having a ZMP.Style packet rather than a color packet specifically. It would work like a CSS style, in practice, and it would still be trivial to let the user edit it. More often than not you use colors and formatting in specific ways, for specific things, unless you let your content editors put colors in descs - which is asking for trouble. This would allow you to set the color, bold, underline, blink (why?) or whatever easily and, from a client perspective, would also make parsing input easier. My first client initially did figure everything out on its own, but I do want to support ZMP and release this version (or a subset) for mass consumption eventually. I'd like to cover as many angles as possible. |
||
|
|||
|
|
Blah, theres no edit button I could see so I'm sorry for the double post. I just wanted to clarify that in my initial post what I meant by harder was that, if you wanted to use additional formatting such as italics, you had to use a mix of Ansi and ZMP. Being able to define a style would let you more easily be able to set and reset the current console format rather than having to worry about a mix of switches. It would be nice to be in 'pure ZMP' mode OR 'ANSI Mode' rather than both at once. I don't beleive in using a lot of formatting, but I do believe that a little goes a long way, at times. One thing I like to do is allow italics in object descriptions so that if a player looks at a book any text that is 'written' on the book shows up in italics and, potentially, in an 'alternate font', intended to look like hand-writing or script. So if I could define a ZMP style to do: ID: 1 Name: Writing Foreground: default Background: default Italics: Yes Bold: No Underline: No Blinking: No Font: Alternate Then I could just slip a ZMP.Style.Use 1 packet before my desc, I'd be gold. |
||
|
|||
|
|
I have thought about that, actually. One idea I had had was to use a subset of CSS, especially since I'm big into the idea of a browser-based client (no installation required == win). I decided against requiring a CSS parser in clients, though. Going with an approach like yours, it might be beneficial to use a CSS-derived syntax that mixed relatively well with ZMP. For example, a command where each argument is a simple name=value pair, where name would be identical to the CSS style type and the value would be the corresponding CSS-appropriate setting. I am, personally, not a huge fan of using alternative fonts or styles in MUD text. I'm much keener on the idea of using indentation and tasteful coloration. Especially for clients that stick with a monospace font by default (i.e. all of them), italics and bold and stuff just make stuff really hard to read. |
||
|
|||
|
|
I'm still pushing forward on this idea. My first releases for a while to come will be in the form of a highly-paired set of server and client, to the point that it won't function on regular MUD clients. You've seen the art before, though, so I'm doing it for aesthetic and functional reasons. That aside, though, I want to pare down the client a bit afterward and possibly the codebase as well and release it as a MUD client with ZMP-specific goodness. More to the point on this one, though: CMD: Water.style-define Params: "style-name", ForegroundColor, BackgroundColor, std|mono|fancy,*italic, *underline, *strike, *blink, *bold Summary: Foreground and Background color should be conveyed in hex notation in six or eight digits. (I.E. 00FFFFFF or just FFFFFF). When using six digits, they will be broken d own into RRGGBB, when using eight digits it will be broken down to AARRGGBB, where AA represents opacity. When omitted, it is assumed to be FF (fully opaque). Font type should represent one of three options, std is the 'normal' font, mono guarantees a monospace font for when presentation is critical (Such as text-rendered tables) and fancy for special occasions. All three are user changeable, though mono would ideally only give the player the choice of various monospace fonts. The commands marked with an asterisk are optional, but will be accepted in any order after the name, FG color, BG color, and font type. This command will register a style with the client, but be aware that the user will be able to modify it if they so desire (except for the name). The benefit is that styles allow you to categorize the output of your mud in more logical ways. Users will be able to save their own settings to any style-definitions, the configuration will be kept under the name of the MUD's ZMP Ident tag. After a style definition is defined, this configuration file is checked to see if there are any user settings to overwrite them with. |
||
|
|||
|
|
Eek, what happened to the formatting? | ||