29 Jan, 2013, Splork wrote in the 21st comment:
Votes: 0
We silently trans them to a room, such as jail, and watch their scripts continue to run. Its amazing how advanced the scripts are but as long as you don't give them a reason to return to their keyboards ( such as using tell, say, etc ), its usually quite easy to tell.
29 Jan, 2013, Telgar wrote in the 22nd comment:
Votes: 0
Splork said:
We silently trans them to a room, such as jail, and watch their scripts continue to run. Its amazing how advanced the scripts are but as long as you don't give them a reason to return to their keyboards ( such as using tell, say, etc ), its usually quite easy to tell.


I still don't think this works. I recall playing with someone who I later found out was botting. I could not tell at the time. They would instantly notice if you transferred them because they were actively multi-playing both characters over separate internet connections. Your method would only catch passive botters (and I agree it's easy to catch passive botters with that technique).

I was trying to think of a way to catch that case, and I don't think I know of one. Even mild versions of the "ask for personal details" (favorite flavor of ice cream, pizza topping or whatever doesn't identify you personally) are error prone and as Runter points out, it isn't appropriate to ask for specific information that makes them think you are targetting them for a credit scam. Also, I just looked in my logs and found out my client does in fact log my responses. So this technique is DOA anyway.

Maybe, if they can pass a simultaneous Turing test on two different internet connections, they should be allowed to bot, since they are effectively role playing two characters at the same time… I wouldn't like it but there doesn't seem to be any way to prove it without crossing the line.

Would asking them to pass an e-mail address challenge be acceptable? Then mail them a passcode. If they don't have two separate e-mail identities up front, they would be forced to confess. It's pretty easy to tell if a major ISP is down so claims their account is broken wouldn't work too well, and if they can't get back to you with the passcode in 5 minutes, you know something is wrong.
29 Jan, 2013, quixadhal wrote in the 23rd comment:
Votes: 0
Sargonas said:
Thanks for all of the responses, I used a variation on Plamzi's idea of the simple countdown, I waited until I suspected they were botting and then I ran a global quest, that was !group, so it forced them to go in separate directions locating items at the same time, sort of a scavenger hunt quest, it just about convinced me they were legit, since the quest is different for each competitor and they competed at the same time.


I love this. Bravo!

While it's not a perfect solution, because a group of players may simply NOT WANT to do your quests, I think most players do enjoy spontaneous events, and are probably likely to give it a shot.

The thing to remember is that it's not at all unusual for friends or family (especially those who live together), to share some of the same recreation. In those cases, they're coming from the same IP address, they probably don't use in-game chat much since they talk to each other by yelling across the room, and quite often one will be auto-following the other (if possible), or at least tending to move together pretty tightly.

My general attitude towards bots is to see if they're disruptive. If not, it's not really a problem. Nobody wants a bot to clear-cut all the harvestable things from a zone, but I've also seen players good enough to do this and seem like a bot. Even in graphical games. A friend of mine used to get kicked off Diablo 2 every few weeks because the auto-bot detection code thought he was botting. He wasn't (I watched him), but he knew the game and the maps so well he moved with the same speed and accuracy of the bots.
29 Jan, 2013, Telgar wrote in the 24th comment:
Votes: 0
There's another feature that's very underutilized, at least in the MUDs I have played, but has at least some support in Diku derived sources. You can mark rooms as a "TUNNEL". These rooms (in theory) only allow one player in them at a time. I've never seen an actual implementation in code however.

It's really hard to multi-play in such a room, and impossible to lead a group through without going single file, one at a time. While you could bypass this with a trigger, it would need to be a trigger that causes the other player to move.

If you outlaw such triggers (and arguably, you could, there is no reason one player should actually move another player), then it would be pretty easy to establish botting. If a player insists they are not violating the rules, but is obviously using a movement trigger, wouldn't it be a shame if they were summoned to a perilous location right before initiating that movement? A player wouldn't initiate the movement, but a scripted bot would…
29 Jan, 2013, Runter wrote in the 25th comment:
Votes: 0
A mud I played for many years (Exile) used this in their gameplay quite a bit. It was a bit of an annoyance for people who had large groups of followers since it affected NPCs as well, but it was good for strategic reasons because you could hide and set traps in the room and wait for your fellow adventurers to attempt to one by one walk through. Maybe 25% of the time (when someone enters) it would snare them, trapping them in a room where friends can't help and prevent them from escape until the combat is over.

It was also useful for non pvpers since in very tough zones it was a way to limit the number of aggressive NPCs that could happen upon you while you fought. In many cases it was hard to kill even one, let alone 2 or 3.
29 Jan, 2013, Telgar wrote in the 26th comment:
Votes: 0
I think a negative side effect of this could be ending up in a situation where you have a player camp out in the room to bar access to everyone else, especially if you use it to block access to a zone with high level equipment. Pretty soon, some team or clan is going to stake out the room and blockade it to control access to that high level eq.

Not that I am adverse to that either, I just don't think it should be achievable with one idle player. So I think the limit on the number of PCs/NPCs per room would have to be configurable and greater than one… except for maybe one or two "explorer" zones.
29 Jan, 2013, Rarva.Riendf wrote in the 27th comment:
Votes: 0
Telgar said:
There's another feature that's very underutilized, at least in the MUDs I have played, but has at least some support in Diku derived sources. You can mark rooms as a "TUNNEL". These rooms (in theory) only allow one player in them at a time. I've never seen an actual implementation in code however.


I have the room max number of people implemented. It is not like it is diffcult to implement as well, (just need to have char_to_room to return if there are already enough people in it). But builders harrdly use it for one obvious reason you spotted:someone staying in the room can block people.

Then you have to decide what to do about when people try to log in (because they logged off in it) the the room when someone is already there. <- that is the main problem imho, I cannot find a good solution for it.

I am all in having quest that gives individual rewards. A simple thing like an egghunt. People need to collect a lot to win. but they cannot give them. So someone multiplaying have no advantage. He will still have to have ONE char get them. For bots, I think hte only solution is a manual one.

I have a command that allows me to switch into a mob and fight (obvisouly differently as I off course keep access to all commands) . You could do that and see how the player reacts.
29 Jan, 2013, Runter wrote in the 28th comment:
Votes: 0
I should mention in the game I described it was implemented somewhat often, but only in areas where PVP was allowed. The game didn't limit PVP by a flag or option, it was toggled based on the area you were in. It wasn't possible to just idle camp one of these "cramped" rooms. There were multiple mechanics that could ignore it and put you in the room under certain circumstances.
29 Jan, 2013, Scandum wrote in the 29th comment:
Votes: 0
I think DikuMUD has the solitary flag to allow one player per room.

Alternatively to transferring a player to jail during combat you can purge the NPC they are fighting. This is less intrusive, and they're more likely to think they ran into some rare bug.

NPCs that flee on rare occasion are a good way to complicate botting, the more exceptions you add the more difficult botting becomes. PK is a good way to prevent botting as well.
29 Jan, 2013, Hades_Kane wrote in the 30th comment:
Votes: 0
Telgar said:
Splork said:
We silently trans them to a room, such as jail, and watch their scripts continue to run. Its amazing how advanced the scripts are but as long as you don't give them a reason to return to their keyboards ( such as using tell, say, etc ), its usually quite easy to tell.


I still don't think this works. I recall playing with someone who I later found out was botting. I could not tell at the time. They would instantly notice if you transferred them because they were actively multi-playing both characters over separate internet connections. Your method would only catch passive botters (and I agree it's easy to catch passive botters with that technique).

I was trying to think of a way to catch that case, and I don't think I know of one. Even mild versions of the "ask for personal details" (favorite flavor of ice cream, pizza topping or whatever doesn't identify you personally) are error prone and as Runter points out, it isn't appropriate to ask for specific information that makes them think you are targetting them for a credit scam. Also, I just looked in my logs and found out my client does in fact log my responses. So this technique is DOA anyway.

Maybe, if they can pass a simultaneous Turing test on two different internet connections, they should be allowed to bot, since they are effectively role playing two characters at the same time… I wouldn't like it but there doesn't seem to be any way to prove it without crossing the line.

Would asking them to pass an e-mail address challenge be acceptable? Then mail them a passcode. If they don't have two separate e-mail identities up front, they would be forced to confess. It's pretty easy to tell if a major ISP is down so claims their account is broken wouldn't work too well, and if they can't get back to you with the passcode in 5 minutes, you know something is wrong.


I may be naive, but I am of the mind that most players will do so without botting or multiplaying.

That said, do you want to basically harass and alienate an honest majority just to -get- the dishonest minority?

I think that is something very important to consider, whether the risk is worth the reward on that.

I know that if I were playing a game and for no reason I was suspected of botting or whatever, and I had to jump through a whole bunch of hoops to prove that I wasn't… I'd just politely leave the game and not return. It's like walking into a store and being frisked on your way out when you've stolen nothing. Which mind you, in my youth I've had experiences like that.

As far as the passive botter thing… If they are actually at their screens watching their scripts run, what is really the harm in that? Is there really that big of a difference as to whether or not they are manually typing the commands vs. having a script do it for them if they are actually AT their screens watching?

As far as the two different IPs and whatnot… again, without basically harassing all of your players to maybe catch a few cheaters, I don't see any way to really pull that off fairly.
19 Feb, 2013, Markov_AU wrote in the 31st comment:
Votes: 0
My normal response is to drop the players link if I think they are not actively on. I have one player that will have been on for 13-14 hours at times, and not be overly responsive, so i disco him and see if he logs right back in.
20 Feb, 2013, quixadhal wrote in the 32nd comment:
Votes: 0
You know, with text muds being an endangered species already, do you guys really WANT to lose players by making them feel like they have to watch over their shoulders or the auto-bot-police will catch them?

Markov_AU said:
My normal response is to drop the players link if I think they are not actively on. I have one player that will have been on for 13-14 hours at times, and not be overly responsive, so i disco him and see if he logs right back in.


A bot script will auto-reconnect if kicked, but so will a player who's excited about the game, cursing their ISP while they do it. In fact, back when I played over dialup modems (20 years ago), my terminal software was set up to auto-reconnect and log back in, and so was my mud client. You'd be hard pressed to tell if I were a real player using such tools, or a bot.

I can tell you if I suspected an admin disconnected me on purpose, I'd wash my hands of the game and never log back in, and probably tell my friends not to play there because the staff were jerks.

As for communication… why do you think you have the right to force players to be chatty? If I want to log in and go around slaughtering things, never saying a word to anyone, that's my business. If you can't stand the idea, make your game work in such a way that you can't make any progress solo.

The more I see in this thread, the more I'm convinced "botting" isn't really a problem, except that some admins are fanatical and paranoid about it. It reminds me of Ahab and the white whale.
21 Feb, 2013, Idealiad wrote in the 33rd comment:
Votes: 0
Whether botting is 'a problem' is really an interesting question and one I'm struggling with at the moment as I'm working on a PvP game. Where I have a problem with botting is a player using multiple bots to gang up on another player. That changes the game quite a bit and I don't see a good way around it.
21 Feb, 2013, Hades_Kane wrote in the 34th comment:
Votes: 0
My main 'problem' with botting is that if someone isn't at their character playing it, I want them to show on the who list as idle or AFK, otherwise, new people coming in will see a bunch of people "playing" and ignoring them, deciding the game is unfriendly and will leave. Or, they will recognize a game full of botters and leave.

If someone is running triggers and can respond to an immortal in a reasonable amount of time, they aren't considered to be botting.
21 Feb, 2013, Rarva.Riendf wrote in the 35th comment:
Votes: 0
Idealiad said:
Whether botting is 'a problem' is really an interesting question and one I'm struggling with at the moment as I'm working on a PvP game. Where I have a problem with botting is a player using multiple bots to gang up on another player. That changes the game quite a bit and I don't see a good way around it.


I have the same kind of problem (theoritically..as I dont have much players to begin with huhu)
I tried to mitigate it by having pk gain to be tied to fame. And gangkilling someone giving you hardly anything in this department.
Another idea would be to limit group size up to a certain number, and allow people to hire npc army. In order to have anyone compete with the same firepower. A botter would still be able to bot multiple groups but those would not benefit from friendly fire, or you could just make some places unable to hold more than xxx people as well.
Point is to make a botter unable to benefit from botting by design, not by rule.

You can also log things and see when people connects, from with ip, etc, and if you have a rule against it enforce it, but manually. Unfortunately there is no real good automatic way to make a difference between many people logging from the same school lab and a botter.
21 Feb, 2013, quixadhal wrote in the 36th comment:
Votes: 0
The first thing to ask is why people are choosing to use bots on your game. What is it they find so boring/repetative/etc, that they turn to botting as a solution? There's no economic factor, like there is with World of Warcraft…. I can't go sell my avatar in your MUD on ebay.

So, how do you solve the underlying problems that make botting attractive?

Most games reward based on activity. If you play for an hour and kill 10 things, and I play for the same hour but kill 30 things, I gain experience and loot 3 times as fast. That's the major attraction of botting…. a bot can play very fast, and it can play for a long time.

So, stop tying experience gain to raw slaughter rates. There are lots of way to do this. One is to provide diminishing returns for repeated kills of the same kind of thing, or things in the same area. That forces players to move around and hunt different things in different places…. something easy for human players to do, an annoyance for bot programmers.

Make rewards from quests much higher than easily-repeatable activities. If an area only has 12 quests, it doesn't really matter if the bot does them in an hour while the human takes 6 hours… once done, that's it.

PK is a little trickier, because botters there usually have a different motive. Either they want loot, or they want fame/fun. Those looking for fame or thrill will usualy have a single human running in a group with several bots following. That way, they ensure the advantage when stumbling upon others, since their "group" will act as a close-knit team.
22 Feb, 2013, Idealiad wrote in the 37th comment:
Votes: 0
PvP is the problem. Certainly limiting PvP based on group size is a solution, but it's a compromise that hamstrings 'legitimate' group PvP.
22 Feb, 2013, Runter wrote in the 38th comment:
Votes: 0
Here's my solution to botting. First, I make botting legal. I built some basic tools and expose information easier to help people make bots. Then I identify what is being botted and remove it/change the core gameplay to mitigate the botting advantages. I do not use anti-bot mechanisms like slightly changing text or asking people random questions, or anything like this. I simply gather data and react to the data to minimize the number of people botting. The problem isn't that bots exist on these games. It's that it risks taking the air out of legitimate players sails by comparison. If legitimate players only feel a sense of quaintness associated with botting (as in bots can't do a significantly better job than they can, and takes longer to build) then there's no problem.

Keep in mind, and this is important, no matter how bot-worthy your game is if you don't have anyone botting it you only have a theoretical problem. Not one founded in reality. I can't stress enough how important gathering data is. Don't drive the problem underground.
23 Feb, 2013, Telgar wrote in the 39th comment:
Votes: 0
I think people are talking about two very different things in this thread.

First is people botting a single, solo character, and the second is scripting a set of assistants to multiplay.

I have no problem with solo botting per se, but multiplayer botting is a whole can of worms.
23 Feb, 2013, Rarva.Riendf wrote in the 40th comment:
Votes: 0
Telgar said:
I think people are talking about two very different things in this thread.

First is people botting a single, solo character, and the second is scripting a set of assistants to multiplay.

I have no problem with solo botting per se, but multiplayer botting is a whole can of worms.


When you can bot one you can bot multi :) there is no 100% automatic way to know if you have a one actual player per avatar.
20.0/40