28 Jan, 2009, calylia wrote in the 1st comment:
Votes: 0
When I was Imm'ing on a ROMmud, I always wondered. Why couldn't we get player statistics on a website? Why couldn't we get information on our characters, or whether our auction was selling, or even just the skills and help files on classes on a browser, plan our skills and strategies and so on. Why can't we build with a GUI? Writing mprogs like how we do BB code with autoclose, so mprog writers won't forget. In fact, why can't we standardize mprog creation so that it's idiot-proof?

We lost the implementer that everyone loved, and the sub-imp was a total jerk, so i started looking into starting my own.

Here are some of the things i've run into:
-o Mud hosting's traditionally been more expensive than web hosting, and potentially, less secure.
-o More people have access to browsers than telnet, though debatable. Companies tend to block telnet ports more than http access.
-o Web based technologies traditionally involves a database, which could provide me with a more convenient way to handle the help files, compile player statistics.
-o Web based technologies traditionally involve forms, which would make area building more accessible than OLC (although, i guess that's opinion)

There are lots of things that a web based game would take away from a MUD experience, but I'd like to hear what other people think.

Web based … why not?
28 Jan, 2009, Zeno wrote in the 2nd comment:
Votes: 0
Web stats direct from MUDs are often seen nowadays.
http://narutofor.us/arena.php
http://www.bat.org/help/who
http://biyg.org/graphs/
28 Jan, 2009, David Haley wrote in the 3rd comment:
Votes: 0
There's a difference between information being available over the web (e.g. stats and help files) and being able to fully play the MUD over the web, which raises various technological issues. You seemed to be talking about both, although most of your examples had to do with grabbing data, not actually playing.

I suspect that the reason for why it didn't happen is actually relatively simple: most people don't know how, and/or don't feel that it's worth their time to learn and implement.
28 Jan, 2009, Zeno wrote in the 4th comment:
Votes: 0
Right, if OP meant playing via the web could you be more detailed? Do you mean installing a Java telnet component on the website? I did that once. Or something like http://mudgamers.com/

Or are you talking about completely web based? Because then you could argue it's not longer a MUD but a http://en.wikipedia.org/wiki/Multiplayer...
28 Jan, 2009, calylia wrote in the 5th comment:
Votes: 0
Sorry for the confusion. I did actually mean both.

From an administrative point of view, where they have OLCs for areas, items, classes and even skills, this could all be done on the web.

From a playing perspective, I guess i did mean more as a game you could play in the browser, rather than a telnet component that connects to a server.

If then, we argue that it is no longer a mud, but a multiplayer browser game …. Is there something so intrinsically muddy about being hosted as a server? Does a mud have to be restricted to being accessed by telnet only? Am I totally going in the wrong direction if i'm thinking of browser gameplay?
28 Jan, 2009, Zeno wrote in the 6th comment:
Votes: 0
Quote
From an administrative point of view, where they have OLCs for areas, items, classes and even skills, this could all be done on the web.

Personally I think using a MUD client with extensive macros/scripting would be worlds better compared to using a web GUI. A GUI would be more friendly, but as an admin of a MUD I would be aiming for freedom of use over user friendly.

If the web component retains all functionality of a MUD client and adds GUIs for building/etc, I have no problem.
28 Jan, 2009, David Haley wrote in the 7th comment:
Votes: 0
That's the real issue I see with OLC over the browser: you'd have to go reimplement everything that's in the in-game OLC. What are you gaining here? A good text GUI can be very nice to work with. Admittedly, few OLC interfaces are that nice, but that's not a fault of the text medium but of the implementation.
28 Jan, 2009, calylia wrote in the 8th comment:
Votes: 0
Zeno said:
Personally I think using a MUD client with extensive macros/scripting would be worlds better compared to using a web GUI. A GUI would be more friendly, but as an admin of a MUD I would be aiming for freedom of use over user friendly.

If the web component retains all functionality of a MUD client and adds GUIs for building/etc, I have no problem.


DavidHaley said:
That's the real issue I see with OLC over the browser: you'd have to go reimplement everything that's in the in-game OLC. What are you gaining here?


These are two really good points. Obviously, there's personal preference: I did my share of OLC building, and I remember what that's like. There were times when I just wanted a list of items from a couple of areas (say, a continent that includes a couple of areas) so I can standardize descriptions, and it was a nightmare. I remember a long time ago (am i dating myself?) I played around with class snippets, like those "how to add a new class to your mud!" snippets, and later on, an OLC version, where you can add and remove classes online, change their attributes and so on, and add skills learned at different levels and so on … and I had the toughest time trying to do it without having a spreadsheet beside me to figure out skills for 125 levels, and I thought, why couldn't I do this all in the spreadsheet? I daresay that these are examples of where a web based interface would be better than a text one.

I would not argue that an OLC can be, at times, faster and more efficient. But for more complex tasks, like going through lists that scroll off your screen, or changing the order of things, I would argue that GUIs would make things easier.

As for what I'm gaining: One of the things that we had with our builders, probably to the dismay of our head builder, is that people don't do everything. We've had our muds on "crash on boot" mode because someone forgot to set HP to a positive number. Countless mprogs with the wrong or missing ENDIFs. Obviously, there are code solutions to these logical problems, but having the information laid out in good order will definitely help.

I have a question though: what would you consider "freedom of use" as opposed to "user friendly"?
28 Jan, 2009, David Haley wrote in the 9th comment:
Votes: 0
The issue of having lots of data to trudge through is a good place where a non-text environment would be helpful. You can do better than most OLCs by having good search functionality, but I agree that if the data is inherently huge it's nice to have other programs to help manage it. I'm not convinced that a web form-based interface is the best, though. Excel strikes me as better.

Note that the process of figuring out what to build is a little different from actually building it. I'm not sure that forms would make it any easier to design a class, for example.

As for people forgetting to do things, I would argue that with or without a nifty GUI, you'd want sanity checks in place to prevent that kind of thing from happening. Even if it's neatly laid out, people might still forget something. I view this as a problem or solution common to text and other interfaces, not really as a reason to pick web-based building over OLC.
28 Jan, 2009, Zeno wrote in the 10th comment:
Votes: 0
Quote
We've had our muds on "crash on boot" mode because someone forgot to set HP to a positive number.

That should be handled in the code so it doesn't crash. Sure, builders shouldn't be doing it but it shouldn't crash either.

Quote
Countless mprogs with the wrong or missing ENDIFs.

Yeah, I've seen that. But the problematic results are minimal; plus the Imm log should report it (Smaug does).

Just read your code solutions line. I think code solutions should come before trying a GUI.

Freedom of use = previously wrote a script to create a full new complete mob with all the fields based on a template. Builder can now execute that script in a single line and require almost no data input.
User friendy = a button to create a mob where it prompts the user for all the fields, full data input required.
28 Jan, 2009, Kelvin wrote in the 11th comment:
Votes: 0
I agree wholeheartedly that web integration is an excellent way to breath new life into the genre. Be it building, configuration, administration, or development through a browser. The manifestation of this goal is my work on the Evennia MUD codebase that is built on top of Python, Django (a rapid web development framework) and Twisted (network framework).

The idea was to write something that ran off of a relational database, and re-use most of the code that drives the telnet side of the game to run the web front end as well. For example, any changes applied to the game from the web are applied immediately in-game. It's possible to move objects, send messages, change names/descriptions, and modify settings through the web right now. Things are going very well, and it is already possible for an developer to easily make data about any object in their game available via the web (if they wanted to, for some reason). As a fall-back (or for those who don't want a web presence), we currently implement a MUX/MUSH style in-game OLC, but are sketching out the plans for the javascript-based web editor that will eventually be the focus.

Tons of possibilities with setups like this. Web-based character generation is dead simple, account management, forums, and even playing the game is possible through the browser (and in-game) with much less effort than would be needed to monkeypatch an old, "classic" Diku-derivative that wasn't designed for this.

End sales pitch :) Sorry, I get excited about stuff like this. The codebase is already in shape where one could build a game on it, but is not to the point where I'd want to make any claims about feature completeness. We could definitely use a hand, for those who may be interested in something like this.

Evennia Community
Evennia Google Code Project
29 Jan, 2009, calylia wrote in the 12th comment:
Votes: 0
Well, haha, I concede. I won't argue with you guys :) Obviously, I've had to work on a mud that wasn't exactly thoroughly coded. I agree that "crash on boot" and poorly coded mprogs would happen regardless of whether it is web based or text based, and freedom of use, of say, auto mob creation, can happen whether it is web based or text based. Admin and user interfaces, poorly designed, will hamper productivity whether it is web based or text based. These non-platform related issues aside, and the NAME of the thing aside (it can't be called a mud cuz it's browser based) … is there any disadvantage to having it solely browser based (ie. not accessible by telnet)?

Kelvin: Evennia looks pretty good! Unfortunately, python isn't really my thing. I agree with you though, that "classic" Diku-derivatives weren't really meant for mass changes. Adding a new class or new command involves changes in all many different files, and is probably intimidating to the uninitiated, nevermind getting it set up to compile and resolving compiler errors.

I guess maybe this is my dream … that there'd be a codebase easy enough to get into, such that anyone who wants to make a MUD (and by that, i don't necessarily mean accessible by telnet only) can … because there are so many great ideas out there, and it's unfortunate that so many of them are unrealized simply because of the "cost of entry". Of course, for every good game, there'd probably be another 10 with imms that just go around smiting and slaying people, haha, but I have faith that the serious ones will break through :)
29 Jan, 2009, Igabod wrote in the 13th comment:
Votes: 0
I've posted this link somewhere on here before but since this actually relates I'll post it again. It's all browser based mud creation that looks fully featured at just a glance (i haven't explored it much). http://www.mudmaker.com Check it out and see if this fits along with what you're looking for calylia.
29 Jan, 2009, Zeno wrote in the 14th comment:
Votes: 0
I don't understand the appeal of MudMaker, it makes me sick.

Aside from paying for a service where you get restricted up the arse until they "vote" on what new "features" in the MUD code to put in, there also seems to be issues like…
Can't unsubscribe: http://www.mudmaker.com/forum/viewtopic....
If MudMaker goes, the MUDs go with it: http://www.mudmaker.com/forum/viewtopic....

Dozens more threads with issues.
29 Jan, 2009, Igabod wrote in the 15th comment:
Votes: 0
This is true, I wasn't exactly advocating mudmaker, I just like the idea of it. And it looks similar to what the OP was talking about. I was just giving that link as an example of this idea that is already in existence. You can't really knock mudmaker too much though cause they are providing a service that allows non-coders to bring their ideas to life. Sure they charge an arm and a leg but it's still a really nifty idea. And if calylia decides to do something like this then I'd suggest reading the forums at mudmaker and avoiding the problems listed there. It would be nice to have several different places like this around the web.
29 Jan, 2009, Sandi wrote in the 16th comment:
Votes: 0
As far as playing through a web interface….

Telnet is a means of connecting your keyboard to a program on another computer (in the case of shell access, you're connecting to the operating system).

FTP is a means of transferring files across the internet.

HTTP (the world wide web) is a limited form of FTP - a specialised, one-way, file reader.

When you're "on" a web page, you're not really there, you're at home reading things you've downloaded from the web. Yes, you can make an interface to accept text, but it's a far cry from the direct connection you get with telnet.


Couple other thoughts - MERC/ROM was designed to crash on bad files.

Quote
The server reports syntax errors, including the area file name and a line
number… The server also reports semantic errors, such as references to non-existent
mobiles, objects, or rooms… The server exits after reporting any error. Merc takes only a few seconds
to load, however, so it's quite practical to use the whole server as a syntax checker.


You might want to look at Gammon's Area Edit for a GUI ROM building tool. It does all the checking to prevent crashes, and the problem you described of standardizing descriptions would be relatively simple with it's two-pane, Explorer styled interface.
29 Jan, 2009, Igabod wrote in the 17th comment:
Votes: 0
speaking of gammon's area edit, is that modifiable? as in, if I added a new room flag to the code, could I modify gammon's area edit to include that new flag? If not then it really doesn't make things that much faster for a mud that has made any additions to the stock code.
29 Jan, 2009, Cratylus wrote in the 18th comment:
Votes: 0
Kelvin said:
I agree wholeheartedly that web integration is an excellent way to breath new life into the genre.


I agree wholeheartedly with your wholehearted agreement.

I can understand old-timers feeling that from
a usefulness perspective it doesn't tickle their fancy.
But from a widen-the-community perspective it's the
bee's knees.

I personally am perfectly happy with doing all my
mudding/building/coding from a terminal session. But
folks these days see browsers as a perfectly legitimate
(and convenient) place for work and play. Adding mud
interfaces there just makes sense.

Zeno said:
I don't understand the appeal of MudMaker, it makes me sick.


I totally understand the appeal of MudMaker. It just so
happens that they really suck at what they're doing for the
reasons you stated. But I think they represent a shadow
of what the future holds.

calylia said:
I guess maybe this is my dream … that there'd be a codebase easy enough to get into, such that anyone who wants to make a MUD (and by that, i don't necessarily mean accessible by telnet only) can … because there are so many great ideas out there, and it's unfortunate that so many of them are unrealized simply because of the "cost of entry".


Coffeemud is super easy, and it has all sorts of very
sophisticated web stuff, much in the manner you've
described.:

http://www.zimmers.net/home/mud/grinder....

IMO Coffeemud is a heartbreaking work of staggering genius,
and it's a shocking crime that so few people adopt it. It
looks to me like it fits your requirements pretty well.

-Crat
http://lpmuds.net

edited 4 grammer n spel
29 Jan, 2009, The_Fury wrote in the 19th comment:
Votes: 0
Quote
IMO Coffeemud is a heartbreaking work of staggering genius,
and it's a shocking crime that so few people adopt it. It
looks to me like it fits your requirements pretty well.


Well said and i could not agree with you more. I have looked at it on more than on occasion and am staggered at the quality of the codebase and just how much of it is configurable to your own needs and the web based building tools are 2nd to none. If i was ever to do a traditional room based mud i would want something just like that to work from.
29 Jan, 2009, Zeno wrote in the 20th comment:
Votes: 0
Igabod said:
speaking of gammon's area edit, is that modifiable? as in, if I added a new room flag to the code, could I modify gammon's area edit to include that new flag? If not then it really doesn't make things that much faster for a mud that has made any additions to the stock code.


Yes, it is open source.
0.0/57