06 Mar, 2012, plamzi wrote in the 61st comment:
Votes: 0
I think people have been talking past each other quite a bit here. That's normal when not every comment is made with the awareness that what constitutes very poor game design for one game can be golden in another. This is true^1000 for decisions concerning game automation. The key to unlocking all confusion is the question 'Who is my target audience, and what do I hope to accomplish for them?' Consider:

Game A: Mobile simulation game targeting people on the go. The ideal player is someone who logs in multiple times a day, with the average session being 20 sec to 2 min. The goal is to make players "feel like" they've been progressing in the game all day. The design is a simulation environment for bots who occasionally take human input. You want to appeal to very casual players who just want to check back and see that they've gained this many points in the meantime. You also want to hook people who care about the best strategy, but you can't reward them to a point where they can 'ruin the fun' of casual players or overload your servers. That's why you put stoppers to extended human sessions (such as, it's going to take an hour for your next production cycle unless you pay us, or your plants will die if you over-water them, etc.) To ensure that no-one feels out-shined by non-casual players, you also put brakes on human-to-human interaction, which may scream wrong for an online game, but then again, your designing the whole game for bots screamed wrong also, yet it wasn't.

Game B: An RPI MUD where players can only advance by engaging in meaningful interactions with other human players over extended periods of time (approaching quasi-realtime). All actions in the game (even killing etc.) are intended to drive RP (just so you can tell a story about it) and are not intended to be 'exploited' for direct advancement. Anytime anyone finds a bottable aspect in your game, down to the simplest, smallest edge via automation, this is extremely unfair to people who have to put in real time, thought, and creativity. You have to not only purge the gameplay of any bottable angles, you also have to police your human players heavily to check if they don't engage in multiplay or 'conspiratorial co-botting', scanning user input patterns for signs of automation. If your goal is to have a human seated behind the keyboard at all times, even the simplest macros and triggers can become suspect.

Most online games sit somewhere in the middle. But for all of them, the same rule of thumb applies. If whatever it is you do (or don't do) about botting helps attract the kind of player you want, then what you're doing is good, and don't let anyone tell you otherwise.
06 Mar, 2012, Deimos wrote in the 62nd comment:
Votes: 0
@KaVir: You didn't really "cover" it. :-p You said that the bots *might* make use of special character skills. On the other hand they might not. They might even intentionally not do this, for exactly that reason. And even if they do, the bot is still useful for any character that does have those skills. And regardless of all of this, it's not terribly difficult to incorporate comparable or alternative skills into the bot.

One more thing to think about is that each modification only ever needs to be done once, so it's not at all impractical.
07 Mar, 2012, KaVir wrote in the 63rd comment:
Votes: 0
As I said already, there is no "silver bullet". This isn't some simple design problem that can be addressed once and then forgotten, it's something that can impact your design on many different levels, and needs to be constantly kept in mind whenever you add a new feature.

If you're expecting some simple generic solution* that'll automagically address every one of your botting woes without impacting the rest of the design, then I'm afraid you're going to be severely disappointed.

* Other than some arbitrary rules and the Avenging Fist of Runter.
07 Mar, 2012, Deimos wrote in the 64th comment:
Votes: 0
I'm not looking for anything, actually. I know the discussion sort of spiraled off into me trying to convince you that it's actually very hard to limit the usefulness of botting, but my original point was the same as the one you just made. Botting can't be mitigated simply through changing game mechanics to be "less bottable." Rather, your game has to be fun enough that players don't *want* to bot.

Obviously everyone finds different things fun, so the only way to please everyone all the time is to strive to make the game have as many options for the different facets as possible, all comparable in effort-to-rewards ratios. If I dislike killing things, then don't have killing things as your only method of experience gaining or I'm likely going to bot kills. That kind of thing.
07 Mar, 2012, quixadhal wrote in the 65th comment:
Votes: 0
Deimos said:
Rather, your game has to be fun enough that players don't *want* to bot.


That's what I was trying to say. MOST people bot because they find part of the game boring, and want to get to the "endgame" without having to spend all the time to get there. A few don't actually care about the game at all, and just want to "finish" it as another notch in their belt. Some want to bot to try and profit by selling resources/goods to folks who want them but don't want to go to the effort of harvesting/making/questing for them.

It reminds me of an old quote from the Oracle CEO (Larry Ellison), when he was being asked about software piracy. "We're not overly concerned about it, because those people are not our customers." He elaborated that their customers didn't just buy a copy of their software and be done with it.. they bought ongoing support contracts, and a steady stream of upgrades as needed. Anyone who pirated it would be doing without all that, and likewise wouldn't have paid for it anyways.

That's kindof how I feel about botting. Focus your energy on making a game people WANT to play. Don't worry about the handful who won't want to spend any time playing no matter what you do, as they won't like your game anyways. Squish the gold sellers or folks who are trying to destroy your economy if they show up, although in a text MUD, I wouldn't hold my breath waiting for them. :)
07 Mar, 2012, Runter wrote in the 66th comment:
Votes: 0
Quote
It reminds me of an old quote from the Oracle CEO (Larry Ellison), when he was being asked about software piracy. "We're not overly concerned about it, because those people are not our customers."


Not really an apt analogy. It would be more like spending your life (not money) collecting baseball cards only to find the company that makes them doesn't mind if people copy and reproduce, and trade them. Botting has this effect on markets in virtual worlds. And your customers (the people who drink your tea) aren't going to appreciate it once they realize how much time they spent to advance/collect/farm/insert word for why someone bots, while other more prosperous players earned it in the "non-customer" way. It's really just comparing social apples to oranges.

Also I disagree that if the game is something someone wants to play they won't bot. That's precisely why they'll bot. They may control a character often, and still have bots running. Or bot while they sleep. If they're really into the game and botting leads to advantages it only makes sense if they have the ability and you allow such a thing. The real question is how do you curtail the unmitigated benefits of botting. Not really how do you convince people it's more fun not to bot. If the returns on botting are diminished other players won't feel so bad when they see bots. If botting provides not just equal, but superior benefits the inverse will be true. People will be even more appalled by the state of the playerbase.
07 Mar, 2012, Hades_Kane wrote in the 67th comment:
Votes: 0
Deimos said:
@Hades: And players don't just make a trigger for "You aren't ready yet" to resend the command (spamming your server in the process)?


Have yet to see that.

Generally speaking, when people bot, they are doing it for skill gains. A number of our skills in the game are learned by maxing another skill, or a combination of skills. As an example, all of our elemental magic is tier based. When you get fireball to 100%, you learn combustion at 60%. When combustion is maxed at 100%, you learn Flare, etc. Each subsequent spell that you learn is generally more powerful and cost more mana, but is limited in some form, such as to the extent that you can 'widen' the spell for hitting multiple targets and such. Another example is when you get both backstab and sneak to 100%, you learn Shadow Step, which allows you to attempt to begin a backstab from an adjacent room.

Many of our skills work in this method, with some opening up entire skill trees and such. For this reason, many people will choose to focus almost entirely on skill training early on in order to maximize the power of their character. Additionally, skill usage and skill improvement give experience points as well, so this is setup as an alternate method of leveling without having to kill mobs. This is the biggest thing we run against people botting, and usually it is based on the "You are free to act again" message. While this system is easily bottable, it's also easily discoverable because if you do a personal echo to someone that isn't responding for several minutes for "You are free to act again" about 5 times in a rapid succession and they subsequently attempt to sneak/vis in rapid succession 5 times, it's quite obvious they are botting.

But the vast majority of our players don't idle bot. If someone has these triggers setup but are still chatting on the MUD or otherwise at their window and being responsive, then I don't have a problem with that.
07 Mar, 2012, Deimos wrote in the 68th comment:
Votes: 0
I guess I do have a problem with that, though, as it can anger people who don't do it because they deem it unfair. I don't think whether or not that anger is warranted is relevant. In the end, we want people to play out games, and if a sizable number of players are significantly angry, you'rr likely to lose players. And that's no good, obviously.

OTOH, maybe the type of player who would get angry about that is not the type you want playing your game to begin with. So, I suppose it would be a non-issue in that case. Personally, I want to appeal ti as broad a base as possible, since it's extremely hard to get a MUD started.
07 Mar, 2012, plamzi wrote in the 69th comment:
Votes: 0
Like Deimos, I want to appeal to the broadest possible base. One approach that I believe is working very well is to lower the bar on certain forms of automation for everyone (minimizing the advantage of power users with advanced client configuration skills) and even to make certain automations part of normal gameplay/combat.

For instance, we have server-side macros, triggers, and timers that are all pretty straightforward and convenient to use. We have server-side command repeat support, so you can configure a macro/trigger, or even just type "40 bash" and go take a short break. If you want to revise your strategy, you do "stop" to "…stop trying to do what you intended." and can then queue up another skill or combo. All these server features are designed so power players and normal players likewise can have fun semi-botting over any repetitive parts without the former going overboard. I'm planning to go a bit further and offer an "if" command that will allow players to run some checks in natural language and if passed, execute the rest of the command, e. g. "if I'm fighting undead cast 'turn undead'". The advantage of having this in command form is that it can be used in triggers/macros by people who know nothing about scripting, yet want to be able to "train" their character to respond in a certain way to certain stimuli, freeing them to make more high-level decisions.

All my changes concerning automation are designed to give people the ability to "script while playing," to continuously configure their character's behavior patterns, and to have a lot more fun doing it than if they had to rack their brain over how to make their advanced client recognize undead targets. These, and a host of other usability features (having to do with mapping and exploration, etc), I believe have significantly closed the gap between power players and those who just want to do everything manually. If the latter don't take advantage of certain automation features, they can't reasonably complain that others do–the features are equally available to everyone and sufficiently simple to master.
07 Mar, 2012, Rarva.Riendf wrote in the 70th comment:
Votes: 0
plamzi said:
If the latter don't take advantage of certain automation features, they can't reasonably complain that others do–the features are equally available to everyone and sufficiently simple to master.

Yeah I chose this path as well, I have loop commands resume a queue filling it etc.
It is better than to rely on a client that people may/may not have access to anyway when they want to play.
It is also way easier to help people use those commands than to know of a gazillion different clients (well 3 or 4 mostly) where is the option to do so in theirs.
it is a win win situation. (Except for those that think typing is the fun part of the game.)

As an example I have a spellup command that launch every spellup you can have, but only the one you are not affected with, you can also use it on a friend it will only use the one he is not affected with, an only the one you can cast on others.
You can also modify the list so you can change the order and even wich spell there is in it.

Kill the use for any scripting for this.
11 Mar, 2012, Runter wrote in the 71st comment:
Votes: 0
Quote
it is a win win situation. (Except for those that think typing is the fun part of the game.)


It's a win in some ways. A lose in others. We should be careful about making these types of statements when we didn't present any of the down side. So I'll do that for you now.

  • It's time spent developing features that intersect with what almost all clients can already do.

  • It's additional code to maintain that needs test coverage.

  • Users will need to learn your system vs copying and pasting from other muds or examples on client dev sites.

  • You may be surprised to find people still use their client side scripts because they want to modify ones from other muds.

  • It's extra load for your server. Some small games will care about this, but for successful games this would be a very unreasonable approach for almost all.

  • And most importantly, it may add to automation rather than lowering it.


If the core problem was automation of tasks, maybe it's more important to rethink your mechanics than waving a white flag in the name of fairness. If players are having to write obligatory scripts to remove mindless repetitive tasks from your game, it may be fair, but it's still not fun.
11 Mar, 2012, Rarva.Riendf wrote in the 72nd comment:
Votes: 0
Quote
  • It's time spent developing features that intersect with what almost all clients can already do.

  • I agree, but so I will be more precise in what I think a mud should provide. A spellup as I did is of course manageable in a client, but it takes lots of time to code on a client as you have to perfectly now evey spell skill from all classes to do so, and even, you dont have the affect state of someone else so you would have to ask 'do you have bless' before casting it.


    Quote
  • It's additional code to maintain that needs test coverage.

  • That for sure, but is is also less human time to waste on explanations on 'no there is nothing like that try to do it in your client' and 'sorry I do not know how to do that in your client'

    Quote
  • Users will need to learn your system vs copying and pasting from other muds or examples on client dev sites.

  • That I disagree, providing something does not mean you remove that possibility

    Quote
  • You may be surprised to find people still use their client side scripts because they want to modify ones from other muds.

  • not at all but see above

    Quote
  • It's extra load for your server. Some small games will care about this, but for successful games this would be a very unreasonable approach for almost all.

  • Could be, but that is up to you to limit yourself, if not possible just do not do it.

    Quote
  • And most importantly, it may add to automation rather than lowering it.

  • Not having some automation will just make peope code/complain/ask for it a little more, not limit them in any way. (and even make some leave)
    Not having stuff like autosacrificing, autolooting etc is making the game a typing skill game, again some people may like it…but I do not know a lot of people in that case.

    Quote
    If the core problem was automation of tasks, maybe it's more important to rethink your mechanics than waving a white flag in the name of fairness. If players are having to write obligatory scripts to remove mindless repetitive tasks from your game, it may be fair, but it's still not fun.

    I agree, but am not thinking about automation of any tasks that could be. More about automation of some stuff you may or may not want to be automatized depending on context.
    Something like autodoor, when running to a waypoint you set, you would want to open all the door in the way automatically.
    In some place you do not know it may not be a great idea.
    Stuff like that.
    Sure your client can do that, but you would have to configure your mapper, and that is not an easy task for most people.
    Most thing like that have received a nice welcome from the players I had/have, as most use a client but are not coders.
    The other can still use their client and their macro etc, I did not remove any possibilities for them.
    60.0/72