Tony Robbins wrote: > But music is nice. But to do that, I've got a streaming mp3 system If bandwidth is a concern you can always go with midi also. Consider that bandwidth may be a concern on the client side. > So far, my best solution is to provide a maintained > connection to my server, and then tell the client to > get more information. Well, there are various different solutions to this: 1. You can provide a package that can be downloaded or you can send a CD (for a reasonable fee, of course) with all the multimedia stuff. This is a nice option for some who do not have a reliable connection. If you have multimedia images that the player is not supposed to have access to until they reach a ceartain level or complete a ceartain puzzle, etc, then you can encrypt the files with different passwords which are provided by the server at the time when they're supposed to become available. 2. You can provide the multimedia on a server for a fetch on demand system. This can be done via http, ftp, some custom protocol, whatever. Advantages of http are the ease of viewing the multimedia (all you need to do is pass the URL to a browser). Advantages of FTP are speed, efficiency, and reliability. A good streaming protocol can give even better speed and reliability than FTP but is not standardized anywhere near as much and you may have a problem with firewalls (HTTP and FTP are far less likely to be firewalled). 3. You can stream the multimedia right off the server in-line. This is probably one of the worst ideas, but it is an option so it does bear mentioning. This would require either switching the client into a binary mode to recieve binary data straight off the server or using a binary to text conversion protocol such as uuencode. 4. Any combination of the above. > But now we're at _3_ clients to play a MUD. Three? you lost me there. > Obviously, writing my own client is an option. I don't know of any other option. You can modify an existing client such as any one of the many tintin ports available. > But now we face a couple fairly painful facts: telnet works on > all platforms and most people have a preferred client already. True, and I would recommend that unless you're writing something that is fully graphical that you allow continued support for telnet. I'll even go a step further and say that telnet is a good protocol to base this on because of its flexibility (am I the only person who thinks that simply extending the telnet protocol would be more than enough for a good MUD protocol and would allow for easy acceptance and use of older clients that don't support the MUD protocol yet?). > zMUD allows writing modules, but zMUD is not > free, and I don't think the 'vast majority' of players > have tossed out the crash to use it. zMUD is not the only client out there that is extendable. There are many free open-source clients available that you can modify to suit your needs and not have to worry about licensing fees. I tend to think of zMUD as a decent all around stand-alone client, but I wouldn't use it to base a custom client on. > In the end, I'm probably going to have to write my own > client, and most likely it will be in Java. Yuk! > The inherent slowness of Java will turn most people off to > it, I fear. But everybody will have access to it. If you base your client off of one that is fairly easily ported across platforms then you can start by writing it for the most popular platform and then port it to others as time permits. You can simply show links to web pages which disply the content for those who do not have the client. > Do extra clients bother players? (For Windows,) I'm > envisioning a mini-browser (approximately 150x150 > pixels of viewing area) that you can set to 'Always on > Top', then set it up in a corner of your screen so that > it doesn't interfere with your "regular" playing, You can also "dock" it to the side or top of the screen. Make the whole thing one client, though. You can have multiple windows, but I doubt that users will want to download bits and pieces of different clients or have to individually launch multiple programs to see all the multimedia in your game. > 1. Do people actually buy zMUD? Yes, I bought it, if I were looking for a client now I might not buy zMUD, but since I already paid the money a while ago and it's a one-time fee, I figure I may as well use it. > Is it worth developing for a specific _client_? No simply because there are enough free clients out there that you can develop just as well. > 2. What kind of client things could be added (music, > graphics, etc) without being considered annoyances? Music, graphics, sound bits (not music but just effect sounds), pics, maps, etc. Make it so that each feature is individually customizable and can be configured on or off so players need not be annoyed by any feature they don't like. > 3. How would you address the fact that telnet is a > widely supported, cross-platform protocol, without > writing clients for each platform? I'm not sure I really understand the question. Telnet is a protocol that is intended to allow programs written on various different platforms to communicate universally. It is not intended to make a single program work on different platforms. > 4. I remember discussion of an actual MUD protocol (not > MSP, MXP, etc). Does the community need an open-source > MUD client available across platforms, etc? Will this > happen? Tintin (originally a Unix client) is (to the best of my knowledge) open source and has been ported to various different platforms. > Oh, and I'm definitely not > advocating turning the MUD away from text-based, so > these are just additions, that one can live without That's key. Make sure the playability of the MUD does not rely on the multimedia extensions. Regards, Peter -- +---------------------------------------------------------------+ | FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html | | Archives: http://post.queensu.ca/listserv/wwwarch/circle.html | +---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/04/01 PST