MUD Concept Question
Sorry for the vague Subject but i wasnt sure exactly what to use anyway ill get straight to the point.
Ive created a windows gui in C++ using Asynchronous Sockets and a select based server in C ( on a unix platform ) which functions like a chat room. Everything works and ive tested it with a few client connections and the server handles fine, everyone can talk to each other no probs.
What I really want to do though is turn this into a very small (and i mean very small ) mud for example just allowing people to move around north, south, etc and maybe even interact with an NPC.
So its more of a concept problem I face at the moment as im not sure of the best way to store the room data, character data, how to handle the movement, etc. Im currently writing some MySQL connectivity and some kind of very simple authentication procedure where the user has to input a username and password to be authenticated before they connect, so I can increase / add to these tables with some character data but should I store room data in these tables aswell ? Or flat files ?
hmmm im not explaining myself very clearly, im just confused as to how MUDS process commands and display and store data efficiently. Only way ive thought of so far is a bunch of If statements checking the incoming buffer for commands and keeping peoples position in a small 2d array ? It just seems like a bad way to do it as its going to be alot of work on the server.?
If someone has managed to fathom out what im rambling on about :p and you could lend some advice or some pointers id very much appreciate it.
Thanks in advance.
using mysql tables, this is the direction i would go
user id PRIMARY NOT NULL AUTO INCRIMENT
..other membership/community type information you may wish to add
room text ID (the general text for room ex: You are in a forrest)
room special/secret text ID (special text that occurs from discovering an item in that room ex "Your magic reveled a ..")
exit north ID
ext south ID
exit east ID
exit west ID
exit up ID
exit down ID
exit SE,NE,SW,NW ID etc.
Basicly, id use the member table only for loging in, and community/chat related stuff.
Location table is relation table, you put the user id (from member table user id, and it tells you what room id they are currently in. If you change the table lay out, or find a different way one thing you WANT to do is something like this reference table. In a mud,the most common action is movement. So you want to be able to access the smallest sized table, with smallest amount of fields to change/alter room location. This table is a MUST.
rooms table is where all room information is stored, like what npcs are inhabited, what items, information texts etc. Lots of reference keys here. Youll notice that the general and secret texts are ids. They are foriegn keys into the text_table. NPC and Shop are also foriegn keys that reference to npc and shop tables I didnt explain. I think you can come up with those yourself using the items table scheme. NPC text should also be reference to the text table. Also the directional exit ID's are reference ids to the room table. When a character uses a move command, the location table should update his room id to the reference ID stored in the proper direction reference. Room ID 0 should not be a real room. You should use 0 or null for directions that arnt available.
Items table has all the item information. Every item has a unique id, and special bonuses. You might want to add a Name field, that references the text_table for a name.
Room items table is another reference table, that lists all the items and rooms they are found in. Multiple rooms may have same item. Example: (item sword id = 3)
where 4 and 23 are other item id's. The reference table isn't needed to be sorted, but perhaps to speed up a search routine to return all the rooms with an item, or all the items in room, you may want to keep the table sorted numericaly by item id.
text_table is another must. I lied about movement being the most common thing in MUDS, its really second. First place goes to text appearences. YOu want a table with all your game text. This goes from npc names, item names, room names-text, etc. (Player names are fetched from member table though).
Any table that has a field for text should be a reference field to this table.
So for example, should I be player 34, this is psuedo how i might go about displaying all that i need to display
I hope that helps you out. I wrote it spur of the moment, so I hope I didnt make it too confusing.
room = mysql_fetch( location_table, 34 ); // find user id 34,and return room id
roomInfoStruct = parseCols( mysql_fetch_row( rooms_table , room) ); // get room general text ref id, exit ids etc)
roomText = mysql_fetch(text_table, roomInfoStruct.txtId);
BTW, I might be interested in helping you with your mud should you welcome the help. Let me know.
Thanks dbgt goten, I think MySQL is the best way to go then, ive designed a few databases in the past so I reckon that would be an easier method for me to use.
The table layout looks like a good soultion for me, i like the idea of having exit ids aswell which link to the relating rooms. The movement table yep thats what I think ill have trouble with, someone else told me you should try and make it as small as possible as you pointed out.
Well your post has definately given me something to get started on, thanks for the pointers and advice and if I ever decide to work on it with someone else ill give you a shout.
I haven't looked through all the different variations, but this link has the source code for alot of the popular muds like dikuMUD, sillyMUD, etc. I don't know anything about SQL myself, but if you just want a general feel for the way other muds process stuff, that's a great place to start. Most muds up and running have taken one of those codebases and modified it slightly or heavily (depending on the coding proficiency of the implementor). I'm in the process of writing one from scratch (I have yet to find a codebase that even comes close to my concept) and the few I have looked through have been extremely helpful, even if only from the design.