I've lamented the lack of a proper MUD playing robot for some time now. Oh, we all know they're out there, but the folks who make them never seem to want to share – even though they're easy enough to spot and foil without the source.

Why do I want one of those filthy things??? Well, they make great stress testers! Where else can I find, on a moment's notice, a hundred n00bs ready and willing to run all over my MUD, killing chickens and rats to test out how the game handles mass combat with that new SQL code I put in?

So… I'd like to hear from anyone who has coded up such a critter. I've pondered digging out my perl cookbook, but haven't gotten around to it yet. I did, however, find this page about a modified version of TinyFugue that someone is trying to build a bot engine around.

I'm hesitant to speak up on this, because the
bot I've coded is really very, very messy.

I created it because I wanted to stress test
the codebase I maintain…and it was originally
not meant for public distribution. So because
it was going to be "in house" and only for
Dead Souls, it is unattractively structured
and hardcoded for Dead Souls muds.

However, since I eventually did release it, and
it does seem on topic for this discussion, I'll
share it: http://dead-souls.net/code/ds2.8.4/lib/s...

It's in LPC and it's doubful it's run on
anything other than Dead Souls without an overhaul…
but if you run a Dead Souls mud it's a pretty
convenient way to load up a bunch of bots and
see how much activity your mud will handle
before the lag starts getting heavy.

I hadn't expected to enjoy botwriting, but it
became weirdly rewarding. A couple hundred bots
stumbling around the mud, picking fights and
manipulating stuff, is a great way of finding
bugs, performance bottlenecks, and misfeatures.

And it was fun pushing the envelope to see
how many players my test mud would handle on
mainstream PC hardware: http://lpmuds.net/1024.jpg

In summary, this code isn't especially portable,
but it works fine, and if you're up for figuring
out its logic and modifying its triggers and such,
it should do just fine for stressing your mud.

-Crat
http://lpmuds.net

Tangent warning…

Every time I look at LPC, I can't help but wonder why people say it's really that much easier than C or C++. I suspect that the real gain is in the framework that LPC drivers provide, and not the actual programming language. Looking at that code, it looks almost identical to C.

Crat: Nice, over a thousand of the little guys running around eh? :)

David: Yep, the big win in lpc is the fact that you can code something on the fly and if you mess it up, the driver won't crash… with a few exceptions, none of the other players will even notice.

It does have some rather odd type interactions though… it can actually change the type of a variable out from under you if you're not careful. I do wish they'd get rid of that horrible bracket mess for mappings though… I never remember which way they go.

Heh, it's a fair point.

I think you've pretty much nailed the basic reason…
LPC provides frameworks that act like libraries
that would make C/C++ programming easier to put up with.

For example, in LPC there is a string data type,
and you don't have to worry about allocating
memory and such. There's no chance of accidentally
overwriting memory, etc etc etc.

In terms of what it looks like and general flow,
yes, it is very much like C. But because the stuff
that isn't very relevant to making a mud has been
abstracted away, it is easier to handle and learn.



Heh, everyone has their pet peeve. Personally I hate the class data
type (like structs) and love mappings. Diffrent strokes!

-Crat
http://lpmuds.net

EDIT:
Note that this particular LPC file has some fairly complex and
sophisticated stuff going on. It's not something I'd advise the typical
newbie to play with. As with C, there is a continuum in LPC from "simple code"
to "advanced code". This one happens to be a bit toward the "advanced" edge.

To be honest, this is one of my biggest pet peeves with the state of many C MUDs. For some reason, there is very little abstraction, reusability, or encapsulation. C obviously has its flaws, but it is possible to write code that is so much easier to work with than what you commonly see in MUD code. Were I to start from scratch now, I wouldn't use C anyhow, but we'd be in a much better state now had some plain ol' software engineering been applied to these codebases much earlier on.


The string data type is solved by C++, but the memory management issues are pretty legit improvements over C (and even C++ to some extent, despite self-managing pointer classes).


That might be why it's unclear to me what the benefits are just by looking at it. Perhaps were a much simpler example presented, it could showcase how simple that example is in LPC vs. what you'd have to do in C. (I'd still question how much of the benefit was from the framework and how much was from the language itself, though.)

I just happen to be many times more comfortable
in LPC than I am in C, and that's why, when the
need arose for a bot, I chose to write it in LPC.

I don't actually think there's much advantage to
using LPC rather than C for the specific task of
making a bot…if any.

-Crat
http://lpmuds.net

I ended up modifying a copy of Nick Gammon's tinyclient into a somewhat inelegant bot. I also coded one in Lua that was so so. I do recall that Nick coded one in Lua that would deal about 500 clients, he wouldn't share the code, but he was more than willing to share the thoughts and ideas behind it, take a search through his site and you should be able to find the thread.

A good stress tester is something that most of us lack, and those who have them are reluctant to release the code because it is pretty easy to use to run a DOS attack against a mud you don't like. You only need a couple of people hitting you with 500 connections each to make most games crawl to a halt.

The codebase I maintain has a configurable "max connections from one IP"
option to prevent that sort of thing. The default is four.

I have to imagine it would be pretty simple to implement such a
thing on most muds that don't already have it.

-Crat
http://lpmuds.net

Yeah to be honest i do not know how smaug or any other diku handles things like that, sounds to me like something that should be looked into at some point and added in.

Yeah, we had better defend against the barbarian hordes pounding at the gates, just waiting to bring down MUDs around the world.

:rolleyes:

The thing is though, 6 lines of perl will do just as good of a DOS attack as a sophisticated bot… To cripple a game, all one needs to do is connect to the login screen and quit, ad nauseum. That forces the admins to either site-ban the address (which may take hours or days, depending on how active they are), or implement a built-in limit that will annoy people from college dorms or other places that put multiple people behind a single NAT firewall.

I can say that Crat's limit of 4 per IP would have prevented my group from joining back when I was at WMU. There were 6 to 8 of us (depending when you looked) that typically would find a new game and all play together as a group. Back then, everyone played from vt terminals on a mainframe, so ANYONE on campus would all be coming from the IP address of said mainframe. Nowadays, people use PC's but they typically have NAT routers for each floor of the building.

But hey, if you haven't gotten any complains, then it's not a big deal. I just have an aversion to trusting the IP address of anything as a means of authentication or control. Maybe if IPV6 ever gets going… :)

Oh, and I *love* the mapping data type. I just *hate* the annoying multi-symbol brackets it uses.

That's why 4 seemed reasonable when I set it as default…it's
not 1994 anymore…



This had not occurred to me, and it's a pretty good point. I'll
have to give it some thought. In any case, it's trivial to change
on the fly with the command: mudconfig maxip 10
(or whatever number seems more appropriate).



No complaints thus far, but you make a good point about NAT being
common these days. The limit isn't really meant to be especially
daunting…just discouraging to the casual hooligan.

-Crat
http://lpmuds.net

I've not seen that – then again, I may be perhaps somewhat spoiled in that I come from a campus where we all had our own static IP address. Actually, I had several static addresses just for myself. :wink: Ahh, those were the days… now I'm on a normal ISP… :cry:

Do you have actual examples of campuses that actually do this? I would be surprised if everybody had their own static addresses, but I'd also be surprised if the entire dorm system were on three IP addresses per building (assuming three-story builders).


And for good reason – IP addresses should be treated with several grains of salt…

Western Michigan University does this, I'm pretty sure. I'll ask my friend who works there next time we have lunch.

I know the way they were talking was that every dorm got a NAT router for each floor. The one I stayed in was 6 floors with about 30 rooms each, so 6 addresses is easier to manage than 300. Students shouldn't be running servers anyways, the RIAA says so. *poker face*

Each department gets a router (more if they have several locations), which will be NAT unless they have file servers that other departments need to access.

Of course, they're moving everything to wireless so that all might go away soon (or maybe already has).

I'm going on what I hear, of course, since when *I* was there we had bare copper wire going to rotary phones, and I was "leet" for wiring up my own RJ11 jack and having a 2400 baud modem!

Huh, that is remarkably different from where I went to school. Sure, we had similar router setups for floors and even sections of floors, for both dorms and department buildings, but no NAT.