Member Discussions

I've done a search but can't seem to find an answer to my specific question. I'm planning a MUD base using Python as the programming language and SQL (probably MySQL unless I can figure out how to use SQLite) as the datga manager. It seems obvious to me that I should be using threads for connection handling and network comm, but I was wondering about using a single thread per player for player processing. To me it seems like it'd be easier to code in general, but I'm wondering if anyone can think of any threading specific pitfalls I may come across with this functionality, apart from the standard basic hassles threads can throw at you.

As for the SQL overhead question, I was wondering if there's enough overhead in SQL querying to make it inefficient for near constant access. For loading data, I'm pretty sure it's faster than any custom DB system I could make, but if I don't want to store very much data in memory if I can help it. Also, would it be more efficient to store item data in a room specific table (ie: SELECT * FROM itemlist_12383) or having an items table with the items knowing where they are (ie: SELECT * FROM items WHERE room=12383).

I suppose maybe I should write the code first and worry about the optimization of the DB later?

The standard hassles of threads are already quite a pain. Do you plan to put locks everywhere or only have a single thread running at a time?

I don't anticipate having to lock much. Interthread communication can be handled through messaging each other. As far as I can see at the moment, it shouldn't be too difficult to code it so that each thread handles it's own variables and if say, player A causes damage to player B, A's thread would send a DoDamage message to B's thread, which would calculate the damage based on B's stats and apply it. This would also later provide for server expandablitly if it became necessary to run on multiple servers. I'm not sure of the overhead cost of handling things this way so I'd have to experiment.

Threading has been discussed at great length in the past. I exhort you to do a forum search for the phrase Dragon's Dinner.

It's not about threads talking to each other, it's about threads sharing the same data (like rooms, items, etc.)

The locking problems will kill you if you don't plan your architecture VERY carefully. If you want to skip this work, then just use single threads. If you are prepared for it, then you can do some slick things using a multi-threaded architecture. It can work either way.

Well, the plan was that there'd also be a thread for WorldData and whatnot. So it kinda is about how they talk. The player tread would query the worldthread for the data. Of course, like you said, it's a matter of planning it very well in advance. But if it doesn't cause too much overhead, using an internal "peer-to-peer" like model may work well. We'll see after I do more research.

When I hear your description of "peer-to-peer", I think of message passing interfaces. I may be wrong, but I'll operate off that assumption.

Also, disclaimer: I am not a systems specialist, meaning I am not an expert in what I am about to discuss. I do, however, have some limited experience, and much observational data.

You probably don't want your first complex threading experience to be a full-scale deployment system. Especially not if you're using a memory share solution - locks are a pain. They're also tricky, and if you haven't played with them enough before, you'll end up with incredibly painful lock ups.

Now, for message passing. There can be very good reasons to use message passing. Full message passing architectures have been shown to have some very nice software engineering properties. They can offer certain types of robustness, as well. Elegant, really.

However, they are not simple. I'd say that message passing is easier to learn than memory sharing, but it's still finicky. Threads, in general, are never, ever simple. A lock-free, heavily threaded system requires as much, if not more, foresight than a mutex solution.

You also won't be seeing performance gains any time soon, with MPIs. Message passing doesn't come into its own in performance terms until you get large architectures. I hear numbers like 32 processors bounced around (someone correct me here?). Basically, don't adopt MPI for performance reasons. If you're going to pick it up, do it for the other advantages.

P.S. Those of you who deal with threads a lot, feel free to correct me. I never use memory sharing designs, and I use message passing interfaces primarily for their nice software engineering properties.

It seems obvious to me that I should be using threads for connection handling and network comm, but I was wondering about using a single thread per player for player processing.

Why does it seem obvious to you? What properties of your specification lend themselves well to threading connection handling and network communications?

I suppose maybe I should write the code first and worry about the optimization of the DB later?

Sounds like a good idea.

Why does it seem obvious to you? What properties of your specification lend themselves well to threading connection handling and network communications?

From what I've read on multithreading usage for online games, almost everyone agrees the network communication should be multithreaded so you never (or almost never) end up in a situation where you need to be sending or receiving data but can't do to the system being busy somewhere else. And connection handling is almost ALWAYS done multithreaded, even if the networking code isn't. I don't know how much this applies to MUDs, but that's the usually case with other types of online gaming.

As to the messaging system being complicated and whatnot, I understand. I've done messaging based stuff before. However it IS much much easier if you understand it than a lot of other methods, particularly the locking and unlocking stuff with threads. I'm not entering this project, like many other people seem to, to learn to program. I'm fairly well experienced, though not professionally yet. This will be my first project using Python, however, and first major use of threading, if I decide to go that route.

You might want to read up on Python's Global Interpreter Lock, then. Python has major implementation issues with threading.

Not many MUDs actually use threading at all, even for network or connection handling. The dominent model is a select loop, and all world code runs quickly enough that there's not much network delay. And usually the MUDs that use threading do it ONLY for networking, because of the trouble of keeping the game state synchronized.

I don't know how much this applies to MUDs, ...

Sounds like you have a solution searching for a problem.