05 Aug, 2011, Runter wrote in the 1st comment:
Votes: 0
JohnnyStarr said:
After studying a bit on web frameworks, I see how the mud community would benefit greatly by
having a framework that could be used to accomplish heavy lifting for new developers.

I think it could even benefit from using a MVC design as far as game objects go. […]


Full disclosure. This is moving away from the idea of a framework and towards the idea of a pattern. And that pattern is, as mentioned, MVC. I've been mulling over this for a month or two, and I think a way to accomplish the MVC pattern can be found by looking at html/css and js. In properly designed html, html would be the model, css the view, and js the controller. After considering this, I thought it might be interesting to use css as the missing link in a mud on the server-side.

So, what's the point? Well, the point is it's much cleaner we've found in HTML/Css/js to separate these three things. Writing inline styles in html is absolutely gross and not maintainable. Writing js inline isn't much better, but at least it's segregated by virtue of technology. In a mud we typically combine all 3 of these things, because there's no virtue of different technology. And we don't see the benefits of centralizing styles and keeping them away from the data, but make no mistake. There's big gains to be had. It can turn around a mess and make it very manageable. There's a lot of muds out there separating the controller and model, the view is the part that is up in the air. I'd like to talk about a proposal to do that using CSS.

Basically, it would require either writing a css parser (which is more work than I'd be willing to do.) or just using one written for us. Here's an example of one written for us.

Before I elaborate, I should make it clear…the client wouldn't use the css. The server would. It makes no sense for the server to use the css, you say? Well, it also makes no sense for the server to be a renderer for the client…yet muds generally all do it. So following this pattern, the renderer, no matter where it may be, can make use of css.

In addition to that, I am not proposing using html. CSS is a technology separate from html. In fact, the css related to a mud wouldn't even need to use the same attributes as you'd expect from html. CSS is rather agnostic about that. Instead we could write css like this:
.genie {
foreground-color: blue;
}
.bottle .genie {
padding-left: 10ch;
}


In this example, all genies are blue. All genies in a bottle have 10 characters left padding.
The renderer would generate a line of text like this based on the rules like this:

Quote
[[color=royalblue]A genie is standing here ready to grant your wish.[/color]]
[[color=royalblue] A genie is trapped in this bottle![/color]]


You can ignore the []'s. I'm using them just to show where the bounding box is.

Relating the html model to the mud model, generally you can compare tags to classes. For example, where you might have a <body> tag containing a <div> in html. And that div may contain many other tags. So in the mud world you might have a Room containing a Player. And a Player containing many Items.

So where does the css concept of classes and id's come into play? A great comparison for classes is actually flags. So this css rule could match a player that's dead:

player.dead { color: red; }


In that example, we want players who are dead to be displayed in red.

In normal css w/html you could expect something like this:
div.red { color: red;}


And a great example of id is simply the vnum! If your mud uses a vtag system, even better, as long as it's unique. :)

A quick example of matching just my vtag of alucard-the-vampire-king:
#alucard-the-vampire-king {}


Switching gears back to the player red rule. Consider the following html. It has a class (poorly named red) that can be matched against to make the content red.
<div class="red">
This content is red! Just like the player who is dead would be.
</div>


But this markup isn't really useful for our mud world. Our mud worlds model is a little more complex. So… Let's consider the 'markup' for our mud world.

ch = Player.new(:name=>"Retnur")
ch.toggle_flag(:dead)



And the flag itself can act as the class. Making the previous example match it great. The point I'm trying to make is that the html is just a scaffold for the data.

It's important to mention that these are naive examples of what css can do. The real power is localizing css. You could have a global style sheet, sure. We've been doing that in these examples. But things might get interesting when a builder puts a style sheet in their area. Maybe for some reason all demon npcs short descriptions are styled differently in this zone. This builder decides just the short descriptions, where-ever they appear in this zone should cascade and override the global style sheet. This is the real power of css.
#some-specific-area npc.demon > short { color: dark-red; }



Here's a quick and interesting example I made scaffolding html:
http://jsfiddle.net/T8sUD/3/

I want to stress, the html isn't important. What's important is that css can match against a model. I repeat, the html isn't important.

If you look at the example, however, there's two distinct blocks being rendered. Both are in response to commands. You can think of this just like web-page requests. In a website, generally, the client "clears" the screen. So imagine if your mud client cleared the screen after it received any block of text. It doesn't, but it *could*. Not that we want it to. But this helps us consider each block of text received as a new view based on a route. In this case the route was "look" and "look at retnur". In http we might consider this to be /look/ and /look/at/retnur/ since we're restful around here.


Fallback Mechanisms
The style could have properties that can't be used because the client connected won't support it. Like, for example, changing the font face. But there are technologies and clients that the server and client may be in agreement to use to make it possible. So the answer is simple. Just as in web clients, you use what style the client understands. If you're using MXP and you know you can change the font face, then that's a valid style. If it's not valid, just don't use it. That would be done in the renderer implementation.

I admit, this is a bit of an academic discussion…because I'm not willing to come outfit YOUR mud with this system. I may implement something in my codebase just as a test bed. But I think this type of design would be a huge step forward. I think the first step in this direction is just starting small and implementing a few attributes, then going from there. The applications as I see it could work in just about any mud, though.

I've already tl;dr'd this out, but I'll probably post more ideas since I didn't go over it all as I consider it more (or maybe actually have a working implementation to show.)

Here's a link for more information regarding CSS for beginners. It uses html to teach it, but just learning how the css rules work is what's important in this context.

http://www.w3.org/Style/Examples/011/fir...
06 Aug, 2011, Runter wrote in the 2nd comment:
Votes: 0
There's a wealth of knowledge here.

http://taligarsiel.com/Projects/howbrows...

It describes in detail how some of the major browsers are architected. I'm very interested in the CSS section, and it was a great read.

Quote
Style computation brings up a few difficulties:

Style data is a very large construct, holding the numerous style properties, this can cause memory problems.
Finding the matching rules for each element can cause performance issues if it's not optimized. Traversing the entire rule list for each element to find matches is a heavy task. Selectors can have complex structure that can cause the matching process to start on a seemingly promising path that is proven to be futile and another path has to be tried.
For example - this compound selector:
div div div div{

}
Means the rules apply to a "<div>" who is the descendant of 3 divs.Suppose you want to check if the rule applies for a given "<div>" element. You choose a certain path up the tree for checking. You may need to traverse the node tree up just to find out there are only two divs and the rule does not apply. You then need to try other paths in the tree.
Applying the rules involves quite complex cascade rules that define the hierarchy of the rules.
06 Aug, 2011, RoFAdmin wrote in the 3rd comment:
Votes: 0
Hey Runter-


So, ill first start off by saying the IDEA of using css to stylize the output of a mud is an interesting one. There are however several things that have poped in to my head.

1) How would you actually go about displaying the text in the style that was needed based on the text you are receiving? I notice your using ruby in your example, im not well versed in ruby, and since this was under general code and design ill use C to demonstrate that im talking about.
sprintf(buf, "Well hello %s, i see you have your handy %s with you.", ch->name, obj->short_descr);


What is going to tell any of that that ch->name needs to be green, and obj->short_desc need to be yellow and padded on the left 15 characters?

You would need some sort of function that you passed an object to, and the name of the variable you wanted. Then it would look at the object, check the styles on it, grab the variable data and mark it up accordingly and return it.

There are however some problems using this approach.
A) In order to do this approach you would need to use a language that has reflection since you are trying to look up a object property by name. C/C++ does not support this.

B) To use your genie in a bottle example. You are assuming that every genie in a bottle is always going to need to be displayed that way. But that may not be the case, but by assigning styles like that, All genies in All bottles will always come out that way.



There is a reason that CSS is used with HTML tags.
Just because one time i type "I LIKE BANNANAS" in a particular area and want it size 17 font, and blue with underlines does not mean that i want that phrase to be size 17 font, blue and underlined everywhere.

To me it sounds like adding CSS is more overhead then its worth. Another broken example for you.
You said ok, All Players Dead show up in red. Well what if i have a function that shows you everyone in the same area as you. And i want it to show Everyone in the same guild as you in green, and everyone not in red? How would that work? How would if work if i had several guild members in the area, but they were dead…

This is why in web pages there is a separation between whats being displayed, and the markup that styles it. You arent saying "make this block of text like this", what you are saying is make this container have these rules, and things display in this container display this way, this time. I could put the same th ing in another container, and it will look totally different.


Does any of that make sense? Like i said the idea is interesting, but if I think if you really wanted to use CSS to stylize the display of the output, it should be done on the client end, and then more then likely you will be sending data across to properly work with CSS in either XML, or HTML. This does of course take it away from the server end of things which seemed to be the idea behind the post, but its the way i see it working best.


Menser
06 Aug, 2011, Twisol wrote in the 4th comment:
Votes: 0
RoFAdmin said:
This is why in web pages there is a separation between whats being displayed, and the markup that styles it. You arent saying "make this block of text like this", what you are saying is make this container have these rules, and things display in this container display this way, this time. I could put the same th ing in another container, and it will look totally different.


I completely agree with this sentiment. I support the general gist of this idea, but the examples you've given don't show how to display content differently based on how it's used, only based on what kind of data it is. I think that, rather than rendering the object directly as the tag, a templating layer should be used. Here's an example of what I mean:

/* Example CSS */
.farsight name { fgcolor: blue; }
.farsight .room { text-align: right; }


players = me.area.players  # find everyone in my area

list = TableNode.new(:class => "farsight")
players.each_with_index do |player, i|
list[i, 0] = NameNode.new(player.name, :class => "name")
list[i, 1] = TextNode.new(player.room.name, :class => "room")
end

render list



It's not a great example of -how- to do it. This kind of thing needs some in-depth experimentation to figure out what will and will not work, which I have done none of. Still, the basic idea is to define new nodes (akin to HTML's anchor node <a>, table node <table>, generic block node <div>, etc) tailored to MUDs, and use those to build up the data structure. Then you apply CSS to it to make it appear how you want.
06 Aug, 2011, Runter wrote in the 5th comment:
Votes: 0
Menser,
First of all, Thanks for the reply. I agree with some of your points, others I disagree with. I'll reply to a few now in addition to some code I incidentally was about to post that proves the concept out.

Quote
1) How would you actually go about displaying the text in the style that was needed based on the text you are receiving? I notice your using ruby in your example, im not well versed in ruby, and since this was under general code and design ill use C to demonstrate that im talking about.


You would need to delegate the world to a generic rendering system based around nested blocks. Just like HTML renderers do. Typically one line could be a block. See my proof of concept for more info on that. Your example isn't workable because you're not using any rendering pattern. You're just sending text straight out.

Quote
What is going to tell any of that that ch->name needs to be green, and obj->short_desc need to be yellow and padded on the left 15 characters?

You would need a structure of nesting that you can build and match rules against. The class of the "element" would be the type. The flags would be the css class. And you can use some unique identifier for the css id. So to be clear, there would need to be an intermediate format. In your examples the attributes of ch could be matched against with the following css for a rom mud:
chardata string { color: white;} /* all string attributes of the character display as white */
chardata #name { color: blue;} /* but name cascades (overrides) to display as blue */

So following the pattern you either use the class for what is nested (string for attributes, they're nested in the character as far as the rendering structure is concerned) or you use their unique identifier. The unique identifier is totally reasonable to be their variable name.

Quote
There are however some problems using this approach.
A) In order to do this approach you would need to use a language that has reflection since you are trying to look up a object property by name. C/C++ does not support this.

Well, whether or not c/c++ has reflection is a topic for another day, but if you're trying to convince me that C/C++ is a bad choice for anything but drivers, then yes, that's true. ;)

Quote
B) To use your genie in a bottle example. You are assuming that every genie in a bottle is always going to need to be displayed that way. But that may not be the case, but by assigning styles like that, All genies in All bottles will always come out that way.

This strikes me as a weird thing to say, because if you write a global rule that matches against all genies…then yes, it'll match all genies. It's not difficult to write a localized rule. Let's make the assumption genie is implemented as a type so we can use genie instead of a npc.genie for a flag. If it were implemented as a flag you'd do it that way. Example follows:
/* these will cascade towards the bottom.  */
#mensers-awesome-area npc { color: green;} /* match all npcs in that area */
#mensers-awesome-area npc:first { color: grey;} /* matches the first npc rendered in a buffer*/
#mensers-awesome-area npc:last { color: purple;} /* matches the last npc rendered in a buffer */
#mensers-awesome-area genie {color: yellow;} /* match all genie in this area, assuming it's implemented as a type */
#mensers-awesome-area room > genie {color: blue; } /* match genies directly nested in a room. */
#mensers-awesome-area genie.asleep {color: grey;} /* match all genies that have asleep flag set */
#mensers-awesome-area item genie {color: red;} /* match all genies contained in any item */
#mensers-awesome-area item.lamp genie {color: silver;} /* match all genies contained in any item with lamp flag */


I wrote a bunch of random rules there to show how the complexities can be used to cascade attributes.
So let's type look full of npcs in your area and see what we'd get:
Quote
A frisky fido is barking here.A frisky fido is barking here.
A frisky fido is barking here.
A frisky fido is barking here.

A frisky fido is barking here.
A lamp is here, waiting to be rubbed.
A clear bottle is here…looks like an angry red genie is trapped inside!


so then we look in lamp:
Quote
A genie is here.


we look in the bottle:
Quote
A genie is here.


To further address your previous concerns, you could match against specific attributes like this:
#mensers-awesome-area npc #short_desc { mxp-font-weight: bold;} /* match all npc short descriptions in mensers-awesome-area*/

So all npcs short_desc just in this zone would get the mxp-front-weight bold attribute. Our renderer if the player seeing it has mxp enabled would apply the bold font weight. Otherwise it wouldn't be bold. But that's okay, falling back is what css is all about when styles are not renderable.

Quote
There is a reason that CSS is used with HTML tags.
Just because one time i type "I LIKE BANNANAS" in a particular area and want it size 17 font, and blue with underlines does not mean that i want that phrase to be size 17 font, blue and underlined everywhere.


Well, that's not accurate. CSS has to have a structure to cascade against. HTML does it nicely. But any nested structure works. Muds naturally have such a structure. Rooms are nested in areas. Npcs, items, players, descriptions, exits are nestd in rooms, Items are nested in npcs and players and other items. The structure is already there. CSS can have rules that match it just as well. The replacement for css classes is whatever you define it as. I like flags for that. And I like unique identifiers for the css id. And as already stated, the css type it matches against can either be builder defined (like genie) or fallback to the name of the class itself. Like npc, player, or room. If you're using a nice programming language, all that work can be done for you immediately like in my example.

Quote
This is why in web pages there is a separation between whats being displayed, and the markup that styles it. You arent saying "make this block of text like this", what you are saying is make this container have these rules, and things display in this container display this way, this time. I could put the same th ing in another container, and it will look totally different.


You should reread my comparison between http requests and outgoing blocks of text. The comparison works quite well. A request in a mud can be as small as one line of text, or as large as whatever your look command results in coming back to the client. It works, even if you think it doesn't. ;)

Quote
Does any of that make sense? Like i said the idea is interesting, but if I think if you really wanted to use CSS to stylize the display of the output, it should be done on the client end, and then more then likely you will be sending data across to properly work with CSS in either XML, or HTML. This does of course take it away from the server end of things which seemed to be the idea behind the post, but its the way i see it working best.


Here is why you're wrong. You already render what your client is going to see on the server. You don't send the client markup. You format the text the way you want it before you send it. When you pad something of right align it, or any of that stuff, before sending the data—that's a form of naive rendering. It's naive because people don't really recognize they're doing something the client is supposed to do in the first place. Well, some of us recognize that. So what's the answer? Having the client do all the rendering? YES! Are mud owners going to do that? Nope. So this is a legacy solution that cleans up things nicely imo. In other words, with this solution you could still connect with telnet and get the development benefits of css while writing how things should render.



Without further adieu here is a working proof of concept.

https://github.com/jeffreybasurto/css4rb

This proves it out pretty well. In the interest of saving time it here is the main file it uses:
# room with a player in it, in an area
player = Player.new
room = Room.new(player)
area = Area.new(player)

# print the rendering out, respecting the css rules of course.
puts player.render("Retnur is standing here.", :with_bounding_box=>true)


With the first 3 lines of code we build a nested structure. (i do it in the initializer for anything that inherits Selectable). And any of these things is renderable. In this example I just want to render a string in the namespace of player.

This is comparable to how a web client may render
<area>
<room>
<player>
Retnur is standing here.
</player>
</room>
</area>


Even in html if you want more control over elements you'd have to write something like this:

<area>
<room>
<player>
<long_desc><name>Retnur</name> is standing here.</long_desc>
</player>
</room>
</area>


But the absence of that structure being included is something a rendering structure can cope with. You don't have to include everything possible to be matched against. And we don't. If we want that extra structure we could do markup for it. Consider:
puts player.render("<long_desc><name>Retnur</name> is standing here.</long_desc>", :with_bounding_box=>true)


This can build an intermediate markup for our renderer so it knows which attributes are where in the rendering. Overall, though, it knows the location of the player variables node in the rendering structure.
06 Aug, 2011, Runter wrote in the 6th comment:
Votes: 0
Here's the css the proof uses.
/* every player */
player { width: 80;}

/* every player inside of a room (any nesting level) */
room player {
align: right;
mxp-color: navy; /* example of something not supported on all clients and how it can fall back */
}

/* players directly nested in a room. */
room > player { height: 3; }

/* every room */
room { align: right;}


/* this rule isn't matched against */
player room { something: irrelevant;}


Here's the output.

[                                                        Retnur is standing here.]
[ ]
[ ]

[]'s are displayed to show bounding box for te renderer.
07 Aug, 2011, Deimos wrote in the 7th comment:
Votes: 0
Very cool read. I'd be interested in seeing a server/client combo using JSON or YAML as a markup and styled client-side in this manner. Short of that, I can still see great benefits from using this kind of separation of concerns server-side.
07 Aug, 2011, RoFAdmin wrote in the 8th comment:
Votes: 0
Hey Runter-

Well on the plus side your a genius an answered a question I had but didnt really ask.

So i can see how your idea would work now. Which has lead to a few other questions.

1) You said this would be great for legacy adoption to allow people to control the formatting of the output since current mud owners wouldn't switch to using a client that handles the rendering.

Would this really best be implemented in a legacy codebase? Especially since a good amount of them are written in C or C++ which we already glanced over would have severe issues with this sort of system?

Since it basically requires you to change code everywhere in your base you are sending text to the player, do you really think this is a "good" option for legacy bases? Do you think its one many would implement?

I could see this being a more realistic idea if it were done in new or upcoming codebase, however I see it being tedious to put in to an existing one. However, If this were something that was better to put in to a new codebase that brings up another question. Wouldnt it be better to design a system where the server just hands out text and the client handles the display it up?




Dont get me wrong now, I think the idea is a good idea, and has merit. I however dont see it being something many older bases would bother to install, especially since more then likely they are already formatting their text how they want. Never mind its easier to change formatting with yours once its done, you have to get them to install it, and change their code first.



I think a better way to go about changing how muds display things would be to come up with a client that supports something akin to xml or html with css.

While i was pondering over all this, here is what i envisioned the proper way servers and clients would handle everything, and the underlying technology it would use.

It would use HTML, CSS and Javascript to handle the client end of displaying things.

Upon connection to the server, the server informs the client of the location of a webpage to load, or sends the contents of the page itself.
Client loads up this page and associated JS and CSS files to create the look of the client.

By doing this the client could be used for any game, and all a game would have to do to customize the look and feel of the client would be to create their own layout.

From that point out all the server has to do is send text with the proper tags and such and the client will handle the display and look of everything. Would even work well as a drop in to existing muds since you could specify that untagged text is directed to the default display box using a the default css rules for display. This way existing muds could go back and change the text they want when they want if they want to use the new system.

I know its not the same as your idea, and i get the reason for your idea, and I like your idea, im just not sure of the practicality of it. Plus, as you said we KNOW that its broken that the server is handling the display aspect of the game. Are we to continue with bad practice because everyone else does?



What I think would be great would be if some of us would get together, and and create this client. Im well versed in HTML, CSS, javascript and jQuery. It appears you are at-least somewhat skilled with them as well judging from your haiku mud project. Im pretty sure me and you could whip together what was needed of a client to make that possible. From there we would just need to come up with a communication protocol. Kavir and scandum seem to be pretty protocol happy sorta guys, so perhaps they could throw their two sense. I saw twisol posted as well, and im pretty sure he was the one with A web techonology based client done already. So im sure he could be very insightful as well.

We all have our codebases we are most familiar with. After that its simply putting together a couple snippets for the popular code bases to drop in so people can utilize our client properly.

Worse case scenario: We have given a way to correct a long standing issue of having the server generate the display. We have created a client that is readily use-able by anyone in either a current or new base they decide to make.

Best case scenario: Wide spread adoption, and better looking and useable mud displays all around!


Whos in?
07 Aug, 2011, Runter wrote in the 9th comment:
Votes: 0
And I made it clear in my original post that I thought it was mostly a topic of academic discussion. But we can't have our ice cream and eat it too. Either we are not going to use a custom client, or we are going to continue rendering on the server. So instead of replying to your entire post piecemeal I'll just say that. It's not out of the realm of possibilities that someone would be willing to consider such a system in a cleaned up version of a fairly standard codebase.

Furthermore, mud owners aren't really willing to give up on legacy. They aren't, usually, because their playerbase uses legacy clients that won't handle markup/css. If they're willing to spend years of their life writing code on ancient codebases, if they have the inclination it may be a powerful enough reason to build a better mousetrap.

And one final comment, I already am writing a codebase that doesn't rely on legacy. (haikumud) and no, I'd never suggest using CSS on the server as an optimal solution. However, it is a much better one than what typical codebases are doing currently with regard to formatting and styles.

So instead of naysaying, I'd prefer to get constructive feedback about the best ways to implement such a thing. It's not enough to state some of the obvious: C is bad. Most people aren't even skilled enough to implement something such as thing. A client doing the rendering would be better. It would take some time to do it in existing codebases.
07 Aug, 2011, Twisol wrote in the 10th comment:
Votes: 0
RoFAdmin said:
I saw twisol posted as well, and im pretty sure he was the one with A web techonology based client done already. So im sure he could be very insightful as well.

Aspect, yes. It's not done yet, but I'm still working on it. Aliases are more or less working, but I need to spend some time polishing up the actual GUI.
07 Aug, 2011, RoFAdmin wrote in the 11th comment:
Votes: 0
Hey,

So I think perhaps you took my post the wrong way, or perhaps i presented it wrong.

Im not nay saying the idea, as i said, after your follow up posts i saw very clearly what you are talking about now, and think it does show merit. I was simply saying that if it were developed I'm unsure it would be something people using legacy code would use and would best be suited to a new project. This however does not make it useless as currently there are no mud clients that I am aware of that actually handle the display formatting themselves.

I also do feel my post was constructive, though perhaps not to the end of how to implement such a feature, and while I did state some of the obvious, it was things that in your original proposal there was no mention of.

Academic discussion includes both positive and negative feedback and criticism. Its easy to talk about the benefits, and features of something, and easier to overlook the obstacles, hurdles, and pitfalls of something.

Me, im the kinda guy who is like GREAT IDEA! Now here are the problems i see with it, how do you propose to overcome them, fix them, or get around them.

Your original proposal talked about using css to standardize the output of a mud to provide better display options for legacy bases.

Is it feasible?: Yes
How would you do it?:
Actual implementation depends strictly on the language the parser is written in, and the code-base it is being implemented in.

Problems:

Lack Of Server Standardizationg:
Since the parser would need to be aware of structure and hierarchy of Areas, Rooms, Objects, Players and so on, as to properly assign the css, this means a parser would have to be written for each code-base that uses a different hierarchy or language.

What your talking about is implementing a standardized display procedure for various programs that themselves follow no set standard for organization of their data.

CURRENT FORMATTING OPTIONS:
Now as far as formatting(not colorizing, but simply text placement and orientation) there are already several snippets of code out there that allow you do such a thing with far less implementation then what is proposed. They are pretty much drop in these files, call associated functions to format, done.

As far as color goes, most muds already have the ability to display color, and since the method proposed to use css already requires them to edit anywhere text goes out; so why not just add your color tags there and call some formatting functions on the text?

Now I already know what your probably screaming in your head. Doing that defeats the purpose of separating the data from the display. Why certainly it does, and I get that concept, and how it can be beneficial. Doesn't mean others will, or that they will find the time investment needed to implement this sort of display mechanism a worthwhile trade off.

TEXT MARKUP:
While the proposed css solution does handle standardization of display without the need for marking up text in most cases, it would appear for the examples you gave that it would still require additional markup where you wanted the text to use rules other then what was specified give the structure of things. Thus you are in some situations still having to mark up the text you want to display as you would with color codes and formatting libraries.

While i don't consider markup bad, what it does cause in the proposed solution is added overhead as the server now has to figure out all the rules that apply to this display scenario before outputting the text. Color codes and formatting functions would be much quicker here i think. Why would we want to add more overhead?

LEGACY ADOPTION
The original intent of the proposition seemed to be for legacy muds.

I think the time investment vs payoff is to little for someone running a legacy code base to implement this sort of display mechanism especially given existing color and formatting solutions.

In addition, as i said previously, given the choice of language of a majority of the poplarlegacy code-bases in use are it makes the proposition an even further challenge.


WHERE WOULD THIS BE USEFUL
As i said where i could see this being useful is in new or developing server bases. Since there is no client out there that really handles the display of data itself (unless its proprietary to the mud) this would allow for a great and easily maintainable way to handle your display.

It would be much easier to develop a library for each language for displaying this data and have people adopt that setup or expand that to fir their needs, then to go back and try to duct tape together a solution on a per language, per code-base level.




As i said, don't take this as nay saying. Think the idea is great. Those are just hurdles i see to the original idea proposed.
I'm just giving what i feel is constructive feedback, Im sorry if it is not necessarily of the type you would prefer, but i think it is beneficial non the less.



_-Menser-_
07 Aug, 2011, Runter wrote in the 12th comment:
Votes: 0
Sorry, I feel like every issue you've brought up so far has been a red herring. I don't think red herrings are constructive. I disagree with just about everything you've said so full heartedly that it's unlikely we're going to agree on anything. I think the negatives you are bringing up are in large non-issues. And if X being more machine efficient than Y was a good excuse no matter what the trade is or target technology running the code we'd all be writing assembly.

And just to be clear, you're the only person on this thread talking about adoption or standardization. So you're only arguing with yourself.
08 Aug, 2011, Runter wrote in the 13th comment:
Votes: 0
I rewrote some of the code I had and currently it works like this:
Area.new(Room.new(player = Player.new))

player.name = "Retnur"

puts player.name.render()

player name {
align: center;
width: 13;
}


producing:
Quote
[ Retnur ]


It was brought to my attention that the world model may not always be appropriate per view. It certainly is appropriate in a lot of places, like looking, or looking at a player. But it's also not always so appropriate. In those cases I forgot to mention how you'd overcome this problem.

The easiest way and the way I would prefer is simply using markup, but since I'm writing this for other peoples approval you can imagine a score command like this:

From score.erb.txt file:
<% "score".to_tag do %>
Your score sheet:
<% player.to_tag do %>
name: <%= player.name.to_tag {player.name } %>
hp: <%= player.heath.to_tag {player.health } %>
moves: <%= player.moves.to_tag {player.moves} %>
<% end %>
<% end %>

Edit: This isn't markup. It's an erb template. Similar template engines exist is just about every language.

That would produce a structure we can render against to match css like this:

score { color: red; } /* entire score defaults to red */
score player { color: blue; } /* any field of a player is blue in a score*/
score player name { color: yellow; } /* except the name, we want that yellow */


This handles views in a very consistent way similar to how rails and others do using templating engines. If you had css defining how a player anywhere in any structure was viewed, it would still apply to these. Although you can override it like I did above. In this case, it applies just to the score command's view.

Quote
Your score sheet:
name: Retnur
hp: 100
mana: 250
09 Aug, 2011, Mastermosley wrote in the 14th comment:
Votes: 0
When the parser interprets the css what is the output of it, and how does the client interpret the parsed string? Is my confusion warranted or am I missing something? I would like to know more on this subject as I am working on a codebase in C# and would like to integrate a formatting system like this.
10 Aug, 2011, Runter wrote in the 15th comment:
Votes: 0
Well, like the title of the thread says, the css is used on the server. Not the client. So the server takes the css that presumably was written by builders of some kind, and applies it to the views as they are rendered and sent to the client. Once the rendering process happens, it's just plain text. So the client need not understand any special language. It need only be able to understand whatever the renderer produced. Which should be plain text in most cases under this system.

But to answer your question, each parser is going to produce something perhaps unique. They'll all be an intermediate format that's designed to be queried for rules quickly. WIth global css you'd only have to create this intermediate object one time.

By far the easiest way, and the way I used to get it working, is to find a css parser written for you. Then to match the rules the easiest way is an XML or HTML library like hpricot or nokigiri. These will let you build a partial document object model without necessarily dealing in html.

In a language where those tools aren't readily available, all this would be very difficult to do.
10 Aug, 2011, Tyche wrote in the 16th comment:
Votes: 0
It occurs to me that CSS is just a macro language for HTML. I know it's a bit more than that, but for the purposes of creating a user -friendly server side markup language…

What I did in TML was to just define a directive called CLASS. I left the definition of that directive vague. However I think it could be used as macro language.

For example:
[class speech]Bubba says, "Hi Biffy"[/class]
[class description]The sword has a ruby encrusted hilt.[/class]


The classes might be defined with a dictionary like…
style_table = { 
"speech" =>"[color fuchsia on blue]%%[/color]",
"description" =>"[color blue][size +3][font wingdings]%%[/font][/size][/color]"
}

Where the markup is recursively substituted with the directives in the macro.

Perhaps one could use something more complex like defining them with regular expressions and use group substitution.
Like… {"speech" => [/(.*)/, "[color fuchsia on blue]#$1[/color]"]}

Allowing the user to edit their own personal macro/class table server side would allow them to effectively skin the muds output.
The final output to the client would be something negotiated like XTERM, VTnnn, ANSI, MXP, Pueblo, HTML, etc.
10 Aug, 2011, plamzi wrote in the 17th comment:
Votes: 0
I think the main use of server-side css would be if, say, a new codebase wants to offer adopters an easy way to customize the look and feel of the entire game. However, some other use cases also come to mind:

You could offer end users the ability to select templates and even create (upload?) their own. Because everything is done by the server, regardless of their current client, they'll get their preferred style and color scheme when they log in. A lot of mud vets are very particular about color scheme and may be induced to stay in your game if they can make it look like "the game they used to love that was shut down".

Also, one sunny day you may have a web-based client, in which case you can elect to send the marked up text, move the css to the client-side, and let the browser render (with many more colors and abilities).

As people have already mentioned, it seems to me that this kind of support would probably have to come from the codebase, and most likely that codebase would be written in other-than-C. The payoff is not big enough for me to try to wire a C codebase this way. To be sure, I am already sending html markups to our web client to support hoverable, clickable elements, embedded images, etc., and if one day I want to enable user-customizable colors, I'll be sending class attributes very much like the ones shown in the above examples (except the renderer will always be the client). But chances are I'll be 'hacking' stuff in because that's a lot less work than a modular implementation (due to all the places where a typical DikuMUD codebase would need to be touched anyway).
10 Aug, 2011, Runter wrote in the 18th comment:
Votes: 0
Well, I wouldn't want to write it all in C myself, but I don't see why it would be super hard to leverage a library already written for us.

http://sourceforge.net/projects/htmlcxx/

Of course, just about anything in C is going to be harder to write, but that's the sacrifice C demands.
10 Aug, 2011, plamzi wrote in the 19th comment:
Votes: 0
Runter said:
Well, I wouldn't want to write it all in C myself, but I don't see why it would be super hard to leverage a library already written for us.

http://sourceforge.net/projects/htmlcxx/

Of course, just about anything in C is going to be harder to write, but that's the sacrifice C demands.


A library will certainly help with all the string processing madness, but nothing will help the fact that the presentation layer in a DikuMUD codebase is, well, shattered in a thousand little pieces. It's like you said, this is an MVC concept. That kind of design is usually implemented from the ground up.

I do think that all the folks with 21st century code should take a listen, though.
11 Aug, 2011, RoFAdmin wrote in the 20th comment:
Votes: 0
Hey-


So ive pondered the idea more, cause as i said, i like it.
And ive come up with some perhaps useful comments.

So obviously the first thing to do would be to parse in the css.

Which got me thinking, you dont need to really parse full css. There are only a few properties that would even apply.

align, padding, width, color

align: left, center, right - default left
padding: depending on align, pads to the left or right.
width - defines the reserved width in the display for the data
color: used to set the color to be displayed.

Is there any more we would need to parse?


Where I think this would be cool/useful is if it were expanded some to give the server full control over the view instead of line by line coloring and formatting of text.
0.0/53