Unless you're doing graphic-intensive things, I don't think caching the information on the client is going to be that big of an advantage. I mean, MUDs are already pretty much the least resource-intensive multiplayer game out there. What else uses less than 1% server CPU and can be reasonably played on dial-up? Plus client-side encryption isn't going to work, especially if you have an open source program that can decrypt it.
I think MXP can already do some of what you suggest, like including images in the client. Of course it's probably not all that flexible, I doubt it would allow for things like overhead maps (haven't really looked at it that much..). One thing I think would be supacool is exposing the game's information using XML web services. I've been working this sort of thing (when I have time), like RSS feeds of the game's notes. I guess a client that could consume those sorts of web services and present that information to the player in interesting ways could be sweet. On Apr 4, 2005 7:51 AM, Christopher Bunting <[EMAIL PROTECTED]> wrote: > Hello All, > I know there used to be various coders on this list from way back, > while most people are probably not looking to do anything of this > depth, I figured that I would make the post here since it does relate > to my rom codebase. Please note: Allot of this post contains my own > personal opinions based on my experience with muds over the course of > many years so it's not directed to anyone.. They are just my > thoughts.. > > ----- Start of Post ----- > > I've had various ideas in the past on how I want my mud to be > different. I had at one time tried to get ideas from the web but the > problem I see is that everything regarding muds is so standardized > that it's unbelievable. > > We have all of these great telnet clients like ZMud, Portal and tons > of others. But no one has ever really developed one aimed at mud > developers to incorporate into thier own games.. > > And then, we have various muds working to incorporate the use of mysql > to do back end functions and such. While all of this stuff maybe sound > good, I think the biggest problem is that in my personal opinion, > these developers have missed the point.. > > General muds have worked great for years and there was never a need > for this back in the mid 90's.. I have yet to see a mud with a > playerbase of that size today who had even thought about doing this. > Aardwolf has had in excess of 400+ players on at many times. I've > never heard mention of them using a database. Why change what already > works well. Hence, it would be nice if that much effort was put into a > mud client that we have never seen. > > The great thing about graphical games is that stress is taken off of > the server because players are given a specifically written client > just for that game.. Like UO, Quake, and so on. It's beyond me why > Smaug was the only mud I ever knew of that attempted anything close > with the Realms Client or whatever. But if I remember, it was windows > only. > > I, myself have been looking into writing a client that could connect > to a mud and would also hold the majority of files that most diku > derived muds hold in memory.. Meaning that the mud client would > include the help files, general gaming notes, contain the motd and so > forth all within the encryted files. The player downloads the client, > logs on, the client checks for updates for new helps ect and downloads > them in the background.. I think a typical mud can be expanded greatly > if the server / client aspects were seperated. > > If you are familiar with the RoaClient and the set of c scripts that > you can incorporate into your mud for sending the motd, boards, eq > lists, who list, sound files and such, then this is what I am after. > But I'm not just looking to have scripts, I'd like to offer an open > source frontend/client as well. That's the only drawback about Roa, no > source for the actual client and hence, it too only runs on windows. > > I see nothing wrong with doing this in terms of files client side. > Some may say that it would make it easier for players to expose the > docs or info contained within the files.. But It doesn't matter > because even with RoaClient, Zmud and others, I can copy the text of > any mud at any time.. It's ashame people do this but I know I've seen > muds with 100% original areas that were copied and reused elsewhere. > However, A specific client with it's own protocal/encryption could > help stop this. > > I guess overall, I'm looking to do something more like UO and general > 3D games in terms of the seperated client/server. I'm not looking to > build a grapical mud. Although bmp, gif, jpg login greetings, motd's > and map support would be nice. I'm just not trying to reinvent the > wheel and worsen the system resource load due to external databases > and everything else. The client should support all of this by issuing > simple commands, not sending full files. Meaning that if the mud send > the send motd, the mud client would do all of the work on the client > side. > > The problem is that there isn't anywhere to look. I've thought about > using the front end from something like Quake 2 and incorporating the > text capabilities from the mud into it but Quake is a commercial > product and it would appear that there would be too many issues using > it along with a modified codebase like mine (Rom24) which has been in > development for about 3 years now. > > Does anyone have any ideas or links to something like this or docs > about this. I don't want an actual client, I would just like to find > info on sending/receiving files and updating things client side. > Encrytion of files and so on. There has never been any open source > clients with overhead maps or anything of the nature being shown and > updated 24/7 on the client side that I have seen. These are just some > of the many things I'm looking to achive but just don't know where to > start.
