MUD Programming Questions

In a proper MUD, you probably wouldn't want a delay between actions. The MUD player (historically-speaking) can enter commands as fast as they like. It usually depends on the action you're doing as to the responses. There is usually a queueing system for actions, so if you issued 15 'cast spell at monster' actions, those would be queued up and dealt with by the heartbeat system. Each object (that appears 'alive') would have a virtual heartbeat method that would be called by the MUDLIB every second.

An example of a non-heartbeat action that would be processed immediately, is when you want to travel through locations quickly, you can go as fast as you can type because these actions are immediately processed (e.g. 'east' 'east' 'north', etc). If you attack a monster though, the responses are usually restricted to the heartbeat of the monster (which is generally around a second or so). This is how you get the classic 'You hit monster very hard.' - 1 second - 'The monster hit you.', and so on.

I would suggest having a worker thread which runs through the object hierarchy calling the virtual heartbeat methods and a thread to handle user input (be it local or over telnet or whatever). Depending on the action entered, either immediately process it or delegate it to the relevant heartbeat'ed object.

You can always download the old LPMUD libs if you want to see how it's done properly.

Regarding your second question, the original MUDs had an interpreter which interpretted game object files dynamically (which were written in LPC) and wrote intermediate data and object-value data out to what were essentially ini files. That way, users could make changes to things like room files and reset them intra-game to see their changes. It depends on how complicated you want your MUD project to be. Are you going to allow script-based specialisation of room/weapon/monster objects? If so, some kind of scripting mechanism would be the way to go (lua, etc), otherwise you could keep it simple and create some form of generic object DB structure and have some simple process to translate DB data into your MUD objects (ala hibernate). You could also go for the simple xml option which would also work nicely.

There are also some great books on writing full MUDs or simple text-based role-playing games, although I'm sure if you google, the topic is old enough that you'll find ample online material to reference.

Hope that helps.

[edit] - Just to be clear and for you purist types (you know who you are!), I used LPC as an example. There are dozens if not hundreds of different MUDLIBs around.

Hey Rob,

Thanks for the reply. Maybe I'm really bad at Googling, but in terms of handling delays, there doesn't seem to be much out there. I'd like to find a good book, but the only one I ever see floating around is "Mud Game Programming" by Penton.

Can any one suggest any books other than the one I just said and that are more specialized for MUD programming vs General Game Programming?

Game loop:

time_step = 0.1;while (true) {  processInput();    current_time = now();  while (current_time-old_time > time_step) {    expireEvents(current_time);    processLogic();    old_time += time_step;    writeToStorage(); // update database, files, etc. to persist changes  }  };

Events are stored when they should execute: (time_of_expiry, event_data).

So expireEvents() goes over a priority queue:

while (front.time_of_expiry < current_time) {  processEvent(front);  pop();}

Quote:

some sort of threading or signals in the C++ code

Yes, it's possible, but it's considerably more complex to get it right. The above approach is very simplistic in that updates are atomic.

[Edited by - Antheus on December 12, 2008 1:47:35 PM]

Quote:

Original post by Amicus I've also read about integrating scripts such a LUA. Is that the way to really go?

It's often worth integrating a scripting language into a MUD since the people developing quests, skills, and the like rarely want to code in the original programming language to get this done, or to have to go through a recompile to test changes.

Quote:

One minor question I have is that many of the sample source codes seem to write data to files to persist things (players, room, objects, etc...). Is this just a convention or am I missing something less obvious?

Most MUDs are based on code from the early 90s. Back then you'd be very lucky if you had access to an SQL database. So it's mostly just convention, the same way that most MUDs are written in C or C++ despite a hundred more suitable languages existing for the purpose.

I must also unfortunately disagree somewhat with RobMaddison: although LPMUDs are fine pieces of engineering, they're also incredibly complex compared to simpler and more hard-coded MUD engines such as the DIKU variety. If you're just starting out I'd steer clear of reading the source to the two-layered MUD programs which introduce all sorts of complications that a beginner shouldn't need to worry about (such as implementing your own language within a game, for instance).

Quote:

I must also unfortunately disagree somewhat with RobMaddison: although LPMUDs are fine pieces of engineering, they're also incredibly complex compared to simpler and more hard-coded MUD engines such as the DIKU variety. If you're just starting out I'd steer clear of reading the source to the two-layered MUD programs which introduce all sorts of complications that a beginner shouldn't need to worry about (such as implementing your own language within a game, for instance).

Kylotan - I agree, there are certainly simpler MUDLibs around. Although I tried to pitch my post to more-or-less cater for any complexity Amicus wants to try. Several years ago, I did exactly what Amicus wants to do (albeit to learn Java rather than c++) and I found the LPMUD libs to be a great resource. There are a lot of supporting files that tell you exactly how things fit together and it's fairly easy to strip out the built-in compiler/interpreter modules and other bits you don't need. If nothing else, analysing someone else's code (that you know is solid) is great practice.

I would suggest downloading any kind of MUDLib (LPMUD 2.4.5 is the one I used) just to look at the supporting documentation (of which there is usually an ample supply). If you've played MUDs before and know basically how the process works, relating the documentation/source code to the concept will be worthwhile.