Original Post
I'm considering creating a MUD game server as a sort of software engineering exercise for myself. The goal of the final product is to be a high-quality, well documented, extensible MUD platform, with a particular eye towards scalability, customization, and a strong document/view model. The server would support various client types such as telnet, terminals, and custom text/ascii art/graphical clients. To accomplish this, World Description files would be stored in a nuetral XML format encompasing all the data needed for each type of client. For example, a text-based client would not recieve graphical data or descriptions, while a graphical client would recieve graphical data and possibly the text as well. Other tag elements will use nuetral descriptors to invoke a client specific appearance, eg- html-like tags would format text in the appropriate color if the client supports this. Basically, the user experience will scale to what the user desires, and the capabilities of their client program. In addition to this XML format for world data, the MUD would be extensible through a scripting language, possibly LUA, python, or a custom language. I would prefur a widely used language to a custom solution, but language-level support for engine mechanisms such as time or events is an intriguing possibility for a custom solution. The various facilities would be tied together by an event-system which would allow clients, NPCs, the game world and scripts to communicate in both a point-to-point and broadcast manner. Each area(room) would have a defined set of "built-in" events, ie- OnEnter(), OnExit(), as well as any custom event handlers specfic to the area. Logical groups of rooms(regions) would also have similar default and custom event handlers. This would scale to any depth in a hierarchical manner. eg- room > house > town > kingdom > etc... TCP should be sufficiant to handle the networking since reliability/order is more of a priority than performance in a MUD. I flirted with the idea of seperate threads for each client/connection however the overhead would probably be very wasteful. My second thought was to spawn threads for groups of players, say 64 or so, grouped by client type. Perhaps client threads are wholey unnecesary though, and threads for load/save, processing, and a handfull of other engine mechanisms will be sufficient. Any experiences/thoughts here are welcome. The player database is largely a grey area for me at this time. I'm unsure of whether a full SQL-type database would be necessary, or if a organized directory of client profiles would be sufficient. Perhaps a hybrid, where each player is essentially their own small database? I already have a system for manipulating a hierarchical set of named properties, which could constitute a small, extendible database with little or no changes. Comments and recomendations are welcome for each of these aspects, as well as anything which I may have, and no doubt, missed. Have you written a MUD before? Please share your experiences, things that went well, pitfalls you encountered, etc. It would be greatly appreciated.