23 Sep, 2009, Vassi wrote in the 1st comment:
Votes: 0
With all this talk of clients the last week or so it felt like the right time to ask this question.

What's the deal with triggers and entire APIs being built into a MUD client? I want to be as clear on this as possible, so I won't leave it that open ended. An API\scripting environment to catch telnet commands is justifiably useful for plugins. (I.E. MushClient) To a certain extent, this is also useful on clients like z\cMUD that can create gauges based on prompt recognition. Aliases are also useful, because they allow people to customize their input to an extent and save on typing or makes it easier to remember commands.

Line gagging and triggers (for the purposes of scripting, automating, or botting) just strike me as a universally bad thing though. I get that some folks have some administration stuff that is made easier by scripts, but that has to be (or should be) the smallest slice of MUD users. Does no one feel that these things artificially improve a MUD by hiding away a lot of design flaws?

MUD spams too much? gag the lines. Why not have a configuration sequence to let the users tell your mud what they do and do not want to receive updates on?

Combat too complex? Use triggers to activate your stances and reflexes. Why not streamline combat so it isn't so complex? Eventually everyone will be using triggers, which in practical terms means that your complex system is just as simple as you feared it would be in the first place - because users don't have to do much except download a script file.

I'm just curious if anyone else feels the same way. Personally, the current state of MUD clients prevented from rolling out a 'traditional' Telnet MUD. Don't get me wrong, as a developer I geek out on all the features, but with a design hat on I hate them. Every last one of them.
23 Sep, 2009, Igabod wrote in the 2nd comment:
Votes: 0
So are you actually looking for some input here or are you just ranting? Please let me know, cause if you're just ranting I won't waste the effort of giving my input.
23 Sep, 2009, KaVir wrote in the 3rd comment:
Votes: 0
Vassi said:
Line gagging and triggers (for the purposes of scripting, automating, or botting) just strike me as a universally bad thing though.

But some players like them, and clients are designed for players.

Vassi said:
MUD spams too much? gag the lines. Why not have a configuration sequence to let the users tell your mud what they do and do not want to receive updates on?

You (as the mud owner/developer) can do that, but the players can't usually modify the mud itself. The client gives them a degree of control they wouldn't otherwise have.
23 Sep, 2009, David Haley wrote in the 4th comment:
Votes: 0
I agree with KaVir. A sophisticated client can be a way to work around problems in a MUD's design. Should the MUD developer fix those issues? Well, yes, but sometimes that doesn't happen, especially if the MUD is a downloaded codebase.

Basically, these sophisticated clients exist because for whatever reason many MUDs don't spend much effort on interface design. You might be particularly sensitive to these issues, considering that you are designing a MUD and a bundled client at the same time. :wink:
23 Sep, 2009, Sandi wrote in the 5th comment:
Votes: 0
I use zMUD, but have no triggers or even macro keys.

My partner Grumny uses tinyfugue, and he doesn't even use the MUD's command completion, always typing in complete commands.

(we each play our own game extensively, and each have over 2 dozen characters on an identical test port)

Hopefully, our game's interface reflects this in a positive way, but we also specifically allow botting, scripting, triggers, and anything else a player might find useful. Some people find coding their client more fun than playing the game, and you know what? I like coding, myself. So who am I to find fault with their preference?
23 Sep, 2009, ATT_Turan wrote in the 6th comment:
Votes: 0
I'm with the school of it not being a problem. I've played on MUD's with combat stances that didn't have an autostance feature - I simultaneously suggested it to the implementors and made a trigger for my client. I've recently picked up MushClient which has some awesome functionality, and I see no problem with gagging a MUD's automap and keeping it in a miniwindow that you can reposition wherever you like on the screen so that it doesn't spam your display every time you change rooms. Since that's functionality that (as far as I know) can't be "fixed" on the MUD side, how is it negative?
25 Sep, 2009, Vassi wrote in the 7th comment:
Votes: 0
I'm sorry I hadn't replied yet, I didn't mean to put on a troll costume I just have a crazy schedule nowadays. As usual there are a lot of very thoughtful replies.

Igabod said:
So are you actually looking for some input here or are you just ranting? Please let me know, cause if you're just ranting I won't waste the effort of giving my input.


There were several question marks in my post which the english language assures me are intended to provoke outside input. Kind of like I'm answering your question, because you used a question mark. Since your heart is so in it, though, feel free to not reply.

KaVir said:
You (as the mud owner/developer) can do that, but the players can't usually modify the mud itself. The client gives them a degree of control they wouldn't otherwise have.


I guess what I'm advocating is that MUD owners work that kind of control into the MUD as much as possible. I've seen a lot of MUDs with "brief" room descriptions or "full" room descriptions, as a for instance. I see MUDs like any other games, they are an expression of the designer's intent (most of the time). Barring the elements that were made customizable, I don't like the idea of people messing with the presentation. I realize I'm probably barking up the wrong tree here, MUDs being essentially open source and inherently dependent on the client for display, but font and color is one thing, completely masking or rewriting the output is another.

David Haley said:
I agree with KaVir. A sophisticated client can be a way to work around problems in a MUD's design. Should the MUD developer fix those issues? Well, yes, but sometimes that doesn't happen, especially if the MUD is a downloaded codebase.

Basically, these sophisticated clients exist because for whatever reason many MUDs don't spend much effort on interface design. You might be particularly sensitive to these issues, considering that you are designing a MUD and a bundled client at the same time. :wink:


The last is probably true.

ATT_Turan said:
I'm with the school of it not being a problem. I've played on MUD's with combat stances that didn't have an autostance feature - I simultaneously suggested it to the implementors and made a trigger for my client. I've recently picked up MushClient which has some awesome functionality, and I see no problem with gagging a MUD's automap and keeping it in a miniwindow that you can reposition wherever you like on the screen so that it doesn't spam your display every time you change rooms. Since that's functionality that (as far as I know) can't be "fixed" on the MUD side, how is it negative?


I guess there is an unfortunate fine line. I don't have a problem with repositioning or segregation information. In fact, I'm a huge proponent of that. Nobody here has really addressed one of the more common uses of triggers (that i've seen) and that's botting, automation, etc. These other features are nice, but it seems like the price is high. Perhaps I'm also sensetive to this issue because I'm making a faction-based PvP game, where balance is critical and a couple of players with clever triggers could seriously hurt things. All I really hear though, is "it makes the players happy". Is it because MUDs are so player starved that they're willing to make this compromise?
25 Sep, 2009, Orrin wrote in the 8th comment:
Votes: 0
I don't think it's necessarily bad design if players are using clients to change the MUD presentation. The big boys like WoW and WAR have scriptable client interfaces with plenty of third party mods and enhancements available and this was presumably by design. There's also blind players for example who may rely on client functionality to make the game playable for them.
25 Sep, 2009, David Haley wrote in the 9th comment:
Votes: 0
Personally I don't believe that triggers should be accepted simply because they make the players happy. Making players happy is well and good, but if it establishes an imbalance between those who use triggers and those who don't, it can subvert the rest of the gameplay. I don't like botting or automation, because that indicates one or more of the following things to me:
(a) the player is "cheating" and getting points for free
(b) the game design is broken because it allows such cheating to occur
© the game design is broken because it forces tedious tasks that are simply automated away

The tedium argument is the more interesting one, really, because I think it's easiest to fix. If players need to keep eating food, just have the food eating happen automatically instead of forcing them to "eat bread". It's a lot harder to address the problem of somebody creating a "fake player" to get around game mechanics that can otherwise be quite interesting (such as a limit on how much one can carry).

All of this said, if one wants to appeal to people who like writing triggers, then why not turn that into the game explicitly? Have a "Netrunner" type of game, where you play as some kind of hacker (or defending systems administrator) where the whole point is to program in offense and defense. In other words, the game would be explicitly devoted to automating the reaction to various events.

I think you might also be on to something when you observe that MUDs have an issue with player attraction and retention, and this can force some compromises.
25 Sep, 2009, KaVir wrote in the 10th comment:
Votes: 0
Vassi said:
I guess what I'm advocating is that MUD owners work that kind of control into the MUD as much as possible.

Fair enough, but of course its up to each individual mud owner to decide where to draw the line. The key word here is "control". Each of us controls our own mud, and each player controls their own client. Offering greater flexibility to the players is nice, but there will invariably be things they want that the mud doesn't offer (for example you've said you don't like people messing with the presentation, but some players will want to do exactly that). That's where the client comes in.

Vassi said:
Nobody here has really addressed one of the more common uses of triggers (that i've seen) and that's botting, automation, etc. These other features are nice, but it seems like the price is high. Perhaps I'm also sensetive to this issue because I'm making a faction-based PvP game, where balance is critical and a couple of players with clever triggers could seriously hurt things. All I really hear though, is "it makes the players happy". Is it because MUDs are so player starved that they're willing to make this compromise?

There is no "compromise", because the client is controlled by the player, not you. You basically have two choices - either you design your game in such a way that triggers can't "seriously hurt things", or you lay the smack down on anyone who doesn't play the mud the way you intended it to be played. Personally I favour the former.
26 Sep, 2009, Scandum wrote in the 11th comment:
Votes: 0
From what I gathered combat is so complex on IRE muds that you need a client with a complex script in order to compete.

I think one solution that works well is giving a bonus to people who play infrequently, and ultimately avoiding game systems that require a lot of time to accomplish, or are so difficult that it's rewarding to script it. Making scripting harder will only increase the power gap between those who are capable scripters, and those who are not.

Regardless, it's impossible to outsmart botters, so I'd say it's easier just to ban botting, instead of trying to fight a losing battle.
26 Sep, 2009, ATT_Turan wrote in the 12th comment:
Votes: 0
Vassi said:
I'm sorry I hadn't replied yet, I didn't mean to put on a troll costume I just have a crazy schedule nowadays. As usual there are a lot of very thoughtful replies.
Nobody here has really addressed one of the more common uses of triggers (that i've seen) and that's botting, automation, etc. These other features are nice, but it seems like the price is high. Perhaps I'm also sensetive to this issue because I'm making a faction-based PvP game, where balance is critical and a couple of players with clever triggers could seriously hurt things. All I really hear though, is "it makes the players happy". Is it because MUDs are so player starved that they're willing to make this compromise?


I for one didn't mention it because I didn't think it significant. Aside from disagreeing with you as to how common it is, I just don't see what the big deal is - I've never played a MUD that had items you could achieve only if automating your actions through triggers, or levels you could only reach that way. If one's complaint against the possibility of botting is simply that a person can gain/achieve whatever their goal is faster than players who only work toward it when they're actually at keyboard, well, whatever, unless the point of the game is some sort of race it makes no actual difference.

I would not call you wrong about your own game, but I'm curious as to how the use of triggers could throw it off so badly. Unless they have to type in large amounts of text, triggers just save you a second or so when typing in a command (maybe another portion of a second for the initial reading and reaction time).

When I played Godwars 2 (which I should do some more…), I had some number of triggers and multi-command alises set up, mainly to activate combat-starting spells or flip to my feet or such. It saved my fingers some typing time and effort, but certainly didn't allow me to compete against mobs or players of a higher power level than my own.
26 Sep, 2009, Dean wrote in the 13th comment:
Votes: 0
Scandum said:
From what I gathered combat is so complex on IRE muds that you need a client with a complex script in order to compete.

I think one solution that works well is giving a bonus to people who play infrequently, and ultimately avoiding game systems that require a lot of time to accomplish, or are so difficult that it's rewarding to script it. Making scripting harder will only increase the power gap between those who are capable scripters, and those who are not.

Regardless, it's impossible to outsmart botters, so I'd say it's easier just to ban botting, instead of trying to fight a losing battle.


QFT
26 Sep, 2009, KaVir wrote in the 14th comment:
Votes: 0
Scandum said:
From what I gathered combat is so complex on IRE muds that you need a client with a complex script in order to compete.


And from what I gather, they view that as "part of the game". The problem is they effectively end up with automated combat again, if that's the only way to compete. That strikes me as a design flaw, if their intended goal was to create a manual combat system.

I know IRE copied their combat system from Avalon - but does anyone know if Avalon had the same problem? What about Gemstone and the like, I think they have a similar combat system, but I only recall people talking about scripts for the IRE games. Is it just that IRE added more options to the point where manual play was no longer feasible?

Scandum said:
I think one solution that works well is giving a bonus to people who play infrequently, and ultimately avoiding game systems that require a lot of time to accomplish, or are so difficult that it's rewarding to script it.

I definitely agree, and that's pretty much what I've done, but I think that's more of a general solution for reducing the value of botting. It doesn't help resolve the problem of a manual combat that requires automation to be competitive.

Scandum said:
Making scripting harder will only increase the power gap between those who are capable scripters, and those who are not.

True, but combined with other factors that reduce the value of scripting, you might be able to convince more people not to bother. IMO its the perception of botting, rather than the activity itself, that is a big part of the problem - what players seem to hate the most is when everyone else seems to be doing it, and they feel they need to join the bandwagon or lose out. If you reduce it to an obscure curiousity, I don't think it would be a major problem.

Scandum said:
Regardless, it's impossible to outsmart botters, so I'd say it's easier just to ban botting, instead of trying to fight a losing battle.

The "lay the smack down" approach isn't something I favour, but if you do go that route, it's worth remember that you won't catch everyone. Catching a handful and making a horrific example of them could certainly help with the "perception of botting" issue I mentioned before, but that's still no excuse for leaving gaping holes in your game design.



ATT_Turan said:
When I played Godwars 2 (which I should do some more…), I had some number of triggers and multi-command alises set up, mainly to activate combat-starting spells or flip to my feet or such. It saved my fingers some typing time and effort, but certainly didn't allow me to compete against mobs or players of a higher power level than my own.

The difference is that the GW2 combat system was specifically designed to minimise triggers and aliases from giving a gameplay advantage. Of course they can make life easier (and aliases are built in to the game for that very reason), but they're not necessary. You can compete just fine without them.
26 Sep, 2009, Orrin wrote in the 15th comment:
Votes: 0
KaVir said:
And from what I gather, they view that as "part of the game". The problem is they effectively end up with automated combat again, if that's the only way to compete. That strikes me as a design flaw, if their intended goal was to create a manual combat system.

I think the intended goal was probably to create a system highly sensitive to both player skill and character skill. To the extent that player skill == client scripting ability I guess you could call it a success, although the combat system is touted as one of the major draws of their games and they seem to be very successful so I'm sure they are happy with it. Personally I think Avalon had a far simpler yet richer combat system, but I'll admit to being much more familiar with Avalon than I am IRE.

KaVir said:
I know IRE copied their combat system from Avalon - but does anyone know if Avalon had the same problem? What about Gemstone and the like, I think they have a similar combat system, but I only recall people talking about scripts for the IRE games. Is it just that IRE added more options to the point where manual play was no longer feasible?

I haven't played Avalon for quite a few years, but my experience was that pretty much everyone who took part in combat used aliases, triggers and client scripting to some degree, but nowhere near the level that they do in IRE. It would probably require analysis of both systems to determine exactly what the differences are that caused this, but I think it's fair to say that yes, IRE have added more and more options such that manual play is no longer feasible. There is also a discrepancy between the IRE games in this regard with Lusternia (the most recent game) having the most complex system. I believe their Midkemia MUD is due for release fairly soon so it will be interesting to see what route they have taken with combat and if it will have yet more options again.
26 Sep, 2009, Sandi wrote in the 16th comment:
Votes: 0
KaVir said:
The difference is that the GW2 combat system was specifically designed to minimise triggers and aliases from giving a gameplay advantage. Of course they can make life easier (and aliases are built in to the game for that very reason), but they're not necessary. You can compete just fine without them.

Hopefully, my combat system achieves the same result. The timing is such that there's time to type commands, but their efficacy depends on the timing of the delivery. In the "it's always something" department, I suppose it could be said my game favors musicians over scripters. :wink:
26 Sep, 2009, KaVir wrote in the 17th comment:
Votes: 0
Orrin said:
I think the intended goal was probably to create a system highly sensitive to both player skill and character skill. To the extent that player skill == client scripting ability I guess you could call it a success,

The problem is that scripts can be (and are) transferred between players. So while scripts are technically the result of player skill, they aren't necessarily based on the skill of the player using them. Plus I'd argue that scripting is more programming skill than playing skill, more related to writing a combat system than playing a mud.

Sandi said:
Hopefully, my combat system achieves the same result. The timing is such that there's time to type commands, but their efficacy depends on the timing of the delivery.

I've only played your mud briefly and don't recall how the combat worked, but in my own system I really tried to play down the value of timing. IMO that's where most affliction systems go wrong - you have limited time to respond to something, and it's hard to keep track of all the appropriate responses, so it works out easier just to set up a trigger.

There are only really two combat situations where timing is important in GW2.

The first is when you get knocked off your feet (sweeps, knockbacks, etc) - but these are all countered in exactly the same way, with any feet-based move (and there are certain abilities and items that let you do so automatically), plus you can configure such messages to be displayed in a specific colour. When playing I usually just set such messages to bright red, and when I see red text I quickly respond with a two-letter counter command.

The second situation is when using a disarm or weapon-breaking defence. But this only happens when you intentionally set up such a defence, in which case you're actively waiting for the catch message, and you have around 5 seconds to respond once you see it.

Aside from that, timing doesn't really matter, as defences are automatic and attacks can be queued. The drawback of course is that combat feels a bit less interactive (as opposed to some combat systems I've seen, where you use explicit commands to block or duck under attacks). But it does mean there's little advantage in setting up a script - it'll save you time and typing, but it won't give a competitive advantage.
26 Sep, 2009, Orrin wrote in the 18th comment:
Votes: 0
KaVir said:
The problem is that scripts can be (and are) transferred between players. So while scripts are technically the result of player skill, they aren't necessarily based on the skill of the player using them. Plus I'd argue that scripting is more programming skill than playing skill, more related to writing a combat system than playing a mud.

I wouldn't disagree with that, and I was actually implying that scripting ability is a fairly poor measure of player skill. IMHO the main weakness of the reliance on scripting of the IRE system is that it raises the baseline to such a degree that a sophisticated scripted client setup is the absolute minimum to even take part. There is still room in the system for the top players to differentiate themselves in PvP, so in that respect it's working as intended, but it seems to me to be a flawed design when you have to wade through so many layers of mechanics to even get to the tiny part that separates the great combatant from the merely competent.
28 Sep, 2009, shasarak wrote in the 19th comment:
Votes: 0
Scandum said:
Regardless, it's impossible to outsmart botters, so I'd say it's easier just to ban botting, instead of trying to fight a losing battle.

The problem with banning 'botting is that such a ban is, by definition, unenforceable. If you really object to 'botting then the only valid approach is to tweak the balance so that 'botting becomes less profitable. The more rigorous the process of attempting to distinguish between 'bots and humans becomes, the more annoying it becomes to humans (while the 'bots don't care); so the more effort you plough into banning 'bots, the more harm that results to the people who don't 'bot. It's a bit like the war on drugs….
0.0/19