Zugg Software :: View topic

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Not sure where wishes go so I'll try here: Would it be possible to remember the last tab used in the script editor so you won't have to start on the wizard tab every time when you don't use it anyway? It's a bit annoying having to change it all the time.

Wizard Joined: 22 Mar 2007 Posts: 2320

Since this is a brand new feature of the very latest Beta version, this is the appropriate forum. At the top of the forum, you might note a new stickied topic about the script wizard. You should read it. There is an option to turn off the wizard, but for right now, Zugg wants the beta testers to test the wizard as hard as they can.

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Thanks. I wonder who's asking for this wizard...

Wizard Joined: 22 Mar 2007 Posts: 2320

People who are new to scripting and just want to write simple triggers to color lines, display messages, etc. One of the complaints about Cmud (and Zmud until it got a wizard) has been the steep learning curve, and some potential users have said this is one of the problems keeping them from buying Cmud.

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

I agree with you on that, but I am sorry to say that I really don't think this wizard will do the trick. There are things that could be done to make a better mud client however and the first one is to change the view of what CMUD should be. As long as Zugg insists on seeing it as a development environment he will not hit the mass market and that's really a shame because CMUD is by far the best mud client if we only look at features. The downside is the complexity and the fact that it has not been very robust compared to other alternatives.

My suggestions would be to focus on making a superb mud client that is easy to get started in. That means that things like aliases, macros, simple triggers, etc. should be easy to create and it is vital that the application is robust. I see far too many exceptions today and most of these should never occur. The reason why they do anyway is because CMUD does not handle things as it should really. One of the worst mistakes Zugg ever made I think was exposing multi-threading to the users. Now that is not something you do if you want to be a userfriendly client. Why doesn't CMUD handle all this complexity itself? Reason is that this is much harder than just letting the user have the problem. Again this is caused by the current mindset that CMUD is a development environment. Problem is that as that CMUD is not very good as it lacks a lot in documentation, robustness, debugging capabilies, etc. not to mention that the "language" is not up to par with what you would expect. As a mud client nothing else today compares to CMUD but the price is that you use a lot of time writing scripts instead of playing your favorite mud.

Today CMUD is a jungle of features and many of them are not very well documented. Some features are simply not working well because Zugg is focusing more on implementing new features that on keeping the existing ones working. If you have very limited human ressources (I understand that Zugg is the only developer?) you don't want to make loads of new features all the time that you need to maintain. Instead you try to improve what you have already and perhaps even fade out features that is not wanted anymore because new improved feature exists.

One thing I would suggest to gain customers is to maintain a codebase with all the general features and then make different "Versions" on top with built-in settings for a specific mud or group of muds that are similar. A bit like I make a lot of scripts for my simutronics mud, DragonRealms, Zugg could make something similar perhaps with help from players of those muds who have solid knowledge of what would be important to have from the start if you choose CMUD for your game. Today I need to write the roundtime gauge myself and react to gsl triggers, etc. Not very friendly for newcomers really and even for me it takes a lot of time although I am no newcomer. Today the users of the clients offered by Simutronics run scripts that are written in a very limited instruction set which could probably easily be mapped to CMUD's own instructions. If people could actually run these scripts in CMUD that would eliminate a major reason to stick with the other clients. Even the basic simutronics account costs the same for three monts as a lifetime CMUD license today so having to pay for CMUD would probably not stop anyone although the simutronics clients are free. The mapper is a great feature that should knock most people of their feet. If you could even improve it's graphical capabilities (make it look more like a real map - I think there was something like this earlier?) and perhaps even provide a starting map with most locations that would just be superb and you could have players help you there.

I could write for the rest of the day but I'd rather have some response to my suggestions so far. :-)

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Another day another suggestion. :-)

How about graphical "skins" that community members can contribute to? CMUD is a bit boring in its look - you don't really get in the right mood for your game and screenshots certainly don't look very appealing compared to some other clients like Simutronics' StormFront. If you could have medieval style, sci-fi style, etc. you would have a more tasty product I think.

This will of course not stand alone but in conjunction with predefined settings for certain popular muds I think you will come a long way. If you then add a simpler view on top of the settings for the most common used features then I think you are just about where you want to be and should be. The "simpler view" could be where you add a higher abstration to your settings. Don't ask your user to make a trigger reacting to certain strings or regular patterns and executing a script - make for instance a highlighting menu where people can define groups of textlines and define style for these with nice colorpickers, etc. as you use already on buttons. These settings will just map to current triggers, variables and other settings below so advanced users can continue to use the current editor. You should probably hide the settings made in the "upper" view to avoid people making changes that the this upper view can't handle.

Imagine this: User gets CMUD reccomended by another user playing the same mud. He downloads and installs the client and starts it up. For supported games theres is an icon just like you have today for sponsored muds which he clicks and quickly gets logged in. He notices that there are certain windows open from the start and the UI is styled for this certain game. One window is the main window and there are other windows where certain information like deaths, logins, room descriptions, etc. is shown. He also notices that there is a map that contains all the places he knows plus a lot more and makes it fast for him to move around. He meets his friend who hints that there are certain scripts he should try out so he does and the first time he might get a message that he should enter certain information like what his lootbag is and where he has his favorite weapon. From then on this script runs until he changes gear and script once again asks him to enter settings. He meets critters that are highlighted depending on their strength and he has nice gauges that show his health, what he has in his hands, his roundtime, etc. Perhaps he doesn't want some of these so he enters the "high level setting" and turn them off by uncliking a checkbox. All in all he never really need to script anything and if he does it's either simple or he decides to learn to make complex stuff himself. Now and then when he starts up CMUD he is told that there is an updated version of the settings for his game that he can download just as you upgrade CMUD versions today. Before long he reccomends CMUD to all his mud friends and also some colleages that haven't played a mud yet.

If you have special settings for a certain game you should also have much more potential to get it's makers as an official sponsor which might also increase your customer base if they reccomend it on their site. We are not so far off in terms of development I think, but it would make the whole difference...

Wizard Joined: 22 Mar 2007 Posts: 2320

Some of your ideas are quite good. I will comment on only a couple of them, giving some background on the history of Cmud related to your ideas.

Threads: The only time that users actually have to deal with threads is when using commands like #WAIT, and you really do want that to spawn a thread. Zmud had the #WAIT command, and did not have threading, but this meant that #WAIT did not act like people expected it to work. A #WAIT would actually prevent any other Zmud processing until the #WAIT process finished executing. It was user demand for a proper functionality for #WAIT that forced Zugg to add threading. If the #WAIT command spawns a thread, then Cmud needs to provide all the other thread-related features as well.

Skins: Cmud did originally have the ability to use skins. Unfortunately, it caused major problems, causing Zugg to spend too much time on it. Eventually, after polling the users, he decided to drop them.

A simpler view: This is exactly what the wizard tools are intended to be, for novices. You might want to make comments and recommendations on how to make the wizard tools more like what you want to see. I'd like to hear you expand on this.

Versions for different muds: Zugg can't possibly write such specialized stuff for the huge range of muds out there. So, he created packages, and the Package Library. The Package Library is intended for exactly what you are tallking about--a collection of resources that users can contribute for customizing Cmud, especially for specific muds. One thing it can't provide yet are maps, but that is one of the major goals in the 3.xx map rewrite project. It really could not be done using the old map code, so this was one of the motivations for rewriting the map code from scratch, and thus much of the last year's work. Eventually, the intent is to allow maps, configurations, and mapping scripts to be shared more easily. Creating location objects and moving room scripts to ordinary classes was a big step toward that.

I'm a little confused because you say that Zugg should concentrate on documentation and making Cmud more robust, and then you say Zugg should provide dozens of variations for different types of mud. That seems inconsistent. Can you explain where you think the balance should be?

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Wizard Joined: 22 Mar 2007 Posts: 2320

Wizard Joined: 22 Mar 2007 Posts: 2320

Posted: Thu Apr 01, 2010 4:30 pm

Well, sorry you don't like the wizard. You are in the vast minority of the feedback I have received.

But you even said it yourself:

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Hi Zugg

I am sorry that you take my comments this hard. I do want to assure you that I have no intention of making you angry or anything. Like you I would like CMUD to be a success - after all it's my favorite mud client and I would hate to see you stop working on it. Exactly because of this however I do feel I need to say when I think you are going in a wrong direction. I think you need to have criticism if you want to improve. I know you like to add fancy features in CMUD but in the end you need regular mud players who don't know anything about scripting. Most of the players I know NEVER write their own scripts and I think the sooner you realize that you need to please these too the better.

I know that you are trying to make CMUD more appetizing to casual user but I do think you should take a more radical approach than you have with the wizard. I'll be happy to go into more more depth with my suggestions but if they are considered as provocations I think it's better to just close the discussion and wish you all a happy easter. :-)

Posted: Thu Apr 01, 2010 10:18 pm

Yeah, but it's pretty frustrating when I was *already* responding to criticism in the first place by adding the wizards.

Specific and constructive feedback on how to improve the wizards in the future would be appreciated, although it's too late for a complete redesign for this round of beta versions. Maybe something better can be added to v4.x. If you felt like this, it would have been nice to have you participate in the usability feedback that I did for the script wizard several weeks ago. That was the purpose of that testing.

I think it comes down to everybody has different opinions. In the case of the new wizards, I think I'll wait till the public version and see what actual novice players think.

Posted: Thu Apr 01, 2010 10:19 pm

And you know what's even more frustrating is that I already predict that when I release the 3.x Public Version, people are just going to complain that there are no new features that make the upgrade worth the money. So I guess I'm screwed no matter what I try to do.

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Posted: Fri Apr 02, 2010 9:14 am

Isn't our license already set up so that once you buy CMUD, if after two years you want to continue getting new updates, you need to update your license at half the current retail price of the software?

Posted: Fri Apr 02, 2010 4:30 pm

Yes Fizgar, that is how it works. Upgrading to the 3.x public version will cost $15 if you purchased CMUD more than 2 years ago. If you purchased CMUD within the past 2 years, then the upgrade (and all versions of 3.x in future) is free.

I tend to agree with kjaerhus that the $30 for CMUD and $15 for upgrades is dirt cheap and could probably be increased. But I also know that I get plenty of people using zMUD who already complain about the $30 for CMUD. My guess (no promises) is that I'll keep the current prices the way they are for the 3.x release, but then increase prices a few months after the public release. I'd like to reward those people who upgrade to 3.x right away. And the price for zMUD (plus free CMUD) will definitely be increasing soon.

As far as the "value of 3.x" we are talking about, I think I'll be able to make a pretty good case. There are a wide range of new things in 3.x for almost anybody, from scripting to mapping to novice-user to buttons and UI improvements. It's also possible that 3.x will get some of the new protocols being discussed at mudstandards.org if we can get that worked out soon. I also plan to spend a significant amount of time creating "screencast demos" of the 3.x public version after it is released. That should address the help/documentation issues.

So it will be fine. Sorry I got frustrated...I've had a few annoying days lately. I just need to grow a thicker skin. I *know* that people will complain no matter what I do...people *like* to whine and they've been doing it for the past 15 years, even with zMUD. So it's nothing new. I very rarely ever get positive feedback. In fact, the Script Wizard and Pattern Wizard have probably generated more positive email than anything I've done in a long time, so I should feel good about that and not let other stuff get me down.

(P.S. Themes *will* be coming back eventually. The Theme system I was using before was horribly written (3rd party) and extremely buggy and unstable, causing lots of problems. But Developer Express added "skins" and themes to their controls a while ago and as I get more and more of the UI controls in CMUD using DevExpress, I'll eventually turn on their themes and see how they work. Just hasn't been a big priority. You'll see Unicode support before you see Skins/Themes)

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

I've allied myself with a little friend who can cheer you up with a cake whenever I'm too rash in my comments. I'll try to focus on making my critique constructive but sometimes I tend to get going so please accept my apologies in advance. Very Happy

I'm glad to hear that you plan to stop "giving away" your fine product. That way perhaps we can hope that you will earn enough to work on this project full time always. Perhaps you could consider some supporter program or something like that users can subscribe to and then perhaps get some advantages like having access to a special forum where new features in CMUD and your other projects are being discussed and perhaps even have a vote or something when deciding what new features to go for. I haven't thought it through really but I would gladly participate in something like that if it could help the development of CMUD.

Wizard Joined: 22 Mar 2007 Posts: 2320

That sounds like the Beta forum. Zugg often solicits comments on potential new features here. How would it be any different?

Posted: Fri Apr 02, 2010 10:34 pm

Actually, when the new web site is released later this year, there *will* be a "subscriber-only" section that will have some special features for people who want to pay a bit more to support Zuggsoft. But I'm not ready to talk about the details yet and I haven't scheduled the actual work on the new web site yet (although I've got the technology to be used for the site straightened out).

Also, a way to "vote" on new features is something that I definitely plan for the new site (for all users).

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark

Magician Joined: 18 Dec 2006 Posts: 317 Location: Denmark