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 <cbunting99@gmail.com> 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.
--
ROM mailing list
ROM@rom.org
http://www.rom.org/cgi-bin/mailman/listinfo/rom