View Single Post
Old 04-24-2013, 12:11 AM   #82
plamzi
Senior Member
 
Join Date: Nov 2009
Home MUD: bedlam.mudportal.com:9000
Home MUD: www.mudportal.com
Posts: 292
plamzi is on a distinguished road
Re: Do MUDs need to be "brought into the 21st century"

I wasn't handwaving any complexity. You accuse me of handwaving, and KaVir accuses me of exaggerating, while all I'm doing is giving my own perspective. In this case, I didn't even give you a rough estimate, so there's no way you'd know if I'm underestimating the challenge

I merely said that the end result of a well-designed graphical inventory is probably going to do a much better job than an all-text one because it has some built-in advantages. The same doesn't strike me as true when it comes to dealing with dozens of mobiles or players in the same room, for example. The endless expandability of a typical MUD "room" is just hard to visualize. I know because I've tried.

I find what these clients allow to be extremely limited, so I believe you when you say it gets hairy. Fortunately, we now have HTML5, mature libraries like jQuery, and a wealth of "primitives" of all kinds that we can leverage.

That's another thing I wouldn't advise. I'm all for leveraging anything that gets us closest to the goal. The "proper framework" for a web-based client, to me, is HTML+CSS+JS, and there are a great number of things already written and licensed very liberally.

I'm not so worried about what MUD vets demand. After all, they are highly unlikely to abandon their favorite MUD client for any graphical wonder. But, for the sake of argument, I have build interfaces to server-side aliases/triggers/variables. I implemented server-side triggers precisely because it lets me just build interfaces on different clients. Those interfaces are pretty basic compared to stuff like battle and inventory management because they're for advanced users and don't have to be sexy. They were actually about as quick to build as their all-text counterparts.

Maybe I'm guilty of both overestimating and underestimating challenges What I'm certainly *not* guilty of is lack of enthusiasm, lack of industriousness, or lack of first-hand experience in what I'm talking about.

When you read the full sentence, it is clearly the license that "cannot be transmitted to another party." Not being able to transmit the license (and having to go to the source to obtain one) is standard stuff.

Believe it or not, I've done my homework. I've read and researched and understood the licenses for all the art I'm using. Before anyone starts worrying and losing sleep, they should at least read the full text of this particular license carefully:

The restrictions below specify that you have to integrate the art into your own product as opposed to re-package and re-sell it. They also specify the maximum resolution you can post on the Internet. But they explicitly allow using the art in commercial software, magazines, newspapers, books. Now, do you think it's likely that they expect these newspapers, magazines, and books to only be sold to people who have contracted the person or party that holds the license?

Clearly, everywhere in the license "client" is used as synonymous with "customer", someone that you render a service to. Either that, or they expect you to sign a contract with every visitor to your website.
plamzi is offline   Reply With Quote