11 May, 2014, hitsuzen wrote in the 1st comment:
Votes: 0
I apologize, I just wanted to gush out an idea I had. I have no plans to ever implement it, but I wanted to just put it out there to get it out of my mind.

Basically, MUDs have declined significantly in popularity since the '00s. MMOs in general, people play in droves – but MMOs are watered down muds. They have less functionality, fewer actions, and in most cases, MMOs don't even have player housing, terraforming, or any of that neat roleplay that makes muds so interesting. The only thing they DO have is graphics.

So I was thinking, sure, some muds have tried to do graphics - they have some kind of html page for the mud and will render sprites or clip art when certain things happen. This tends to just detract from the experience for me.

But basically, there are lots of mud engines around now – but they all do the same thing – a mud is basically just a client-server network model. A user inputs strings and gets strings back. In a way, it's just a super complex web protocol with numerous verbs and possibilities operating on a usually large system of memory-entities.

Wouldn't it be neat if we took a really robust mudlib and wrote a graphics engine for it? It could totally work - the client opens a connection to the mud server and sends strings based on client input. Forward on the keyboard sends the north string. Your surroundings are rendered by a periodic look n / look e / look w / look s call, displaying nearby actors and rooms. Each room is rendered based on the string feedback from the server, if the room contains the word "dungeon" a dungeon tileset is loaded, if it says "chair", a chair is loaded, et cetera.

Of course, input would still be restricted. You can't necessarily move your character more than TO a room or maybe TO an object (sit chair would have your character approach a chair and sit in it), so it would play exactly like a mud, but it would have a spiffy 2d or 3d graphical interfact with models and sprites and such.

It would basically be possible to take a mudlib and turn it into a full-fledged MMO. You'd skip the whole nightmarish process of building an MMO engine – that work is already done for you, all you need to do is build the client-facing renderer.

I think it's a neat idea – and a massive undertaking. What mudlib would you pick? How would you build up models/assets for in-game rendering? Could mudlib handle constant calls? Would people enjoy a renderer like this, would it make that mud extremely popular and more intuitive for newcomers?

But it would be very easy to start up a project like this. You take the mud engine you understand the best and just do a lot of syntax parsing. Everything comes and goes in strings, which are easy to understand. The mudlib is basically a big black box that you only need to program rendering for what results you design to display.

Any thoughts?
11 May, 2014, plamzi wrote in the 2nd comment:
Votes: 0
hitsuzen said:
but MMOs are watered down muds. They have less functionality, fewer actions, and in most cases, MMOs don't even have player housing, terraforming…


There are some very practical reasons why MMO's had to shed a lot of complexity just to gain graphics. If you take, say, a MUD server and a Roguelike GUI and try to marry the two, I think you'll find out very quickly what those reasons were, if you don't already suspect them. And if you don't have infinite time, resources, and artists, at the end of the road of compromises you may end up with just another Roguelike.

I'm not naysaying the general idea. In fact, I'm a firm believer that it is possible to retain a lot more complexity and add enough graphics to make a MUD competitive and relevant, especially in markets (mobile, social web) where screaming 3D graphics are not a requirement, and static 2D GUIs are in many ways more playable than 2D scrollers. And, to this effect, I've put my code where my mouth is.

But having walked the path, I can assure you that it's thorny and full of trapdoors. Also, you should not expect enthusiasm from most MUD admins, or crowds waiting to play your game at the end of the rainbow. Most MUD admins are likely to get into squabbles with you over whether what you're building is a "real" MUD. And there are no crowds out there, especially in the casual realms, dying to play a graphical MMO that is at least 10x-20x more complex than what they are used to, and most likely at least 10x harder.
11 May, 2014, Tyche wrote in the 3rd comment:
Votes: 0
Some mud admins posted similar ideas on usenet back in the 90's.
Nothing ever came of it, except for Ultima Online, EverQuest, etc.
11 May, 2014, hitsuzen wrote in the 4th comment:
Votes: 0
Can I ask what the obvious pitfalls/traps are exactly? I wouldn't dream of making a "proper" MMO with this idea, just something of very graphical MUD (the difference between the two largely being combat design and movement)… I'm talking for a theoretical standpoint anyway, something like, "Well, lots of people want to build their own MMO, and this seems to me like the most straightforward and obvious way, since the hard work of writing the backend code is done for you."
12 May, 2014, plamzi wrote in the 5th comment:
Votes: 0
hitsuzen said:
Can I ask what the obvious pitfalls/traps are exactly?


I wrote a pretty long post and lost it by pressing the wrong button. Now it seems like a bit of a waste of time to rewrite. Especially since by your own admission you're not considering actually doing anything yourself. And if you are, in fact, considering building something, you'll face most of the big issues right off the bat. My listing them for you is not going to matter.
12 May, 2014, Scandum wrote in the 6th comment:
Votes: 0
An MMO like WoW isn't that much different from your average MUD.

Going graphical is pointless as you'll be competing with commercial games that are way ahead of MUDs in that department.

It's possible to take MUDs to the next level, but there's not much talent left in the MUD community, and graphical games are likely to move on to interactive world design before long. It does appear they're facing the same hurdle as MUDs in that department.
12 May, 2014, Nathan wrote in the 7th comment:
Votes: 0
Go look at Meridian 59 (https://en.wikipedia.org/wiki/Meridian_5..., https://github.com/Meridian59/Meridian59), maybe try playing it. That ought to cure you of anything less than full blown crazy on trying to turn a mud into an MMO. Granted that meridian 59 was not written as a mud first persay, but making a multiplayer graphical game of the full client <-> server variety is clearly quite hard and a hell of a lot of work. You might not even get something you like out of it.

Maybe with web tech and a lot of hard work you could make a playable game with visuals resembling BrowerQuest (http://browserquest.mozilla.org/). I don't know, but I suspect that your idea of translating from normal inputs to text commands and from text output to a 3d display would be more complicated and messy than you think and quickly prove difficult to port between muds. If a mud's engine were truly powerful enough to run a passable MMO, someone would've done it (and probably did long ago). In any case, you need a game worth playing before you bother with any of this.
12 May, 2014, quixadhal wrote in the 8th comment:
Votes: 0
Neat.

I didn't know Meridian-59 was available. I wonder how it escaped the claws of the dead company that surely still thinks it owns it…

In any case, if you want to make a graphical game, make one. There are plenty of modern graphical game toolkits out there, such as Unity3d, that will make your life much easier than trying to shoehorn graphics into a game designed around text. The simple fact is, people who build text games often do so because they lack the artistic skill (or desire) to generate all the 3d models and assets needed for even a simple graphical MMO. People who play them *probably* don't play them while thinking "Boy, I wish this game had graphics!" If they did, they'd go play one of the many graphical games out there.

So, while I don't see a reason you couldn't do it… I also don't see a reason to bother. I think you'd get more mileage out of using a moden 3d engine and adding rich text support to it, rather than going the other way around.
12 May, 2014, hitsuzen wrote in the 9th comment:
Votes: 0
plamzi said:
hitsuzen said:
Can I ask what the obvious pitfalls/traps are exactly?


I wrote a pretty long post and lost it by pressing the wrong button. Now it seems like a bit of a waste of time to rewrite. Especially since by your own admission you're not considering actually doing anything yourself. And if you are, in fact, considering building something, you'll face most of the big issues right off the bat. My listing them for you is not going to matter.


Okay. I mean, bullet points would be enough.

Yes, I don't plan to do this, but it's just a technical idea I had and I was curious what others thought of it.

The point is, yeah, you could use Unity, and learn the ins and outs of its server-client model. You could build your own anything from scratch – but that's not really the point. Programmers are usually inclined to be lazy - that was just the crux of my idea, we have plenty of server-client models that exist - mudlibs. The protocol is well-defined. And yeah, you'd have to take your mudlib and make a game actually worth playing too, but my curiosity was doing something the lazy way and wondering how well it would work out. I'm curious about what technical hurdles exist - ones that are apparently so obvious I should already be seeing them - because these kinds of things fascinate me as someone who programs, in general. What am I missing that's so obvious here? If you don't want to say, that's fine, but I'm just inviting hypothetical discussion, since I'm not so sure anyone has thought of this before - it's not like MUDs are something that many people know about, hell, telnet in general is an archaic decrepit thing probably to anyone with any knowledge of networking or protocol.

I mean, I've done UDP basic server-client stuff in c. Listen, connect, bind, fork, yada yada – you'll build ten thousand lines of boiler plate code just to get the basic facets of your server/client send-receive down. And there's already existing server-client stuff in the form of SmartFox or something more general like Apache… I, or more hypothetically someone, since I'm too lazy to be inclined to bother… could easily I'm sure learn one of these products and turn around and make a server model, but how long would that take? Would I have the endurance to make all that work, then go about building my own game engine, and then create everything else involved, then integrate all these working parts together…? All the while fixing bug after bug… Every component you have to build yourself is a lot of hours in just frustration and debugging. The point of using existing stuff you know works… is you avoid all that time and effort.

The idea I have here could be an awful one, but I have the hunch that it would actually be the simplest way to build an MMO. What other framework can you use out of the box to build an MMO of your chosing? Unity has networking, of course, but you still have to build a lot of it from scratch from what basics I've learned of it. There's the Hero Engine, but I'm of the impression that the Engine is garbage - not that writing a 3d-client for a MUD would necessarily create a great game, true. But I at least know MUDs tend to support more potentially interesting mechanics and because MUDs are pretty well-known it would be easy to find builders for your game, as well as administrators – and you could start building and planning your game right from the get-go. This kind of approach wouldn't necessarily be any good for a commercial company, but I never meant to imply that. As a project, it's just a fancy I thought might have some merit, since it could be the missing piece in making MUDs popular again - what if someone wrote a generic engine that parsed mud output to implementation-defined graphics?

Unless, I'm missing something rather crucial here, which I might be.
12 May, 2014, plamzi wrote in the 10th comment:
Votes: 0
hitsuzen said:
Unless, I'm missing something rather crucial here, which I might be.


Depending on what kind of end result you have in mind, you'd be missing a few different things. But some of the big-ticket items are going to apply regardless.

For instance, any fully graphical game requires a lot of graphical assets. On the other hand, a lot of the mechanics you may find rich and worth keeping in a MUD server tend to impose huge requirements on the art or the UI. How do you reconcile the two without simplifying the mechanics to a point where you have a workable solution that is better than existing graphical games? A graphical multiplayer game, especially the first of its kind, is a huge undertaking even for commercial companies with the resources to hire complete graphics teams. If you think the start is easy, how do you propose we start? I think you are throwing out things like "animation of a sprite sitting on a chair" without realizing the full implications.

Based on experience (you can browse the links in my sig) I would say that a traditional MUD server lends itself to a certain kind of MMO, but it was still a whole lot of work to be able to keep the existing rich content and interactivity while providing a GUI that is not going to turn off modern gamers. And now that we have a full GUI, it's a huge challenge just to keep pace with the evolving gameplay logic.
13 May, 2014, Nathan wrote in the 11th comment:
Votes: 0
@Quixdhal
http://www.meridian59.com/index.php

It got back into their hands somehow. What I heard was it changed hands a couple times before making it back to them. I'd say there sort of lucky on that account to at least have control over it despite it having failed to really become a hit. Of course I didn't know it existed until a couple years ago I bumped into their site while searching google.

@hitsuzen I think it's arguable that telnet has some merit in that it defines a model for behavior over a raw socket connection that doesn't depend on either side knowing everything about the other end. While the real options etc aren't of much use for anything other than an actual terminal application, it probably will always have some utility for prototyping things and learning about how sockets work and also for stuff like local connections to a shell running on a router.

@plamzi There might some merit in a 2D graphical client, given that a fast-ish graphical animation of battle would be far easier in 2D than 3D. That sort of thing would, I imagine, be hellish to make work in 3D. It's not great graphics, but if you consider the animation in battle for wesnoth or games like terraria, hammerwatch (haven't played this last one) you can see that there is definitely ability to show more than one move/weapon in that sort of perspective. It would be a sizable chunk of work to produce adequate art to be sure.
09 Dec, 2014, Ashlan wrote in the 12th comment:
Votes: 0
The ideal thing in my mind would be to make a MUD that interacts seamlessly with a graphical game, but never try to do both at the same time.

There are tons of games out there, like say Eve Online, where the graphics are such meaningless symbols that they could have been played as a MUD. For example, in Eve, you do almost everything through a text menu on the right side of the screen. Playing Eve as a MUD might have been a relief compared to clicking people's names in a severely spammed out, un-customizable text box on the right side where the names are constantly shifting up and down with each other.

The challenge in my mind is reconciling the really expansive control options in MUDs with the "hotkeys, spacebar, point and click" interface of a graphical game.
09 Dec, 2014, plamzi wrote in the 13th comment:
Votes: 0
Ashlan said:
The ideal thing in my mind would be to make a MUD that interacts seamlessly with a graphical game, but never try to do both at the same time.


I'm trying to imagine this but failing miserably. Do you mean something like a text input interface to an existing graphical game? I've heard that all major online graphical RPGs eventually get those, whether they want it or not, because it makes botting possible.

Ashlan said:
There are tons of games out there, like say Eve Online, where the graphics are such meaningless symbols that they could have been played as a MUD. For example, in Eve, you do almost everything through a text menu on the right side of the screen. Playing Eve as a MUD might have been a relief compared to clicking people's names in a severely spammed out, un-customizable text box on the right side where the names are constantly shifting up and down with each other.


I haven't played Even Online, but your own comments suggest that the problem is in fact with how they presented the clickable elements. Shifting text is a problem in and of itself, and it's a problem for MUDs much more so than graphical games. Putting clickable elements inside shifting text without strategies to improve its usability is a GUI design issue, not an issue with the concept of clickable elements itself. The web seems to do pretty well with clickable elements that stay in one place, no?

Ashlan said:
The challenge in my mind is reconciling the really expansive control options in MUDs with the "hotkeys, spacebar, point and click" interface of a graphical game.


It *is* challenging. But the best way to tackle the challenge is to start from a neutral place and evaluate the strengths and weaknesses, and the interplay, of different interface elements. You can't just say that every complex game would be better off if all it offered was a command prompt–that's too simplistic and easily debunked. For example, point and click is infinitely superior when it comes to movement than typing "s;s;s;sw;w;w;w;w;w;s;open door;s". And in action-oriented MUDs, movement commands are probably 90+% of everything players type.

Point and click is also superior when it comes to targeting. This came up in a recent discussion on how some MUDs have had issues with special characters inside NPC or PC names that some other players couldn't type, so they couldn't interact / attack / defend against those entities. But if the UI provides a clickable way to interact with any target, the issue becomes moot. (I know that some MUDs intentionally make you type the full name of your target or a verbose sentence to "take the second blue-green potion out of the woolen sack" but those games probably regard any form of non-typing interaction as idolatry).

There's a host of other benefits to be reaped from clickable elements. A big win is just the fact that you are not putting a new user in front of a blank command prompt with no clue how to proceed (only MUD vets and command prompt lovers will know to type 'help'). Even for experienced players of your game, not having to type "kill 12.guard" or being able to quickly access only the valid commands to interact with an item, are clear improvements in usability.
10 Dec, 2014, Ashlan wrote in the 14th comment:
Votes: 0
plamzi said:
Ashlan said:
The ideal thing in my mind would be to make a MUD that interacts seamlessly with a graphical game, but never try to do both at the same time.


I'm trying to imagine this but failing miserably. Do you mean something like a text input interface to an existing graphical game? I've heard that all major online graphical RPGs eventually get those, whether they want it or not, because it makes botting possible.

Ashlan said:
There are tons of games out there, like say Eve Online, where the graphics are such meaningless symbols that they could have been played as a MUD. For example, in Eve, you do almost everything through a text menu on the right side of the screen. Playing Eve as a MUD might have been a relief compared to clicking people's names in a severely spammed out, un-customizable text box on the right side where the names are constantly shifting up and down with each other.


I haven't played Even Online, but your own comments suggest that the problem is in fact with how they presented the clickable elements. Shifting text is a problem in and of itself, and it's a problem for MUDs much more so than graphical games. Putting clickable elements inside shifting text without strategies to improve its usability is a GUI design issue, not an issue with the concept of clickable elements itself. The web seems to do pretty well with clickable elements that stay in one place, no?

Ashlan said:
The challenge in my mind is reconciling the really expansive control options in MUDs with the "hotkeys, spacebar, point and click" interface of a graphical game.


It *is* challenging. But the best way to tackle the challenge is to start from a neutral place and evaluate the strengths and weaknesses, and the interplay, of different interface elements. You can't just say that every complex game would be better off if all it offered was a command prompt–that's too simplistic and easily debunked. For example, point and click is infinitely superior when it comes to movement than typing "s;s;s;sw;w;w;w;w;w;s;open door;s". And in action-oriented MUDs, movement commands are probably 90+% of everything players type.

Point and click is also superior when it comes to targeting. This came up in a recent discussion on how some MUDs have had issues with special characters inside NPC or PC names that some other players couldn't type, so they couldn't interact / attack / defend against those entities. But if the UI provides a clickable way to interact with any target, the issue becomes moot. (I know that some MUDs intentionally make you type the full name of your target or a verbose sentence to "take the second blue-green potion out of the woolen sack" but those games probably regard any form of non-typing interaction as idolatry).

There's a host of other benefits to be reaped from clickable elements. A big win is just the fact that you are not putting a new user in front of a blank command prompt with no clue how to proceed (only MUD vets and command prompt lovers will know to type 'help'). Even for experienced players of your game, not having to type "kill 12.guard" or being able to quickly access only the valid commands to interact with an item, are clear improvements in usability.

Good points there. I think you would need to play Eve Online before you could really know what I'm talking about. It helps that it's a spaceship game and not a humans-controlling game. There is a 3d world but the way you interact with it through clicks is almost totally irrelevant compared to what you do with the text-based overlays. This is partly because ships and structures can be really, really far away from each other since it's outer space.

I don't think a MUD-based control scheme would work in most MMO-type games but if you were willing to make some sacrifices to how people move around, meshing a graphical game with a rooms-based environment, it might work out.
10 Dec, 2014, quixadhal wrote in the 15th comment:
Votes: 0
I have played EVE, and the problem isn't the control scheme itself. It's more an issue of information density.

When playing EVE, you get a huge amount of visual data telling you what's happening, where things are, what's shooting at you, what kind of ammo is being used, how much damage you're taking, and how fast. ALL of that helps you decide what to do, should you use shield boosters, let them slide and switch to armor reps, switch ammo types or crystals? Should you leave your weapons on focused fire or peel the launchers off to a secondary target?

Trying to replicate that in a text environment would be a nightmare. A turn-based game could work, but not a real-time one. The only way you'd keep up would be to make the client parse everything out and replicate the graphical UI… and then… why bother with text?
10 Dec, 2014, Ashlan wrote in the 16th comment:
Votes: 0
quixadhal said:
I have played EVE, and the problem isn't the control scheme itself. It's more an issue of information density.

When playing EVE, you get a huge amount of visual data telling you what's happening, where things are, what's shooting at you, what kind of ammo is being used, how much damage you're taking, and how fast. ALL of that helps you decide what to do, should you use shield boosters, let them slide and switch to armor reps, switch ammo types or crystals? Should you leave your weapons on focused fire or peel the launchers off to a secondary target?

Trying to replicate that in a text environment would be a nightmare. A turn-based game could work, but not a real-time one. The only way you'd keep up would be to make the client parse everything out and replicate the graphical UI… and then… why bother with text?
Possibly it depends on what kind of MUd you're used to, I played Iron Realms MUDs for years and they would regularly send a lot more information than a typical Eve fight sends, all through text. A common way of dealing with it in the early days was with color coding, something that Eve does with its text I think in displaying damage types. Then your prompt with your health changes as things progress. You basically learn to speed read with color aides.
10 Dec, 2014, quixadhal wrote in the 17th comment:
Votes: 0
Yeah, I've played those kinds of MUD's…. you don't read… you plough through and ignore 90% of the spam, only really noticing the amount of various colors that happen. When you get to that level of nonsense, you aren't really "playing" the game, you're emulating a pattern matching bot. :)
11 Dec, 2014, Ashlan wrote in the 18th comment:
Votes: 0
quixadhal said:
Yeah, I've played those kinds of MUD's…. you don't read… you plough through and ignore 90% of the spam, only really noticing the amount of various colors that happen. When you get to that level of nonsense, you aren't really "playing" the game, you're emulating a pattern matching bot. :)
Yeah that was the eventual downfall of those MUDs for me. :lol: I reached a point where every now and then, I would consider playing them again, then I would check the forums and people were posting about "systems" and I would be like "oh yeah, systems" and go do something else.

My goal is to launch a MUD with some complex PvP that doesn't need a system and could be translated into graphics if all goes well. The biggest challenge I think is managing movement across two very different styles of gameplay.
11 Dec, 2014, plamzi wrote in the 19th comment:
Votes: 0
Ashlan said:
My goal is to launch a MUD with some complex PvP that doesn't need a system and could be translated into graphics if all goes well. The biggest challenge I think is managing movement across two very different styles of gameplay.


I know you said you're using Evennia, but you should check out these links at least to get some ideas:

http://www.aaralon.com/text
http://www.aaralon.com/
11 Dec, 2014, Ashlan wrote in the 20th comment:
Votes: 0
plamzi said:
Ashlan said:
My goal is to launch a MUD with some complex PvP that doesn't need a system and could be translated into graphics if all goes well. The biggest challenge I think is managing movement across two very different styles of gameplay.


I know you said you're using Evennia, but you should check out these links at least to get some ideas:

http://www.aaralon.com/text
http://www.aaralon.com/
Well, I would like to learn JavaScript so I will definitely check yours out :) I am a pretty novice programmer and getting evennia to work without root privileges to help with installing the dependencies is pretty difficult for me. A VPS can be expensive too. So it can't hurt to look around!
0.0/24