I was hoping someone could give me some insight into the use of the Twisted Game Engine for use with MUD development? Preferably someone who has actually used it as well. Pros? Cons?

Caveat: Please disregard your personal preference for using Python. I am just looking to find out the technical differences between using a more Python centered engine versus a C-based one as well as any specific pros or cons to using the Twisted engine specifically.

I think twisted is just an io library based on the reactor pattern. So it's not really a game library. Unless there's another library I'm unaware of. I've heard good things about it, though.

http://twistedmatrix.com/trac/

I dunno what point you're trying to make other than affirming exactly what I said. :rolleyes:

Twisted originally was developed to make a mud, so there are some mud-specific things buried in the codebase. However that purpose has long since been outstripped by Twisted being a networking library, not to mention that even the mud-specific code is rather experimental/undeveloped, at least that was my impression when I looked at it.

So, while Twisted is fine to use for networking (as many Python muds do) and you might be able to re-purpose some of its original mud code, my advice would be to use a leaner alternative if you just want to make a mud.

But, if you envision making something that can take advantage of all that Twisted has to offer on the networking side, by all means take advantage of that.

So what is the engine capable of exactly? I've got a few ideas, but I'm not sure what the capacity of its power is.

I don't know what point you're trying to make (but I have a few guesses.) You offered what you 'thought' Twisted is; Kjwah cited a source and kept his typing-to-information ratio pretty low.


In my experience (limited, fallible) this approach can be detrimental to your overall goal of building a MUD… IMO, you'll have better luck determining what you need and finding the best tool for that job than you will choosing a library that offers a lot of capabilities that you would then spend time finding a use for. (instead of developing your MUD :) )


Like Idealiad mentioned, you may be better served finding something leaner. (I haven't worked with Twisted so I can't really offer a lot. It might be perfect for what you need, but it also might have a lot of stuff you don't.)

Try circuit, or..

import socket
import asyncore
import string

I think those are good points.

I am pretty aware of what I need and what I plan for the future of this MUD. This engine was suggested to me and I'm trying to see what I can do with it to see if it is right for my needs or if it more than I really need.

Any other [related] comments are more than welcome while I research this myself.

I don't think Circuits is the library I was really thinking of, but it still might be worth looking into.

FibraNET

The point was he made a nonstatement and quoted it as something interesting. So if he actually had a point to make I'd rather him say it than made me divine what it is through the bones.


Re Demigod. These types of libraries are great for muds. I suggest you do not implement your own IO with whatever python provides. Twisted is no doubt going to be as efficient if not more so than implementing it yourself in pure python. So definitely use a library like this one. These reactor based libraries are all very similar. They rely on callbacks defined on an object representing a single socket instance. So you might define a dataReceived() method that handles the text input. Or connectionMade() for what to do when the initial connection happens. Or connectionLost() for when it's dropped. If you act upon these three basic events by just defining code to be ran it's very simple. From the Twisted documentation here's a basic example:

from twisted.internet.protocol import Protocol

class Echo(Protocol):

    def connectionMade(self):
        self.factory.numProtocols = self.factory.numProtocols+1 
        if self.factory.numProtocols > 100:
            self.transport.write("Too many connections, try later") 
            self.transport.loseConnection()

    def connectionLost(self, reason):
        self.factory.numProtocols = self.factory.numProtocols-1

    def dataReceived(self, data):
        self.transport.write(data)

factory = Factory()
factory.protocol = Echo

# 8007 is the port you want to run under. Choose something >1024
endpoint = TCP4ServerEndpoint(reactor, 8007)
endpoint.listen(factory)
reactor.run()

FWIW, as I said, all of these libraries like Twisted are very similar. There's a few popular ones in Ruby that do exactly the same things like EventMachine and cool.io.

Twisted is a large library with a lot of features - most of which are unnecessary for a MUD. There are a lot of protocol implementations in there (including things like GPS). I have questions about its performance, but it will certainly perform well enough for any MUD project.

I, personally, am not a fan of it because of how large it is and the fact that it mandates certain things that I find unpleasant (like its strange startup scripts). I think it's overkill for a MUD, but it's certainly not a bad choice. Leaner alternatives that I would recommend include: gevent, Diesel and Tornado. Tornado is aimed at HTTP but you can use the core for any network server.

I'll also put a plug in for my own network framework Pants. It's similar in both design and performance to the standard library's asyncore module but aims to be easier to use. It's got regular networking as well as Telnet, HTTP* and IRC implementations at the moment. Here's an echo server similar to what Runter posted above:

from pants import Connection, engine, Server

class Echo(Connection):
    def handle_read(self, data):
        self.send(data)

server = Server(Echo).listen() # len(server.channels) will give us the number of connections.
engine.run()

Pants also provides basic events and scheduling, which can be useful.

As was mentioned above, these are all networking frameworks, not game libraries. Basing a MUD off of one of these is very close to starting from scratch, so you might find it worthwhile to investigate some of the Python MUD codebases.

* The HTTP implementation - not written by me - actually outperforms Tornado. </brag>

EDIT: As an addendum, I'd like to point out that the standard library's asyncore/asynchat modules are quite solid but are also out-dated and fairly low-level. In my opinion you'd be better off going with a more modern library unless you're quite confident with socket programming.

OK, ok, that's enough gentlemen. :smile:

Aww, cmon. I liked that last bit there from sanko.

I was the lead developer on the twisted server for InstantJam last year (if you haven't heard of it… that's you and the rest of the world).

A challenge with Twisted is that, to take advantage of it's high concurrency capabilities, you need to slice up your server logic into lots of small bits and string it together with essentially a linked list. I can attest that code in that form is very challenging to wrap your head around and debug. Twisted also has a habit of eating exceptions deep in the machine which complicates debugging.

The latest twisted does allows you to use Python delegates to write code that appears normal but is really sliced up into concurrent chunks beneath the surface. You give up some of the concurrent performance by doing so, but the code and errors and debugging become sensible again. You can still run into tricky concurrency bugs because your code looks like it is sequential but isn't really.

Since my team was working on a game server, we contemplated often what possibilities Twisted had to offer. Here are my thoughts:

If you made a game server that expected massive amounts of concurrent connections, a library like Twisted would probably be a must. Realistically, for a hobby project, using something like Twisted is about getting your Geek on, but if you have fun with it then you have fun with it (I know I do).

Twisted is designed to allow a collection of loosely connected services, all collaborating. If you wanted to go beyond a simple telnet MUD and have your game tightly integrated with a website, feeds, external servers, etc; Twisted is a framework that fits that need (I'm sure there are others).

For me, I like the high concurrency problem space but don't ever plan to use Twisted again. The main reason is that, once you use it, you can tell that Twisted "fights" against the underlying Python language to do it's job well. Because Python doesn't have high concurrency paradigms in it, Twisted code has the feel of taking normal code, turning it inside out, then tying it into knots.

Justin

Thanks Slakker, that's essentially what I needed to hear.

Twisted has served us really well for the open source Evennia MUD codebase. We are on year three or four now, and things are chugging right along pretty well. Take a look at http://evennia.com/ or join us on #evennia on FreeNode IRC.

It's been great not having to worry about too many protocol-level issues, and the performance has been outstanding for what we're doing. We've also been able to easily hook in a web-based JS client, which is included in the repository. This could be used to easily run telnet and a web versions entry points at the same time, serving the same game.

Twisted is complicated and the documentation is pretty bad, but we've taken care of that part for you. You only need grab Evennia, drop in your game-specific stuff, and get off to the races.