18 Jul, 2011, linkmeplx wrote in the 1st comment:
Votes: 0
As the title informs, I am currently writing up a new Windows MUD client. This offers a few challenges, the most pressing in my eyes being: what does the MUDding community expect from a client, and what do we really want to see in a client.

There's a few features that are, in my opinion, just common sense, like triggers and macros. Those two aside, what features do you hope to see/need to see in this new client?
18 Jul, 2011, David Haley wrote in the 2nd comment:
Votes: 0
Do you have specific features in mind to set you apart in the first place? Are you writing a client just because you feel like it, or have you already identified some key differentiators?

Popular areas of work these days are web-only clients. Twisol will have plenty to say about that… :smile:
18 Jul, 2011, linkmeplx wrote in the 3rd comment:
Votes: 0
I started the client as a desire to write my own, for my own use. But I figure a lot of the stuff I think would be nifty, others might appreciate as well, such as graphical representations of things like HP and such, but customisable to nearly any standard of representation across many codebases. That in itself will present the challenge of testing it on the various codebases. I will also attempt many of the features found in VWMud (which served as my original inspiration, and written by my step-father Vaughan Wynne-Jones), like the Defcon system. Other than that, the project has not advanced terribly far beyond basic workings, such as connecting and displaying text. I have yet to implement colour support.
19 Jul, 2011, Rarva.Riendf wrote in the 4th comment:
Votes: 0
why not contributing to already existent client like mudlet ?
19 Jul, 2011, Twisol wrote in the 5th comment:
Votes: 0
Before I say anything else, good luck with your project! Writing a MUD client is a lot of fun. :smile: What language are you writing it in?

As DH implied, I'm writing a client that runs in any reasonably modern browser. The biggest benefit to me is that I get immediate access to HTML and CSS, which makes it relatively easy to build out the front-end, and it opens up new possibilities for client-side rendering. Plus, users don't need to explicitly download anything, since it's just a webpage.

Relatively speaking, you might have difficulty differentiating your client from the other desktop clients. For example, Mudlet has a relatively good user experience, and MUSHclient has an impressive amount of power in its scripting. Both clients allow you to create graphical widgets like health gauges. I can't speak about any other clients since I'm only familiar with the two. It's no big deal if it's just a personal client, but if you want to see user adoption you should think about how you want to stand out. What kind of MUD client are you building? :wink:
19 Jul, 2011, linkmeplx wrote in the 6th comment:
Votes: 0
Yeah, it is a lot of fun. Coding in any regard is fun though, IMO. I'm writing it in AutoIt. I found it like a year ago and just now decided to give it a shot, since GUIs are easy as…well…something easy, plus its actually a powerful BASIC-like language. As for standing out, I don't really know. I haven't put that much thought in to it. Its really more of a personal thing that I'd like to share with others. I'm not very competitive. Maybe you guys could give me some insight as to what I could do to stand out more?
19 Jul, 2011, Twisol wrote in the 7th comment:
Votes: 0
Ah, wow. AutoIt isn't an environment I'd have picked, but if it works for you go for it. I actually expected you to name C#. :biggrin:
19 Jul, 2011, Arynth wrote in the 8th comment:
Votes: 0
Seeing you mention AutoIt, I have to speak up some (I'm on those forums as well). Using AutoIt means it will be Windows only, unless they use Wine to run it on Linux/Mac, but that it will be self contained without dependencies (except for whatever files you use for storage). I think that would be very nice.

As far as features, I say start with the basics, and leave yourself open to the possibility of adding more later on. Triggers and macros would make for a decent Version 1, .5, or something to let people see/play with.

Only problem I can think of with using AutoIt is if you ever try to give users of the client access to another scripting language. I don't recall seeing a good way to do it, but there may have been some promising examples for Lua (of all things) on the forums.

Oh, and just so you know, you could even make a mud server using AutoIt (which I've done just as a test before, worked great), so just keep at it.
19 Jul, 2011, linkmeplx wrote in the 9th comment:
Votes: 0
Yeah I know it'll be windows only (for the most part). Later on I'll actually port it to python or something. As for getting a server set up, that'd actually be pretty cool. I just might do that as a side project. Anyway, thanks for the advice and info
19 Jul, 2011, Runter wrote in the 10th comment:
Votes: 0
Why type of features did you AutoIt mud server have?
19 Jul, 2011, Arynth wrote in the 11th comment:
Votes: 0
It was super basic, only thing I had to do different was the allowing of a copyover. I couldn't tell how to do a copyover on Windows as you do on Linux, so my idea was to run 2 processes, one that handled nothing but the data coming from sockets, and then the other that was all the actual mud functionality (from the command interpreter down). Getting the IPC for that all setup was more of a challenge than actually making the mud server, but I learned a lot about both.

Main problem I had was deciding on how to store things/retrieve them. SQLite, XML, ini, pfiles, etc… I still have those arguments with myself sometimes, too. :)
19 Jul, 2011, Runter wrote in the 12th comment:
Votes: 0
re copyover

If you design a program in a way that the lib is segregated from the driver you can copyover simply by having the connections persist at the driver level, while "rebooting" the lib. The actual process never needs to be restarted that way and you're not dependent on technology specific vuhdo wrt to the connections. Of course, then the driver changes require an actual reboot– But I think they should!
19 Jul, 2011, Arynth wrote in the 13th comment:
Votes: 0
That was also my thinking. I'd considered moving most of the "core" stuff into the networking side, essentially creating the driver you speak of, and then having the actual decision making, gaming aspect of it become the lib. Figuring out what needed to be where, as well as how to organize it all properly, was more than I was willing to take on, given I originally did it as more of a "I wonder if…" kind of thing.

I love the idea of never needing a copyover again, but am aware that you really have to plan for such a thing far in advance, or just accept that you'll need to reboot the whole thing to make certain types of changes, no matter what.
19 Jul, 2011, Runter wrote in the 14th comment:
Votes: 0
One way to make copyover less needed is just requiring less reboots in general to make changes. There's no reason that you should need a reboot, for example, to edit a help file, or any other data live. Sometimes copyover is just used to reset the state of the game to default.
19 Jul, 2011, Arynth wrote in the 15th comment:
Votes: 0
Oh agreed, anything that can just be reread from file via in-game command (that isn't "copyover") makes sense to me, no matter the underlying technology.

Ok, I'm done derailing the OP's topic. :redface:

If I had to suggest something for a client, it would be to either use an imbedded webpage for output display, or a RichEdit Textbox. They each have their merrits/drawbacks, so it would really be up to you to decide which is more worth it in the end.
19 Jul, 2011, Kaz wrote in the 16th comment:
Votes: 0
linkmeplx said:
As the title informs, I am currently writing up a new Windows MUD client. This offers a few challenges, the most pressing in my eyes being: what does the MUDding community expect from a client, and what do we really want to see in a client.

There's a few features that are, in my opinion, just common sense, like triggers and macros. Those two aside, what features do you hope to see/need to see in this new client?


I would do it the other way around. Rather than ask what we want to see in a client, I would tell us what killer feature is going to make your client the one that we want to use?

*For example, I use Tintin++ on muds because it fits nicely in an Xterm window and has support for triggers and shortcuts. Clients ZMud and Pueblo became popular for their embedded protocols (MSP, MXP, etc.). Mudlet and MUSHClient are well known for their scripting capabilities. Twisol's client will run in a browser. The Bedlam client runs on an Android phone.

What niche feature do YOU see the need for?


(*pre-emptive apologies to client authors here. I know your clients are all fully featured, and have way more stuff than this laundry list, but that's not the point)
19 Jul, 2011, plamzi wrote in the 17th comment:
Votes: 0
Kaz said:
linkmeplx said:
As the title informs, I am currently writing up a new Windows MUD client. This offers a few challenges, the most pressing in my eyes being: what does the MUDding community expect from a client, and what do we really want to see in a client.


*For example, I use Tintin++ on muds because it fits nicely in an Xterm window and has support for triggers and shortcuts. Clients ZMud and Pueblo became popular for their embedded protocols (MSP, MXP, etc.). Mudlet and MUSHClient are well known for their scripting capabilities. Twisol's client will run in a browser. The Bedlam client runs on an Android phone.

What niche feature do YOU see the need for?


Slight correction: The Android client is called "Blowtorch" and I've heard good things about it. My mobile clients are for iOS (see sig).

Other than that, Kaz and the rest have shared some very good advice here. Even if you mean this as a fun experiment, it doesn't hurt to shoot for a niche. That is, if you care about whether your client will actually end up being used in the real world.

My personal bias is for clients that make it easy to visualize elements of the gameplay. If you're good at graphic design, one interesting approach would be to try and provide an easy-to-customize char info hub out of the box, a nice and clear mini-map, and why not even drag/drop inventory management and mob icons? You're not going to wow anyone with triggers and aliases, which other clients have been perfecting for many years. But a client focused on easy-to-setup visual richness would be worth pursuing, I think. If you do decide to go that way, I have a ton of public domain item and mob icons I can share with you.

In any case, good luck with your project.
19 Jul, 2011, Littlehorn wrote in the 18th comment:
Votes: 0
I think having a client with an epic GUI interface that's similar to the top MMO's out there would be nice. You know, something that you can fully customize (or remove) based on simple triggers for those who have little knowledge of scripting. That way they can have something similar to some of the graphical online games they play right out the box.

A good portion of the best MUD's out there do the same thing with custom clients. Then those that don't, rely on players to sink time and money into clients (zMUD, Mudlet etc) that are powerful enough to support from-scratch interfaces. Why not have one that has a nice tool that customizes a pre-defined GUI for you out the box that actually looks sexy as hell. :D
19 Jul, 2011, David Haley wrote in the 19th comment:
Votes: 0
Don't forget that all of that is nice and good, until you run into the problem of needing some server-side support for the more interesting GUI elements.

It would be nice to have nicer GUI elements that are easier to use, but honestly the effort would probably be better spent packaging together things for an existing client rather than starting from scratch.

Again if it's just for fun, that's totally fine, but if this is supposed to be something people use, a little more focused effort on a specific problem would be useful.
19 Jul, 2011, linkmeplx wrote in the 20th comment:
Votes: 0
As a note, this really isn't something I'm doing to make people drop their preferred clients. That's just silly. Its mostly for myself that I'll be uploading here so others can try it, and well if they like it enough to switch, that makes me happy. Otherwise its just another among god knows how many options. HOWEVER. Its not to say I won't make the effort to write the best gorramned client possible. But if you want/need a reason to use my client instead of others, use mine cos I told you to and I'm just simply amazing (may or may not be fact).
0.0/50