Bringing the best of MUDs and online text gaming to your browser, MudGamers is a new community gaming site with a fresh modern design. An integrated Flash client enables players to connect immediately to their chosen game.
I've posted some more details on the project on my blog. I'd appreciate any feedback and of course I'd love for people to begin to list their games. Once I am happy with the site features and we have enough content I will begin to market the site to players with an emphasis on attracting new gamers to mudding.
The client is pretty nice, seems easy to get around with, I tested it out by making a character and moving around a bit. Do you have any plans to expand it and allow for aliases, triggers, etc? or is it more a starter thing, and alternative to telnet?
I'd like to try it with my mud. Is it possible to enter an ip and port somehow? I didn't see a way of doing so.
The idea of the MudGamers site is that each mud has its own page so the client only connects to that particular game. If you go to the submit page you can fill out the connection details and it will list your game and generate a page with the client embedded.
If you mean you want to use the client separately, then it's available from here.
Kayle said:
Do you have any plans to expand it and allow for aliases, triggers, etc? or is it more a starter thing, and alternative to telnet?
There are some technical issues that make storing triggers and aliases tricky, although with Flash Player 10 it may be getting easier. It is something I will definitely keep in mind for future versions, but the client is definitely aimed at the novice or casual user rather than the power user.
Hmm. See, I tried to get FMUD working on my site but wasn't able to. It might be a good alternative to just get a page on MudGamers and then link to that for the client. Mm.
Hmm. See, I tried to get FMUD working on my site but wasn't able to. It might be a good alternative to just get a page on MudGamers and then link to that for the client. Mm.
I would say 99% of all reported problems people have getting FMud to work are down to wrongly configured socket policy files. You will still need a working socket policy file to use MudGamers but there is an example file, server script and instructions available here.
People on shared hosts probably need their server administrator to do this step for them. However all the host has to do is serve a master socket policy file allowing connections from mudgamers to all ports and then all their hosted games are taken care of. It's just a couple of lines of xml and a python script.
Edit: I'm happy to write to mud hosts or help them with any questions or setup issues they may have in order to make this resource available to their clients, but the initial push is probably best coming from a paying customer.
We're in the process of redoing our game's web site and the new version has fmud as part of it and it seems to work just fine for us based on fairly minimal testing thus far. If one (or more) of the folks I host wanted to use this (or registered on your mudgamers.com site like I did yesterday) too, what would I need to change about the socket policy file to make it work for them as well?
This would allow Flash applications hosted on mudgamers.com access to all ports on your server. This should allow for any game you host to list at mudgamers. You can also specify ports individually, comma separated, or in a range.
This would allow Flash applications hosted on mudgamers.com access to all ports on your server. This should allow for any game you host to list at mudgamers. You can also specify ports individually, comma separated, or in a range.
Done, thanks, at least it's a simple change.. now to figure out what else is still wrong with it's configuration so you can see it from your end.. :wink:
(I may have to go with that comma separated port list instead of * though, I'm not certain that I like the idea of flash being able to access ANY port at all…)
I installed Python 2.5.2 in order to try this software out.
I've been playing around with this, and I'm finding the the auth scheme problematic.
Please correct me if I'm wrong, but it looks to me like before the applet connects to my game port, it must first connect to my auth port.
If I have the webserver on server A, and the mud on port 5050 of server A, then when computer B (me at home) connects to the webserver of A, I get the applet, which then runs locally on computer B.
Then this applet on computer B contacts server A on port 843 to retrieve its policy file. Once the policy file is retrieved and the policy is accepted, then the applet performs the connection from computer B to port 5050 of server A.
Connection is made, joy ensues.
Do I have this right?
If so, then this makes the client mostly unusable to me. Port 843 is privileged, meaning I need to run the auth as root or do some unrecommended trickery. That's a problem. The next problem is that I need to open a firewall port for 843 on server A. That's tricky for me.
I understand that you're constrained by Adobe's security standards, but I'm finding this scheme to be a pretty fair obstacle to using the client. I've got a couple of places on the internet where I could try to put this, but they all run into the first or second roadblock. For others I suspect it would also be not-so-great. Perhaps an indulgent mud host wouldn't mind running a sockets script for you as root and opening that port on their firewall for it…but I'm not sure I'd count on it.
I'm hoping I've misunderstood how this thing works.
Adobe have recently made the security restrictions a lot tighter and unfortunately there is no getting around the policy file requirements.
There is much more information on the Flash player security model and socket policy files on the Adobe website. They also have some alternative policy server scripts for download.
Muds that are self hosting or with their own server/VPS shouldn't have much of a problem getting this set up, however I agree that for those with third party hosting they are going to be reliant on their hosts to enable this for them. I am in contact with the major hosts about them offering this facility to their customers so we'll have to wait and see. This issue will affect anyone wanting to use a Flash client with their game, whether through MudGamers or not, so I hope that the various mud hosts see the benefit in setting up socket policy files for their servers.
I seem to be running into basically the same problems, though it does appear that running the FMud client from my own site works without the issue of port 843 being open since it's being run from the same machine to begin with, but that could just be illusionary based on my testing a dev site from within the firewall to begin with too. Though, from what I can find on the web, port 843 isn't actually used for anything other than adobe socket policies, but the XML file could potentially be hacked to basically force open any other port at all if someone was good enough. :sad:
For those with hosts unwilling, or not around, to install this socket policy will there be an account system to allow listing?
The whole idea behind the site is that it will enable players to try out new games easily in their browser, so I'd really hate to lose that 'click to play' facility that embedding the flash client gives.
I think it will take a little time, but I believe there is benefit in enabling Flash access and hopefully if more game owners start asking for this service mud hosts will make the necessary server changes.
MudGamers is very much in an alpha state and these are the kinds of issues I want to get sorted out before I even think about trying to market the site to new players.
11 Sep, 2008, David Haley wrote in the 19th comment:
Votes: 0
So am I correct that you'll only let people list if they go through the necessary steps of setting up your Flash client, or convincing their host to do so? I don't mean to presume or anything but that sounds more like a way to advance a client than MUDs…
The whole idea behind the site is that it will enable players to try out new games easily in their browser, so I'd really hate to lose that 'click to play' facility that embedding the flash client gives.
I'm definitely not interested in raining on your parade, but from what I've seen, you're facing a formidable obstacle in making your my-client-only site a big resource, based on this auth problem. If you stick with your (very nice) client only, I just don't think you're going to have a site that's very useful except to the dozen or so muds and their players who can wrangle their admins to run the policy server as root on a privileged port.
On the other hand, there are other 'click to play' options available. My demo mud, for example, uses a java client for that "just click here to play!" thing: http://dead-souls.net/javaclient/demo.ht...
It's not as pretty as your client, nor as functional, but it works great and it does what you say you want to happen on your site. I'm sure there are other solutions, too. Perhaps someday everyone will run an Adobe policy socket server…but until then, I think it wouldn't hurt to make a mud resource site more flexible.
Bringing the best of MUDs and online text gaming to your browser, MudGamers is a new community gaming site with a fresh modern design. An integrated Flash client enables players to connect immediately to their chosen game.
I've posted some more details on the project on my blog. I'd appreciate any feedback and of course I'd love for people to begin to list their games. Once I am happy with the site features and we have enough content I will begin to market the site to players with an emphasis on attracting new gamers to mudding.