   MUDs (or text-based games): Questions about threading and architecture...
  I know that many, many MUD engines exist but I'd like to try creating a simple one just to fool around but I have a few questions:1) Is it better to use a threaded or non-threaded approach?  It seems like most MUDs use threading.  1a) If threading is preferred then how many threads should I have?  (eg. one for each client, one for running NPC AI, etc)2) How should combat turns/rounds work?  This seems to be my main confusion and it seems very related to my other question.  For example, if a player initiates combat than should I add them to a combat queue that gets updated every few milliseconds, etc?I've taken a look at the book MUD Game Programming but it didn't seem too good...   
  Perhaps http://www.gamedev.net/reference/programming/features/mudpie1/ would be of use to you?   ;  In case of MUDs, threads add nothing but complexity for no benefit.Quote:It seems like most MUDs use threading.They do?Quote:2) How should combat turns/rounds work? This seems to be my main confusion and it seems very related to my other question. For example, if a player initiates combat than should I add them to a combat queue that gets updated every few milliseconds, etc?Since concurrent logic is so complex/hard to get right, it's one of areas where multi-threading is frequently avoided. Perhaps your question is aimed at how to time the events. This is simply done inside main simulation loop:while (running) {  sendAndReceive();  for (Event e in events) {    if (e.expired()) e.perform();  }  update();};Events in this case is just a priority queue where you schedule events in simulation time when to happen.   ;Quote:I've taken a look at the book MUD Game Programming but it didn't seem too good...I disagree - I think Penton's book is a great starting point for your own MUD.  I'm sure others will disagree with me, but why are you avoiding it?   ;Quote:Original post by sofakng1) Is it better to use a threaded or non-threaded approach?  It seems like most MUDs use threading.No, they really don't. 99% of the MUDs currently in existence are single-threaded.Quote:2) How should combat turns/rounds work?  This seems to be my main confusion and it seems very related to my other question.  For example, if a player initiates combat than should I add them to a combat queue that gets updated every few milliseconds, etc?Most MUDs work much like any other game - by updating several times a second. Every X updates you can see who's in combat and perform the calculations accordingly. If polling all the characters for updates becomes inefficient you can start adding events to a priority queue sorted by time so that you only handle 'ripe' events, but that is an optimisation that you are unlikely to need to begin with.;Quote:Original post by ShakedownQuote:I've taken a look at the book MUD Game Programming but it didn't seem too good...I disagree - I think Penton's book is a great starting point for your own MUD.  I'm sure others will disagree with me, but why are you avoiding it?I agree with you. I think the Ron Penton book is actually quite a good start on developing MUDs. While I never read the book, I know Ron Penton and he's quite a well versed Software Engineer. Toolmaker   