I don't have a problem with the announcement - after all MUSHclient is free, so another free client isn't going to reduce my revenue. :-)
I acknowledge that MUSHclient has some features that I would do differently if I had the energy to rewrite the client from scratch - for example script functions could be more consistent, and with less duplication of the way things can be done.
I see from your forum that you have people busily describing what they dislike about MUSHclient/zMUD/cMUD/MM2K so that is healthy starting point. What perhaps is more subtle and easier to miss is the things that work smoothly perhaps without your noticing it. In other words, a lot of things in MUSHclient are the result of design decisions, tradeoffs if you like, where a feature that doesn't quite work the way you want, actually helps something else work well.
I see a comment about the user interface in other clients to be "quite cluttered". This is hard to avoid, either you have big cluttered dialogs, or lots of small dialogs, where you start wondering under which dialog a feature is to be found. Still, hopefully you solve that, and do it in a way we will all want to copy. :)
I hope you incorporate Lua scripting - I would recommend that in any case. [EDIT] I notice when re-reading your post you mention Lua, sorry for not reading more carefully.
Lua would also be a good choice for saving the world file - saves writing an XML writer and parser, especially if you are using Lua anyway.
The thing about big programs like zMUD and MUSHclient is that they gradually evolve - in their cases over something like over 13 years. It is easy to look back after 10 years and say "oh, I wish I had done that differently". Hopefully you will learn from our mistakes and not repeat them.
The source for MUSHclient is publicly available, so you are welcome to browse it for useful routines (eg. base 64 decoding, UTF8 handling and so on). I hope that anything that I have clearly written myself will be attributed, and the same for other authors. I am sure that we are all working together for the good of the MUD community and that this will not be a problem.
I think some sort of module / plugin system is a must - that lets people extend the client without worrying about what triggers / scripts / datanames other scripters might be using.
I had a look at wxWidgets a while ago - this gave Windows / Linux / Mac compatability, however I found that, at the time, it was a bit flaky. If you are using that, hopefully it has improved since then.
I notice a comment on your forum:
Quote:
So, the buddy package must access a variable set in the session. Thus, now you have a namespace question. The buddy package could document that the session should define a variable called "buddylist". But, what if some other package you want to use decides to use the same name?
This is solved in MUSHclient by plugin state files - something like a buddy list (or ignore list, etc.) can be in a state file. There is a state file per plugin, per world. Thus the plugin itself doesn't have to have buddy lists in it, and presumably you have different buddies on different worlds, so the state file idea works well there.
You have some good ideas there - and every now and then another one pops into my head too. ;)
I was thinking of better SQLite support, an SQL database would be good for sharing things (eg. names of spells) between different characters, who play on the same MUD.
All the best with the new project, and maybe some of the regular posters here will drop in on your forum and add some more suggestions too.
|
![[Go to top]](/images/gototop.gif){kind=small}
top