25 Jul, 2012, KaVir wrote in the 21st comment:
Votes: 0
Rarva.Riendf said:
Triggers is to repeat uninteresting thing to be done.

It doesn't matter how interesting something is, if triggers give an advantage, players will use them.

Command queuing won't stop people from using triggers, but it does help reduce the advantage they give, and therefore the incentive to use them.
25 Jul, 2012, Lyanic wrote in the 22nd comment:
Votes: 0
KaVir said:
Rarva.Riendf said:
Triggers is to repeat uninteresting thing to be done.

It doesn't matter how interesting something is, if triggers give an advantage, players will use them.

Command queuing won't stop people from using triggers, but it does help reduce the advantage they give, and therefore the incentive to use them.

So much this. Power players will write triggers for anything and everything if it gives even the tiniest advantage, or if they're just too lazy to bother paying attention to something. There's even the breed of player who writes triggers for no other reason than to see if he/she can. I recently implemented a trivia game run by an NPC. Within one day, I found players running bots on it to farm all the questions and add triggers for all the answers. Reason: Because. There's no real gain. The only thing it accomplishes is preventing other players who actually want to play the trivia game from being able to answer quickly enough.

I typically have no issue with bots or automated play of any sort. Besides, it's impossible to prevent. You can try to discourage it by removing incentive and leveling the playing field between the capabilities of the server and the client. Beyond that, all you can do is write policy and attempt to enforce it - something I refuse to waste my time on. My solution to the trivia botting was to write a new racial language module for the NPC asking the questions, which mangles the questions, preventing exact pattern matching, but still leaves them readable to humans. Still, this isn't a surefire solution. It does not prevent botting. It only increases the entry barrier. Someone with a bit of patience and regexp wizardry can still write a valid trivia bot. In fact, I have one player who already began doing that. I've just had to keep an eye on him, begrudgingly.

I think for phase two, I'm going to implement some response time analytics that can detect suspected botting and start ignoring answers from that player. Even then, any player with a sophisticated client could just have the triggers send responses on a random timer. It's a no win situation. That's really the point to this. If you think your players aren't writing triggers to circumvent your game mechanics, solely because they can, then you are mistaken. If you want to spend all your time policing player activity, so be it. Nevertheless, it's highly advisable that you make design choices that don't give huge incentives to write triggers, and don't further disenfranchise the players who choose not to. Removing any semblance of a command queue seems like the type of design decision that fails in this regard, for many of the reasons already given by others in this thread.

P.S. HK, you're aware that I used to play you game. I did have an extensive set of triggers. I also know someone who played (might still play, not sure), and had a very nice Mage-bot for automated, optimal use of your fantastic magic system. Take that as you will….
25 Jul, 2012, KaVir wrote in the 23rd comment:
Votes: 0
Lyanic said:
So much this. Power players will write triggers for anything and everything if it gives even the tiniest advantage, or if they're just too lazy to bother paying attention to something. There's even the breed of player who writes triggers for no other reason than to see if he/she can.

Or because they enjoy it. I remember talking to one of my players who wrote a lot of bots. For him, the biggest attraction of my mud was that there were no rules against botting.

Lyanic said:
My solution to the trivia botting was to write a new racial language module for the NPC asking the questions, which mangles the questions, preventing exact pattern matching, but still leaves them readable to humans. Still, this isn't a surefire solution. It does not prevent botting. It only increases the entry barrier. Someone with a bit of patience and regexp wizardry can still write a valid trivia bot.

I recently approached the same issue from the other perspective - parsing newbie-chats to see if they can be given an automated answer. Because the exact wording of a question can vary, it looks for certain sequences of keywords.

It doesn't handle typos, although I could do that easily enough with my soundex parser. It would increase the number of false positives, but if it was just trying to answer trivia (rather than help newbies) then that wouldn't be such a big deal.

Lyanic said:
I think for phase two, I'm going to implement some response time analytics that can detect suspected botting and start ignoring answers from that player. Even then, any player with a sophisticated client could just have the triggers send responses on a random timer.

You could record which trivia questions each player had successfully answered, and exclude those players the next time that question comes up. Or you could grab a massive list of questions from somewhere, so vast that they very rarely repeat. The "cool" solution would be a bot that continually trawls the net for new trivia and answers, but I could see that going horribly wrong.
25 Jul, 2012, Hades_Kane wrote in the 24th comment:
Votes: 0
KaVir said:
This is less of an issue for a non-PK mud. It's also less of an issue if the combat system is already primarily automated, as is the case with most muds.


I wouldn't consider us a PK MUD (PK is opt-in, but not overly stressed on the game anyhow), and our system is primarily automated. The only "issue" I feel like has been raised which has any credence toward not having a queue would be perhaps the half a second advantage someone with a queue might would have, but I still maintain the advantage would be negligible.


Runter said:
Because for a player like myself that may not use a fancy client or scripts, that means having to retype the command completely if it was slightly too soon. And dying, cursing the system, and leaving the game. Anecdotes about what your current players like isn't really saying much.


I don't use a "fancy client" or scripts, in fact until recently, I was still using an ANCIENT version of zMUD on my work computer (and that's about as primitive as an actual MUD client gets) and even in that one, you enter a command, and it stays on your command line w/o having to reenter the command (it's highlighted, so even a single keystroke or backspace will clear it). You enter the command half a second too early, well, in pretty much any client I've ever used, there's no need to retype, just hit enter again half a second later as the command is still there. I'm not seeing an issue here.

And I would disagree, anecdotes about what my current players like is really saying -everything-. You can speak until you are blue in the face with your developer hat on, but if what I have pleases myself and players more than what you might be suggesting, then for my game, who is right?

Quote
In any event, it starts becoming too advantageous to automate stuff your server should be doing for everyone.


Should be… in YOUR opinion. See above.



Rarva.Riendf said:
But removing the queue because you did not add a way to kill it (basic rom as a ! command that repeat the last command, in mine !! will just kill the queue, and resume will allow to well obviously resume it) is pretty much WTF


The WTF is pretty easy to answer: It was a better solution for what we wanted with the game, the specific and particular systems, and it meshes well with the gameplay experience we are after.

Quote
The fact that your players well received it pretty much say they are too dumb to use a client.


And is insulting my entire playerbase because they enjoy something different than you really necessary? Would it be fair to say that MUSH players are dumb because they don't like games with combat? Get off your high horse just because someone thinks differently than you or enjoys their game playing different than you. That's really a wholly unnecessary attack. Or are you "too dumb" to realize that?

Seriously.



Lyanic said:
P.S. HK, you're aware that I used to play you game. I did have an extensive set of triggers. I also know someone who played (might still play, not sure), and had a very nice Mage-bot for automated, optimal use of your fantastic magic system. Take that as you will….


As you quoted KaVir, there are a segment of players that will attempt to automate anything or everything.

I think that anyone trying to develop or making significant design decisions based on trying to account for what the clients can do is doing themselves and their players a disservice, because when trying to prevent certain behavior that's possible for someone who is determined to automate or script around your intended game experience, you're going to lessen that same experience for the people who are actually playing the game.

As far as the the Mage-bot? I'm sure for the more simple mobs and such, it would do fine, but I would also bet that against a live player who knows the magic system well, it would get shredded. Between elemental fields, elemental strengths/weaknesses of the parties involved, counter spells, etc. that it wouldn't stand up to the human element.


But overall, if someone wants to go to the trouble of writing scripts or configuring their client to support a command queue? More power to them, I don't really care. As far as it creating a higher barrier of entry for playing the game? I don't think so. It might create a higher barrier of entry to have a command queue, but it's been my experience that most of the players don't really care about that, particularly in the face of the vast improvement the wait-state system has been over what was there.

I've always felt and still do that the lag state for commands was a primitive and early solution for solving the issue the of cooldown for skill use, not an intended "command queue" feature, and not this crucial feature that others are trying to make it out to be.
25 Jul, 2012, Hades_Kane wrote in the 25th comment:
Votes: 0
KaVir said:
Lyanic said:
So much this. Power players will write trigers for anything and everything if it gives even the tiniest advantage, or if they're just too lazy to bother paying attention to something. There's even the breed of player who writes triggers for no other reason than to see if he/she can.

Or because they enjoy it. I remember talking to one of my players who wrote a lot of bots. For him, the biggest attraction of my mud was that there were no rules against botting.


We've had those types, too. Not necessarily looking to automate everything, but have written massive and numerous scripts where it seemed like most things they did in the game was influenced by something they personally scripted. Much of it was information gathering, using the various methods to stat or identify mobs and objects in the game, and building a database of all the information they gathered, and figuring out behind the scenes calculations and numbers. To the best of my knowledge, they never did what I consider botting, and never just had their characters automated without them playing.

I always find it interesting when players use the power to script their experiences in that way.
25 Jul, 2012, Rarva.Riendf wrote in the 26th comment:
Votes: 0
Quote
And is insulting my entire playerbase because they enjoy something different than you really necessary?

Sorry but being happy about removing a functionality for the sake of removing it (as stated a single kill queue command render all your arguments against it moot), and moreover a functionality that can be remade client side anyway, but at your client cost (against for no other reason since the functionaly was there to begin with), I do not see any other adjective.

[edit]really I was wrong, I see another adjective: Apple users. Your call to call it an insult :).
25 Jul, 2012, Rarva.Riendf wrote in the 27th comment:
Votes: 0
KaVir said:
Rarva.Riendf said:
Triggers is to repeat uninteresting thing to be done.

It doesn't matter how interesting something is, if triggers give an advantage, players will use them.

Well I like to think that the interesting thing are the one where triggering will end up putting you in trouble more than anything, and when relying on trigger will make you an average player that never does epic thing at all. (relying on trigger usually means rational/data statistic analyses decisions), otherwise, well you dont really need triggers to act like a chaotic berseker.
25 Jul, 2012, Lyanic wrote in the 28th comment:
Votes: 0
Hades Kane said:
I think that anyone trying to develop or making significant design decisions based on trying to account for what the clients can do is doing themselves and their players a disservice, because when trying to prevent certain behavior that's possible for someone who is determined to automate or script around your intended game experience, you're going to lessen that same experience for the people who are actually playing the game.

Actually, it has already been established in this thread a number of reasons why you do yourself and your players a disservice by NOT taking into account what the clients can do. Can you give an example to support your position? Also, in what way does having a well thought out command queue lessen the game experience for anyone? Please explain.
26 Jul, 2012, Ssolvarain wrote in the 29th comment:
Votes: 0
Why should you automatically assume that every player is interested in typing out complicated commands to simply play a game? Just because you would doesn't establish a fact.

Most of the players I know prefer simple clients and simple commands. I get by with GMUD, and there's no reason why your game shouldn't support a client that simple.
26 Jul, 2012, Lyanic wrote in the 30th comment:
Votes: 0
Ssolvarain said:
Why should you automatically assume that every player is interested in typing out complicated commands to simply play a game? Just because you would doesn't establish a fact.

Most of the players I know prefer simple clients and simple commands. I get by with GMUD, and there's no reason why your game shouldn't support a client that simple.

I'm extremely perplexed by this post. I would like to inquire the following:

A) Who and what is this in response to?
B) What point are you trying to make?
C) Have you read the thread?
26 Jul, 2012, quixadhal wrote in the 31st comment:
Votes: 0
As far as botting goes… I find writing a bot to see how well I can make it play the game is often more fun than actually playing the game. It's as simple as that. No motive to cheat, to make in-game gold by selling stuff, etc… just to see if I can code something that will do better at playing than the other humans. :)
26 Jul, 2012, Runter wrote in the 32nd comment:
Votes: 0
Quote
Quote:
In any event, it starts becoming too advantageous to automate stuff your server should be doing for everyone.


Should be… in YOUR opinion. See above.


Well, the statement is self supporting. You should be doing it for everyone if it starts becoming too advantageous to automate stuff. So the core of your disagreement, which you haven't really addressed, is that you appear to be saying it's not too advantageous to automate this stuff.

And anecdotes about what a player base likes isn't useful when talking to developers on a forum mostly for developers trying to get to the bottom of good design philosophy. Especially when you have no way of knowing how many people tried your game and didn't like it, or how your players would feel about a variation of your system that resolves the issues that's being brought up. This is exactly why it isn't useful information. It doesn't tell us if it's a net gain just because the people who liked your game enough to stick around give it a seal of approval. To get a hint at that you'd need a more unbiased sample, I.E. the people on this forum that don't play your game.
26 Jul, 2012, Rarva.Riendf wrote in the 33rd comment:
Votes: 0
If a game allow me to kick and bash, and if I know my next two actions will be kick and bash, I want to be able to know bash is exectuted at the perfect time, and not having to spam it for that.
And do not tell me making an alias allow you to do that because taht would be pretty stupid.
Because one:it means you would have to do evey goddam combo that can happen in fight. (basically impossible)
Or ooh wait, generate aliases on the fly in you client then use the alias command you just created.

Next remove aliases in game while you are at it…so people are forced to type every command line so they are more 'active', it is the same logic behind.
26 Jul, 2012, Hades_Kane wrote in the 34th comment:
Votes: 0
Rarva.Riendf said:
Sorry but being happy about removing a functionality for the sake of removing it (as stated a single kill queue command render all your arguments against it moot), and moreover a functionality that can be remade client side anyway, but at your client cost (against for no other reason since the functionaly was there to begin with), I do not see any other adjective.


It wasn't removed for "the sake of removing it". It was removed because there was a better solution to skill cooldowns than using a lag timer, because it makes the game play closer to what we intended, and creates a simpler interface for the players.


Lyanic said:
Hades Kane said:
I think that anyone trying to develop or making significant design decisions based on trying to account for what the clients can do is doing themselves and their players a disservice, because when trying to prevent certain behavior that's possible for someone who is determined to automate or script around your intended game experience, you're going to lessen that same experience for the people who are actually playing the game.

Actually, it has already been established in this thread a number of reasons why you do yourself and your players a disservice by NOT taking into account what the clients can do. Can you give an example to support your position? Also, in what way does having a well thought out command queue lessen the game experience for anyone? Please explain.


There's been plenty of examples of people discussing trying to work around people botting their games by adding all sorts of nonsense, from randomly timed and generated quizzes, captcha like pictures, etc. If I were legitimately playing a game and every 10 or 20 minutes I had to interrupt what I'm going in order to address a bot detection measure, I would leave. That's a prime example, right there, and as I said, there's been plenty of discussions here and elsewhere of people who have added such measures. Just because that other's guy client is capable of automating his character to get around a MUD's systems doesn't mean my game experience should be impacted by that.

As far as what I innately have against a command queue, to repeat, I feel like it lends itself toward lazy play. I'll touch on this a bit more specifically in a reply to someone else.


Lyanic said:
Ssolvarain said:
Why should you automatically assume that every player is interested in typing out complicated commands to simply play a game? Just because you would doesn't establish a fact.

Most of the players I know prefer simple clients and simple commands. I get by with GMUD, and there's no reason why your game shouldn't support a client that simple.

I'm extremely perplexed by this post. I would like to inquire the following:

A) Who and what is this in response to?
B) What point are you trying to make?
C) Have you read the thread?


I think what he's getting at is a "well thought out command queue" system also can just as easily read "a complicated system to juggle commands". Someone earlier said the "simplest" solution to the OP's problem was adding in command queue interruption or exclusion, etc. I disagree. The simplest solution, at least from the player's end of things (which again, I stress should be considered when developing), is to disallow the input of an invalid command. "Bash -> You can't do that." is pretty straight forward.


Runter said:
And anecdotes about what a player base likes isn't useful when talking to developers on a forum mostly for developers trying to get to the bottom of good design philosophy. Especially when you have no way of knowing how many people tried your game and didn't like it, or how your players would feel about a variation of your system that resolves the issues that's being brought up. This is exactly why it isn't useful information. It doesn't tell us if it's a net gain just because the people who liked your game enough to stick around give it a seal of approval. To get a hint at that you'd need a more unbiased sample, I.E. the people on this forum that don't play your game.


I still maintain this is a flaw in logic. Regardless of what type of forum we are on, and regardless of "good design philosophy", you could have the best designed command structure ever conceived, but if the players don't like it, or if a simpler solution that meets players' needs and expectations will be just as well and good, then what have you accomplished other than being able to give yourself a pat on the back? A pat on the back on an empty MUD really isn't really something I'm all that interested in.

Besides, the OP asked for suggestions on how to address being able to communicate while waiting on the cooldown for skills, and you guys offered one solution, I offered up a different opinion.

Also, I'm far less concerned about an "unbiased sample" from people that don't play my game than the people who do. The people on this forum aren't who I'm making End of Time for, I'm making End of Time for the people who do play the game, and if my design decisions please them, myself, and our staff, then that's really all I care about. Also, no one here is unbiased, because one thing I've learned in my years within this community is that everyone has very strong opinions on exactly how things should be done, and any deviation from that is "wrong". That's one reason why there is so little success in collaboration within this community.



Rarva.Riendf said:
If a game allow me to kick and bash, and if I know my next two actions will be kick and bash, I want to be able to know bash is exectuted at the perfect time, and not having to spam it for that.


This is at the heart of why I don't like command queues. Should you be able to queue up your next uppercut and roundhouse kick in a Mortal Kombat game since you know those are going to be your next moves and you want to execute them at the perfect time?

Why should a game hold your hand and allow you to execute commands with perfect timing? When I keep saying that command queues lend toward lazy play, this is exactly the mentality I'm speaking of. We have a handful of skills that rely on timing (with some randomization toward the proper timing), should we not have those because players may want to have the ability to naturally and unfailingly execute the commands at the perfect time?

No.

You want a game that allows you to execute every command exactly when you need to? Go find a different game. Plenty of people have found our system to be perfectly acceptable, so much in fact that we've had more luck with player retention in development than many other games that are open have had.

Quote
And do not tell me making an alias allow you to do that because taht would be pretty stupid.
Because one:it means you would have to do evey goddam combo that can happen in fight. (basically impossible)
Or ooh wait, generate aliases on the fly in you client then use the alias command you just created.

Next remove aliases in game while you are at it…so people are forced to type every command line so they are more 'active', it is the same logic behind.


Lyanic is a good example of someone who can disagree with someone on this board and keep it civil. I replied to the last bit of your stuff, but until you can drop the hostile and condescending tone, I'll be done with our exchanges.
26 Jul, 2012, KaVir wrote in the 35th comment:
Votes: 0
Hades_Kane said:
Why should a game hold your hand and allow you to execute commands with perfect timing?

Because difficulty should be determined by the gameplay, not the interface.
26 Jul, 2012, quixadhal wrote in the 36th comment:
Votes: 0
Good example of this from a discussion this morning: Doors.

In the original DikuMUD paradigm, a door is an object which sits between two rooms, and exists in either an open or closed state. The door can often also be locked or unlocked, and a variety of other properties have been added to support things like bashproof, pickproof, stuck, ajar, etc…

That's all well and good, but the user interface to these doors is accomplished by the mandatory use of the open/close verbs, and optionally the unlock/lock verbs. The word mandatory is chosen with care. In the classic DikuMUD, if you attempt to go west, and there is a closed door there, you get an error message and have to then type "open west door", followed by "west". If the door was also locked, the open command will fail, requiring you to then do "unlock west door", "open west door", "west".

From a logical standpoint, this makes sense and doesn't seem like a bad thing. However, consider how you (the human) respond to doors in your daily real-world life. Do you approach every door with the conscious thought of "unlock door, open door, go through door"? I know I don't. I just walk through the door, and if it's closed, my subconscious handles opening it. If it's something I expected to be locked (like my house door), it's almost pure subconscious that gets out the key and unlocks it too. I don't have to put forth extra effort to make it work.

So, why do you need to do that in a game? Surely, unless you're incapacitated or drunk or in a panic state, just typing "west" should automatically open the door AND (if you have the key) unlock it? Why make the user type it out? Why take their attention away from the gameplay, just for the sake of a tedius mechanic that could easily be automated?

Sure, if the door is stuck, the automated thing should fail and then the user will need to figure out, do I push or pull the door? Do I need to bash it? Is it barred? But that's the exception to the rule… most doors are just… doors.

The same thing applies to command queues. It makes sense for in-game activities to take time, and it makes sense to be able to enter at least a few of them in sequence, knowing they'll go off when your character is able to perform them. Likewise, it makes NO sense for non-gameplay commands to have any delay. Checking your inventory, chatting on an OOC channel, getting the who list… those are all meta-elements that you (the player) need to do, not your character.

All the folks arguing against command queues seem to think they make people lazy. Well, newsflash… people play games TO HAVE FUN! They don't *WANT* to have to work, just for the sake of making it do what they want it to do…. Put the challenge in the gameplay, not the user interface.
26 Jul, 2012, Runter wrote in the 37th comment:
Votes: 0
I'll list every point you've made:

1. It makes people pay attention/more active in inputting commands on time because they can't queue up skills.
2. It eliminates players accidentally queuing up too much and being stuck.
3. Positive feedback on the system (in your mind only) has proven that no improvements are to be made.

I'll list every counter point:

1. It gives an unfair advantage to people who know even minimal client scripting. It makes using a mud client practically required You seem to think zmud is a minimum entry level, but that's an advanced mud client. This is exactly what KaVir was talking about with IRE games that require heavy automation just to enjoy the game.

2. While I agree this happens to new players, there's plenty of people suggesting variations on your system that simply address other concerns without throwing the baby out with the bath water. You simply don't care to entertain that your system could possibly be improved at all. I suggested limiting the queue to 1. This solves a lot of problems and doesn't let players queue up too much. Other solutions suggested include a way to clear the queue, and commands that ignore the queue completely.

3. Frankly, the anecdotes used to claim your system cannot be improved because of some 3rd party not even in this discussion said it's the best is a logical fallacy on more than one level. It's a blatant appeal to authority. How could a reasonable debate ever take place if every person here said something like "Lots of people tell me my system is better, therefore it's better." Even beyond that, you can't even prove that same people wouldn't say the same thing about a variation on the system. Actually this is like saying "I don't know why it's better, I can't explain why it's better, but you guys just trust me." And if we're going to measure the quality of a feature by a small segment of the mud community that plays your game, I guess we could just as easily ask KaVir's playerbase what they prefer, or IREs what they prefer. They're playing your game because they prefer it. That's not just correlative, but it doesn't mean they wouldn't also like something else. Or that people not playing your game wouldn't like something else.
26 Jul, 2012, Hades_Kane wrote in the 38th comment:
Votes: 0
1. People enjoy it fine without having to script the game. A command queue, is in your guys' mind a necessity (which I still disagree with), but the game plays perfectly well without one. I doubt there is a game out there that client scripting wouldn't lend an "unfair" advantage to, but I repeat, I don't feel it is wise to base your development decisions when trying to account for what people's clients can do. You spend all your time trying to make an unbottable, unscriptable game, and well, I'd wager you make a game that's also not terribly fun to play. Likewise, I really don't think with the way our game is setup that someone scripting their fights to have the briefest of quicker response time to being able to act again would really have that much advantage over someone not using scripts.

2. A single command queue seems reasonable, I'll give you that, but on the same hand, other than getting "instant command", I don't see the point.

The comments about gameplay/interface… I would consider the input for combos on many types of games (including the blitz abilities that Sabin wields in Final Fantasy 6 [a significant influence in our theme]) to be a matter of interface. I think that input/interface error on the part of the user/player to be perfectly valid. That's a significant basis for fighting games altogether, and numerous numerous mini games on console RPGs (from button mashing, to slot machine style selections, to button combinations).

3. Any system could be improved, and I'm not saying mine couldn't. What I am saying is that the people who play the game and staff on it find what we have in place to be both an improvement over what was there, and a perfectly acceptable solution and gameplay mechanic. Any system could be "improved" and every person is going to prefer something different. I don't like command queues and outside of this thread, there hasn't been any sort of call or even questions about there not being one.

Oh, and for the record, you do have to type "unlock west" "open west" "west" to get by exits in my game, more of the tedium "making sense" thing. I think there needs to be a balance between some bits of tedium and automation in a game for it to be balanced in that regard. Just as how we've removed the need for eating/drinking and lights in our game because that seemed to be an interference to the enjoyment or immersion of a game, others expand upon and make more of those systems, including things like potential death for not eating/drinking/sleeping enough. Different strokes, really. Sure, these games are meant for fun, but I think that when you do too much hand holding for the players (from things like automatic eating/drinking, auto unlock/open on a movement command), the game suffers overall. Maybe my mentality is stuck in 90s kinda way, and maybe influenced from the grindish 90s console RPGs that I grew up on and our game is heavily influenced by, but there is some level of tedium I think is necessary.


One thing that might be worth mentioning is there actually is a MUD 'delay' command implemented that allows people to put commands on a delay, done right it could be used as a defacto command queue if a player so desired as more than one command can be set to delay, but it doesn't really see much use and didn't come to mind in earlier discussion, mostly because we use in our programs a lot (in place of the normal 'mob delay' command). Concerns about needing client scripting to emulate or work out a command queue may would be alleviated by the system, although it still wouldn't be much use in the "immediate command" after a wait-state is over (which is fine by me, again, I don't like the concept of providing immediate firing of commands MUD-side).
26 Jul, 2012, Rarva.Riendf wrote in the 39th comment:
Votes: 0
Quote
It wasn't removed for "the sake of removing it". It was removed because there was a better solution to skill cooldowns than using a lag timer,

A command queue has nothing to do whatsover with any method you use to put time between differents commands. Nothing.

Quote
This is at the heart of why I don't like command queues. Should you be able to queue up your next uppercut and roundhouse kick in a Mortal Kombat game since you know those are going to be your next moves and you want to execute them at the perfect time?
Why should a game hold your hand and allow you to execute commands with perfect timing?


Sorry I did not think your game was a beat them up or a fps, guess I was wrong. (and btw nowadays beat them up allow macros as well because it should be a game about reflexes to the visual input, not a dexterity game needing you to be a squid to compete….)


Quote
unlock door, open door, go through door

Case in point, I made so you can configure how you react to door: Be blocked by them, open them automatically, and unlock them automatically.
(Because sometimes you do not want to use keys automatically when a door locked right behind you and you are exploring or something.) or sometimes you actually want to be blocked by a door if it is closed (cause sometimes it means that an aggro is behind it)
27 Jul, 2012, Lyanic wrote in the 40th comment:
Votes: 0
Hades Kane said:
There's been plenty of examples of people discussing trying to work around people botting their games by adding all sorts of nonsense, from randomly timed and generated quizzes, captcha like pictures, etc. If I were legitimately playing a game and every 10 or 20 minutes I had to interrupt what I'm going in order to address a bot detection measure, I would leave. That's a prime example, right there

I don't think that's really in line with what's being discussed here. We're talking about design decisions that reduce the utility of botting, not eliminating or detecting it. Trying to eliminate or detect botting is a fool's errand, in my opinion. Any system can be circumvented, and it takes less effort for the client to do so than was put into the development of the server-side countermeasure. The only logical steps to take are creating disincentives to botting and narrowing the advantage between botters and non-botters, to prevent disenfranchisement of the latter category of players. What most everyone in this thread is trying to bring to your attention is that the system you have devised does the opposite of this.

Hades Kane said:
We have a handful of skills that rely on timing (with some randomization toward the proper timing), should we not have those because players may want to have the ability to naturally and unfailingly execute the commands at the perfect time?

I can see how this design decision would strengthen the tie to the decision against command queues. In fact, I can't really think of a way to marry timing based attacks with a command queue system. However, I will also say that timing based attacks disenfranchise the segment of players who are slow typists or have slow internet connections. Perhaps it's a small enough segment that you do not concern yourself with them.

Hades Kane said:
I don't like command queues

That's really all you have to say in the end, though. You are the developer of the game, so invariably, your personal preferences and biases will factor into the design. If you don't want command queues, you won't have a command queue, and you will attract a pool of players who also don't like command queues, or who have no real preference on the matter.

Hades Kane said:
Lyanic is a good example of someone who can disagree with someone on this board and keep it civil.

Thank you. Although, just recently, a certain MU* community person was making quite contrary statements about me.

Hades Kane said:
we've had more luck with player retention in development than many other games that are open have had.

*twitches* Not going to say it…said…I…would…drop…it…
20.0/46