Login
User Name:

Password:



Register

Forgot your password?
Changes list / Addchange
Author: Khonsu
Submitted by: Khonsu
6Dragons mp3 sound pack
Author: Vladaar
Submitted by: Vladaar
AFKMud 2.2.3
Author: AFKMud Team
Submitted by: Samson
SWFOTEFUSS 1.5
Author: Various
Submitted by: Samson
SWRFUSS 1.4
Author: Various
Submitted by: Samson
Users Online
Bing, DotBot, Google

Members: 0
Guests: 30
Stats
Files
Topics
Posts
Members
Newest Member
488
3,788
19,631
595
Khonsu

Today's Birthdays
There are no member birthdays today.
» SmaugMuds » General » User Lounge » The future of MUDs?
Forum Rules | Mark all | Recent Posts

The future of MUDs?
< Newer Topic :: Older Topic > Oh yes, and I'm still alive.

Pages:<< prev 1 next >>
Post is unread #1 Apr 13, 2015 10:58 pm   
Go to the top of the page
Go to the bottom of the page

Xorith
The Null Value
GroupAFKMud Team
Posts254
JoinedFeb 23, 2003

 
I just recently got back into the whole server admin gig, setting up forums for a graphical MMO that I happen to love, and it brought me back to MUDs.

What is the future though?

A while ago I wrote an experimental MUD server in PHP5. I did this because I had worked extensively with PHP and I knew that the native string manipulation would be a huge bonus for something that is based in the world of text. Here we are in 2015 though, and there's so much more that can be done. I look at MUDs and can't help but feel like they'll never be a viable form of entertainment again. Not as they are now at least.

So what's next?

Pueblo was an attempt to marry rich text and graphics with MUDs, and so was MXP if I recall. Other games, such as Federation II, have gone on to use XML and proprietary front-ends in order to provide a more engaging and interactive experience. I had an idea once, to marry 3D gaming with text-based. The idea was that when a player connected to the game from a MUD client, they got the standard text, complete with ASCII colors and everything. If they connected with a proprietary 3D client, the server would then switch to also include special markups that indicated things like coordinates in the world, 3D assets, and so on. I never got a chance to play with it, but has anyone tried it?

Anyway, just a brain dump. What is everyone up to these days?

Post is unread #2 Apr 14, 2015 10:48 pm   
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

 
Trying to make a MUD with 3D graphics, or even 2D graphics is, IMHO, a waste of energy.

A MUD is an adventure or role playing game where multiple people interact in the same world. The details of how they do it vary from game to game, but one thing remains the same, text. In my opinion, and I suspect in most text MUD players' opinions, part of what draws people to play MUD's is the same thing that makes people continue to read books rather than just watch movies.

With a text game, the author can write prose to set up an emotional response in the player. They can use enough detail to set the scene, but leave the player free to use their imagination to fill in the gaps. The result is an experience that, like reading a book, is more personal for the player because their own mind is helping to create the experience.

The more you move towards a graphical game, the more you are taking away from that experience. You are moving towards the movie experience, which is fine... but it's a different kind of game, and will attract a different audience.

However, one thing that CAN (and SHOULD) change is the reliance on TELNET. The last few versions of Windows haven't even included a telnet client, by default, and doing all the formatting work on the server end is not only extra work, but you can't even be sure how well it will work on the client's display.

I've said before, developing a new MUD that isn't trying to be legacy compatible with anything else, I would opt for a packet protocol using JSON or something similar, and just send messages back and froth over a TCP socket. To play the game, you download a custom client which talks that packet protocol and formats the display appropriately for the hardware it's running on.

The client could be a simple text client that looks very much like a normal MUD today, but is doing all the word wrapping, color translation, etc on the client end. Or, it could be some fancy graphical interface that shoves text into various panels with a pseudo-graphical map and clicky buttons. You could have a websocket client that runs in a browser too, but I personally dislike those unless they're done very well. I prefer to not have my game session end if the browser crashes.

Post is unread #3 Apr 19, 2015 1:28 am   
Go to the top of the page
Go to the bottom of the page

ayuri
Magician
GroupMembers
Posts239
JoinedJun 13, 2008

 
So the way I see it is, MUDS in some form will be around. Its like IRC, sure there are many other chat applications, however IRC still has a following. Muds are the same. There's a community around a well developed game.

I personally think there is nothing wrong with telnet for the game. Now mind you, I don't use it for server administration, but for a game its fine and works well and cross platform. Windows not having a telnet client isn't a problem. Many open source programs exist (putty for example) or even stand alone mud clients. Plus you can always install it from windows if your -really really must have it- *puke*. As to formatting, my rule of thumb is 80 column mono spaced font. Having worked on a lot of AIX systems, you cannot underestimate 80cm. A note in your MOTD, or newbie zone 'for best play experience please make sure your client is capable of at least 80 columns of text and that you are using a mono spaced font. Chances are, if the player is aware what a MUD is, they know how to change their font's :D I've done some really wicked stuff in game for 80cm using the color codes, reverse colors, blinking text and what not.

Now, the dangers to mud's...lack of time. I have, sadly, let mine die to the way side, and being honest been that way since 2009 or so. Personally, I've grown up...Ok so not really....but work, family, children, promotions, more work. Free time is no longer a 'personal' time. Its family time. Or its time fixing the lawn mower, or working in the garden, or any other number of tasks running a house hold. Face it, the people who ran muds are getting older.

The big question is, how might one attract new players? How do you get the word out to people who have no idea what a MUD is? Not like you walk up to someone on the street and say 'hey try this online game i found, its all text based!' (Ok well if you did that to me I'd be like COOL! but still....). Computer science kids in college may fire up a game to see what it does. But will they take interest in it? Will they play it, and enjoy it? Will they bring their friends in? How do you advertise? Mud Connector? Great and all, but you kinda have to know about muds to begin with to even stumble about mud connector.

So whats next? The masses want their Shiny graphics, their farm ville, their face book, and whole host of stupid things. With everything going mobile, and yes...it is going mobile. People who have no want of a computer are now face down all the time in their phones, games such as muds will be rare. As long as there are some sysops/gods/admins/whoever who has a few extra mental cycles and the want to host a game....there will always be a game out there.

Anyhow, that's my rant.
ayuri

Post is unread #4 Apr 19, 2015 4:56 pm   
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

 
Just a comment on the 80 column part of ayuri's post.

It's not that people have LESS than 80 columns these days, it's that most of us have far MORE. My eyesight is pretty poor, so I use a large font, and my putty session is still 172 columns by 53 rows. That's why I suggested doing the formatting on the client side (via data packets) rather than on the server side (pushed over TELNET as a stream).

When I log into a "normal" MUD which assumes 80 columns, it look quite ridiculous on my screen since it never uses more than the left side of the monitor, leaving all that screen real-estate blank, when it would be a perfect place to put ASCII mini-maps, status information, chat channels... whatever. But, because it's a single text stream over TELNET, there's no way to easily do that.

Sure, I could use a fancy client and do the work myself to try and regexp-match things and shoehorn them into place, but that's a LOT of effort to expect from your players. And the developer doesn't want to try and develop and debug multiple layouts based on screen size, and relying on ANSI/VT100 codes to try and position things.

The simplest way is to send all the data as packets, where the packet type is disctinct for each type of information. Then the client can decide what to do with it. Initially, the game developer will want to write one or more clients, but if it works well and is a popular game, additional clients might appear from the playerbase. I don't see a great deal of value in generic clients, because they'll never work for more than one or two MUD's out of the box, and the effort to customize them is non-trivial.

Post is unread #5 Apr 20, 2015 8:36 pm   
Go to the top of the page
Go to the bottom of the page

ayuri
Magician
GroupMembers
Posts239
JoinedJun 13, 2008

 
See, to me the right hand side is all reserved for the p0rn :D
I'm not versed with what client you use, but I used to use tintin++ and run a split screen (inside of gnuscreen that is) so the mud would fit perfectly, I could have a second window running with a mapper, and then even a 3rd vertical split inside of that that's grepping for ingame channels. While it took me a while to set up, I feel the customization was worth it.

In my opinion, keeping the protocol simple and letting the users pick what they want to configure, however they wish to configure it would be the way to go. The beauty of it is mud in window1, chat in window2, something else in window 3. If you have multi-monitor setup, a new gnuscreen session for sharing (or not!) to watch some other output from the game. Or using it to multi-play my god and mort account.

This isn't my screen shot, but I modeled a lot of my setup after others like it :)


(I only ran max of 4 windows)

My concern with using JSON or anything else is your breaking a lot of existing clients out there. I love tf and tt++ as I can run them from anywhere in the world as long as I can access my servers. Running them in screen means I can disconnect and re-attach from system to system with out having to log off. Uber handy for botting or being 'omnipresent' :D. Other people love zmud, or any other number of clients that exist.

As to easily taking the single text stream, what knowledge would be required to parse the JSON output? Would you be at the whim of the mud owner saying this is your mini-map, and no you may not add your hidden exit to it? (Not familiar with JSON, sorry!) With the text stream, I hook tintin back into its self with netcat. If I didn't want to use netcat, I could have it write all output to a.out, have it readin a.out and parse it that way, or simply tail -f | grep . Other mud clients I've played with support lua scripting, tt++ scripting, and some even have some damn nice built in examples or easy to build rules for those who do not know how.

I know of a few MUDS (if they can be called that) that require you to use their client. At that point, you are in charge of not only the game, but also techsupport of your players. It's bad enough having players who abuse the game, but having to walk them though a client issue....(there's a reason why I never worked helpdesk and stayed on the server side of things).

To me, in my mind nothing beats good old telnet. I know Scandum has his own little things that he plops into muds (MSSP anyone?) but hands down I love tt++ and the way you can configure it. There's something magical that can be done with raw text and awk/sed/grep.

(Not trying to beat you down Quixadhal, just my incoherent ramblings.)

ayuri

Post is unread #6 Apr 21, 2015 10:48 pm   
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

 
JSON is pretty easily parsed, and there are existing libraries for almost every programming language used by more than 10 people. As to how it would look, details of the encoding aside, the concept is pretty simple.

In your screenshot, you can see several different kinds of data, which your MUD server formatted for you (making a bunch of assumptions about your screen size, ANSI capabilities, etc), and which you then either have to just splat to a window, or pick back apart by clumsy regexp matching to try and figure out what parts are what content, and place them in the appropriate section of your display.

You say your client does this... but you have to configure it, and it has to adapt to changes (either by the client being updated, or by the user having to change those fragile regexp matching codes).

So, what kind of content is on your screen?

I see a room title, a room description, a mini-map, an NPC, several objects, a list of exits, some data about the room itself, a prompt which displays several bits of character data, some informational output about your character, and various chat messages from various sources.

Rather than making the MUD format all that for a text stream, and then making your client rip it back apart to split it into different parts of the display, wouldn't it be much smarter to have the data sent as packets, where each packet clearly says what it is, and the client is then free to either format it in a generic way and splat it out, or go "Hey, I know what that is. I'll put that over here!" ?

{ 'room' : {
    'title' : 'Starlit Foyer',
    'desc' : 'A thin mist... blahblah...further down.',
    'exits' : [
        'north' : vnum-or-path-or-name,
        'east' : 'unknown',
        'west' : vnum-or-path-or-name
        ],
    'contents' : [
        { 'npc' : {
            'name' : 'straw man',
            'short' : 'A straw man sits here, propped up.',
            ... other npc data the player could detect by looking at it...
            }
        },
        { 'item' : {
            'name' : 'silver potion',
             .... stuff ...
            },
        ... rest of the room's contents ...
    },
}


Looks ugly? Well, it's not meant for human consumption. However, you can see that there is no ambiguity. The JSON packet data is created automatically via the json module from the actual room data (serialized), with some parts possibly filtered out to avoid sending spoilers to the players. Yes, the MUD coder has to write the code to turn a room object into JSON, but in reasonable languages, that's mostly deciding what NOT to serialize (spoilers, or data which only means something locally). Once you write the code to serialize a room, it works on ALL rooms. Once you write the NPC serialization code, all NPC's are serializable, including the ones inside rooms.

From the MUD's standpoint, a big wad of formatting code to try and make the room display look pretty on various terminal types and various widths suddenly becomes json_encode(room_data, 0), where the 0 means do NOT do a full encode like you would to save/backup the room, but do the filtered version for output.

From the client's point of view, it knows the formatting rules for each type of data, and thus knows how to color/highlight/place each item where it goes. If an item type is NOT recognized, it can have default rules to format it and splat it out to the default display window/panel/etc, pretty much like the MUD would have done.

Of course, I've only done the ROOM data there, and not a complete job either... but enough to give you the idea. When the client sees a 'chat' packet arrive, it can know to look for the 'channel_name' and put the 'message' data into the appropriate display area for those messages. It doesn't have to try and parse 'Foo Bar@Silly Git Mud tells you "I hate you."', which might change if the MUD dev decides it looks better with a comma, or some variety in the "tells you" part...

As for compatibility with existing clients... who cares? It's not 1990 anymore, move on. New cilents will be developed, and if people would adopt this idea, the MUD devs themselves would likely write one or more cilents custom-tailored to their MUD.

I really don't understand this bizzare concept that MUD's are held hostage to compatibility with clients they didn't write, and aging protocols that are falling out of use. Do you expect to be able to play World of Warcraft using your Diablo 2 client? Do you fire up your Grand Theft Auto client to play some other racing game? No. You want to play X, you download the software for X. Click, install, done.

I can only assume it boils down to laziness on the part of MUD admins of the past. Because they got a free ride on not having to write the client/display code, they never bothered... and thus the players put the effort into making clients that do what the game SHOULD be doing itself, and thus don't want to let go of something they put effort into making. That worked in 1990. It's a stupid practice in 2015. If you really want to run a game, write a good client to make your game look as good as you WANT it to look, don't pawn half your job off on the players.

Post is unread #7 Jul 16, 2015 3:20 pm   
Go to the top of the page
Go to the bottom of the page

AmonGwareth
Fledgling
GroupMembers
Posts2
JoinedOct 5, 2013

 
To take it one step further, if you are writing your own client don't even transmit the text with each packet. Create a static lookup of all text-based data and transmit it during login, then reference it later using unique IDs. Saves on packets.

Fwiw, nearly every 3D MMO uses UDP instead of TCP for packet transmission.

Post is unread #8 Jul 20, 2015 2:06 am   
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

 
That's because most every 3D graphical MMO can afford to lose packets.

UDP is faster only if you are happy with data arriving out of order, or not at all. Hence the "Unreliable" part of the name. In a graphical game, you aren't moving from room to room, you are saying things like "i moved north a bit", and the server is telling your client "Bozo is this vector/distance from you". Missing a packet here and there isn't a big deal, it results in less smooth movement in the case of missed updates about others, or perceived lag if your own packet didn't make it through.

If you care about that stuff, you have to either do it yourself and end up recreating TCP in a new and not tested way, or you end up doing what most MMO's actually do... use a mix of both TCP and UDP packets, based on the content being exchanged.

You could certainly keep all the text client-side, if you like. However, you will then have to have the client "patch" itself, either on connect or via some background task. One of the only real reasons MUD's tend to persist in this day and age is the rapid pace that content can be created or adjusted by an active team of only a few people.

*shrug*

I'm not sure anyone really cares about saving packets these days. Given the bandwidth most players have, I can run around like a rabbit on crack in an MMO, spam the chat window, and still be using a tiny fraction of even a low resolution youtube video. It might matter on the server end, but that's assuming you have 100+ players. I'd worry about that problem if it materializes. :)

Post is unread #9 Oct 5, 2015 11:12 pm   
Go to the top of the page
Go to the bottom of the page

Xorith
The Null Value
GroupAFKMud Team
Posts254
JoinedFeb 23, 2003

 
Activating special encoded data via a command is possible. If you're still stuck on a telnet client, you're in luck. If you happen to want more, you could easily do all of the options.

I've seen a MUD use an open-ended XML document. JSON seems possible.

Still don't think I can come back to MUDs though. My name is fairly well forgotten at this point, and www.wurmonline.com keeps me busy :P

Pages:<< prev 1 next >>