So how much graphics are you talking about then? I've seen two or three telnet mud clients utilise 3D graphics, but from your talk of "3d engines for shading and particles" and "using text when it's the best solution only. Like describing things in detail" I got the impression you were referring to a typical MMORPG-style interface, with a handful of textual elements, such as mouseover pop-up windows for providing details on an objects and creatures.

What textual elements would you provide that a typical graphical mud would not?


And I'm clearly not one of them, but I still disagree with the idea of forcing graphical enhancements on players when they can't use them or don't want them. In fact I wouldn't consider it any different from muds that force unicorn-vomit colour schemes on their players.


If you want a create a mud that caters exclusively to non-mudders, then go for it. Personally I think it's a really bad idea, but I'd still be interested to see the outcome.

Well, yes. The graphics and text are just the media with which a game is created, not goals in and of themselves.


I know, right? I hate how Starcraft 2 forces me to use this funky 3d display.


When you put it that way, of course it sounds stupid. But, well, that's not what the idea is.

Someone is having withdrawals.

Starcraft 2 isn't a mud. There isn't even a separation between client and server. A more accurate assessment of your attitute can be made by looking at you react when an actual mud requires you to download a client:


So you "would have liked to check out" his mud, but you didn't because you couldn't be bothered to "download something [you] don't have". How should I, as a game admin, respond to that sort of attitute? Let's see…




I was going to write more, but then I realised I don't really care about you as a target player anyway. I have bigger fish to fry.

Ah, KaVir. That's very clever of you, isn't it? :wink: The crucial point you are forgetting, unfortunately, is that I don't believe I'm a target player for the Chrome-based game. I'm not, I know I'm not, and I'm not trying to say that I am. So yes: I completely agree that he shouldn't spend any time on accommodating my needs, and never pretended otherwise. He would be much better off working on his target audience, not wasting time chasing down every last player. This is why I think your "attitute" is a little silly, and for the same reason, it's a little odd for Tonitrus to expect people to cater to such individual tastes.

Heh, despite all the graphical side-discussion, I wasn't trying to suggest anything about graphics. Indeed, I wasn't even suggesting a non-CLI based client app. You guys have played nethack, or another roguelike game, no?

Using a message-based protocol instead of a stream-based protocol, you are free to make the client look or act however you like. If you want to to look and act EXACTLY like tinyfugue or tintin++, you can do so. The only difference is that all the data you get from the MUD is already categorized and formatted into some kind of logical packet structure. There's nothing stopping you from dumping it all in one window and (to the USER) making it look just like a plain old TELNET connection to a regular MUD.

However, should you *want* to do something different, like having the client use hot-keys or mouseover, or having graphics for things that seem like they'd work well with graphics, it's a LOT easier to do with message passing. If you *want* to support asynchronous events that require multiple different back-and-forth negotiations and not have to worry about disruption of the display, again, message based packets are much easier to work with than OOB TELNET negoatiations which may or may not work properly with Joe's MUD Client.

I'm not quite sure what you mean here. Almost invariably when I decouple I get cleaner and easier to understand code. That's not always true for abstractions; I gotta have a solid reason to abstract. I guess you could say I'm pretty vigorous about refactoring functions to be cohesive and loosely coupled, and downright lazy about refactoring objects. Maybe you are unnecesarily abstracting certain things or doing it way too early? I have no way of knowing unless you can get your finger on a example.



Most of the above deals with formatting of output. My solution was to create a mud markup language which is sent on to a stack that formats it according whatever the client can handle. That's an abstraction that seems to work.



Believe me, you can spend years building a foundation without ever getting to a game. ;-)



The network code as a module worked and I've incorporated it into two mud codebases already. The concept of building a mud game as a collection of adhoc plugin modules, I completely abandoned.

The problem with targeting non-mudders is their wants or interests are different. I for one work for a professional game developer who makes games for the online PC market. I can tell you off the bat that it's an entirely different market and genre to become successful. Like for example, heavy text based systems are becoming more and more unpopular in today's online 2D/3D games just because of the instant gratification the new generation has become. People don't want to read 2 to 3 paragraphs of quest text anymore. They want 2 or 3 lines and a wiki or mod that points them to the quest location.

So you're really talking about apples and oranges here and not traditional MUDs. Yes, you could heavily influence certain MUDs, but it's not the same market or genre at all. You would need to appeal to a different range of players in order to be successful and you can't just rush into that because you're a MUD developer.

If you really want to bring the millions of users to your MUD from the online gaming world that is maybe the MMO market. Then you're better off influencing their style of systems into your genre from their genre. That does not mean going completely 2D or 3D.

P.S

Top down is a camera preference. Most rendering engines have movable camera capabilities for their engine either in first person, third person (top down or follow) etc.

First of all:
"P.S

Top down is a camera preference. Most rendering engines have movable camera capabilities for their engine either in first person, third person (top down or follow) etc."

I'm not an idiot. Kthx

Second of all, I'm tired of people telling me what is and isn't a legitimate mud. Kthxbai.

This whole "but that's not a MUD" thing strikes me as a bit silly. Adding graphics doesn't make something not-a-MUD-but-an-MMO. This would be silly because MMOs are just MUDs built on graphics. The distinction is merely an artificial one created by marketing execs. "MMOs" didn't exist until the term was coined; calling this shiny new game by a different name just makes it seem like an innovation to open the market to new players. Suggesting that StarCraft 2 cannot be compared to a MUD is also silly because they are both games. In either case, the user interface (I can damn near guarantee) will make or break your game. A poorly designed UI (whether or not it's preceded by a G) will turn off a lot (though probably not all) of players–perhaps even the majority.

Of course, it all boils down to preference. If you can design a game that makes people think it's easy to play and (gasp!) fun, you'll find players, graphics or no.

Usually when people talk about targeting non-mudders, they're referring to a target audience that they believe would like muds if they were to gave them the chance. Such a targeting strategy usually involves lowering the entry barrier (for example, by making the interface more like other games the mudder-to-be may have played in the past).

However you make a good point. If the goal is to target those who don't like traditional muds at all (which would fit with the idea of not appealing to established mudders) then you still need to decide which audience you are targeting. You can't simply say "I'm going to target everyone who doesn't like muds" - you need to target an audience based on something they do like.

By remaining compatible with older mud clients I appeal to existing mudders, a market with which I have some experience, and with a little work I've also made the game more accessable to blind players (a small market, but one that won't be drawn away by fancy graphics). With a graphical client I could move a little into the MMORPG market (a huge market, but one I lack the resources to enter seriously). With a custom web-based client I could also edge into the browser game market, and perhaps compete with Facebook games (also a very large market, and one I'd have a better chance in). But all of these clients would still play the same game.

This is the approach I would favour. Rather than burning my bridges and moving fully into a market I don't know, I would rather expand into multiple markets.




More accurately, MMORPGs are just muds with custom graphical clients - in theory (ignoring legalities for a moment) you could create a text client to play WoW, or play a DikuMUD with EverQuest's client.

However the comment that sparked the current debate was about "making text games for a wider audience". In that context, it obviously makes sense to distinguish between text-based and graphical games - unless the original comment was simply a quip concerning the popularity of text games (i.e., the implication that the "wider audience" doesn't like text games at all, and therefore the "text game" in question should contain as little text as physically possible), but I don't think that was the meaning of the comment.


The current discussion is about supporting existing mud clients, as opposed to dropping such support and exclusively supporting a custom client. Within that context, it makes no sense to draw comparisons with games like Starcraft 2, because they don't have the server/client distinction.

Not to be facetious, but does this statement have any practical value? I mean, in theory you could make a text client to play basically any multiplayer game, but it would be ludicrous to think it would be remotely useful.


SC2's multiplayer mode could certainly be implemented using servers and clients. It happens not to be – it uses a peering model, IIRC – but that is irrelevant to the fact that a client is being used to play a game with other people. In theory (ignoring legalities for a moment) you could create a text client to play SC2, that speaks the same peering protocol.

Massively Multiplayer Online Games are built to support thousands if not hopefully (future) hundreds of thousands of players simultaneously. Technically speaking, the same can be applied to MUDs. However, the difference lies engine.



That's crazy. Starcraft is an RTS and therefore should be compared to other RTS and E-Sport game.



That's not true. Otherwise we would all play the first game that offered that and nothing else. We would never need new games after that because we only need that one game that's easy to play and fun! :rolleyes:

The big question to ask is how much time Kavir devoted to his tactical interface, and if most developers are willing to spend that kind of time. VT100 has been available to create tactical interfaces for decades and few MUDs have utilized it. The same goes for 256 colors and xterm mouse support.

The truth is that the average MUD developer is either incompetent, lazy, stuck in their ways, or a combination of both.

I personally like tactical interfaces and any form of generated content. Not so much a fan of static content, like showing pictures of items, mobs, rooms, etc.

I also think many people would talk a different talk if they were using a different mud client.

That is true. There's some neat stuff that can be done. Indeed, the first mud I played in the 90's had some working optional interfaces that used VT100.

However, I should also mention.. They abandoned support for the feature because of support even back then.

Well I started working on it around 3.5 months ago - however in that time I taught myself how telnet negotiation works, implemented a few protocols as practice, and then you and I spent quite a bit of time discussing and fleshing out your MSDP specification. Provide an MSDP snippet and other developers could skip that part entirely, saving about a month.

After that first month it took me about 2 weeks of playing around with one of Nick Gammon's plugins and reading over documentation before I could get it to display the energy bars using MSDP data. It then took me a further week before I was able to create my own plugin from scratch. Another developer would still need to learn the ins and outs of MUSHclient, but they could use my plugin as a reference - I reckon that would save them at least a week, even if they wanted to create their own plugin from scratch.

There was also a gap of nearly a month when I didn't do any work directly on the plugin at all, just an indirect bugfix and a quickly written function for generating the dungeon tiles. But that's still easily 3 weeks that shouldn't be counted.

So now we're down to about 6 weeks. It's difficult to judge how much time I spend coding on the mud, particularly as I'm usually online at the same time, and therefore answering questions and helping people alongside my coding. But if I had to give a figure I would guess perhaps 20 hours per week on average, and I was still spending at least half my time working on the mud. So that would be what, around 60 hours work? That sounds pretty high to me though.

Of course an experienced plugin developer could do it a lot faster, or someone could just copy and modify my plugin.

How much would someone need to know about mushclient and lua to write plugins like this for it?

Not much, it's relatively straightforward. You also don't need to use Lua, there are bindings for other scripting languages. (No Ruby though AFAIK, there are some issues with the ActiveScripting engine for it IIRC.)

I played Mortal Realms back in the days, pretty much everyone used the interface because it gave a big advantage, and as a result pretty much everyone used either zmud or tintin++. Tinyfugue has innate vt100 support from the terminal, but strips VT codes (or something of that nature) by default. So because of the interface everyone used VT clients, and because everyone used VT clients lack of support wasn't considered an issue by the developer.



You could have created a VT100 interface in a lot less time, and by steering people away from mushclient instead of toward it have a pretty large portion of your player base use it. Of course it wouldn't look as good. I'm still somewhat pessimistic, then again, it's a lot less trouble when a dev only adds MSDP, and leaves the client side development to the playerbase.

Didn't you kind of defeat your own point here?
That's like saying that a nice 3d game could have been made with cheesier 2d graphics in a lot less time, but yeah, "of course it wouldn't look as good"…

This doesn't have anything to do with the fact that your client is console-only, hmm…? :wink: