04 Oct, 2011, zany wrote in the 1st comment:
Votes: 0
I'm not sure if this is the correct place for this, feel free to move it.

I'm not a very experienced programmer, although I know the basics, and I've decided to code a MUD with a friend, probably using PHP. However, I'm not sure how to use telnet properly. Assuming I use a linux server, how do I set up a PHP program such that a user can telnet to the server on a particular port (say port 9001) and get information from the PHP program rather than being able to use the terminal commands like sudo etc.?
04 Oct, 2011, plamzi wrote in the 2nd comment:
Votes: 0
If you're not highly experienced, writing a MUD server from scratch is probably not what you want to do. Why not start by googling "mud php" and build upon something existing?
04 Oct, 2011, JohnnyStarr wrote in the 3rd comment:
Votes: 0
If you are knowledgeable with PHP then it's not a bad idea.
PHP 5 has added object-oriented features, as well as some good APIs for various
database vendors and other useful technologies.

The PHP guide has a section about socket programming and the libraries included that
you will need to use. That being said, you would want to understand that the PHP used
to write dynamic web-pages, isn't exactly the way you would write MUD code.

I'm assuming you are mentioning PHP by name because of your experience using it. I
understand not wanting to add learning a language to your current TODO list. However,
you may find Ruby to be a more forgiving, elegant approach.

Have fun!
04 Oct, 2011, zany wrote in the 4th comment:
Votes: 0
I am more knowledgeable about C/C++ than PHP, but my friend knows mostly PHP and I'd like to learn that, plus my C++ isn't great anyway. In addition we'd ideally like to be able to administrate and build the whole thing using webpages, which is where PHP would come in handy (of course we could use C++ for the codebase and PHP just for the administration and building pages…hrm).

The thing I'm still not sure about how to do is telnet usage, and how to run a telnet server that responds to commands other than terminal/cmd prompt commands. I downloaded phpmud, but couldn't see any obvious telnet usage, so I'm guessing it's entirely web based.

EDIT
NVM, http://www.php.net/manual/en/sockets.exa... looks interesting and pretty much what I wanted to know.
04 Oct, 2011, Rarva.Riendf wrote in the 5th comment:
Votes: 0
zany said:
I am more knowledgeable about C/C++ than PHP, but my friend knows mostly PHP and I'd like to learn that, plus my C++ isn't great anyway. In addition we'd ideally like to be able to administrate and build the whole thing using webpages, which is where PHP would come in handy (of course we could use C++ for the codebase and PHP just for the administration and building pages…hrm).

The thing I'm still not sure about how to do is telnet usage, and how to run a telnet server that responds to commands other than terminal/cmd prompt commands. I downloaded phpmud, but couldn't see any obvious telnet usage, so I'm guessing it's entirely web based.

EDIT
NVM, http://www.php.net/manual/en/sockets.exa... looks interesting and pretty much what I wanted to know.

Why for a new codebase, use telnet at all..if people have internet, they have a brownser, better provide them a nice client as well. So they don't need anything to play your game but go on your webpage.
Only reason to use telnet is to support an old game as a hobby…
04 Oct, 2011, KaVir wrote in the 6th comment:
Votes: 0
Rarva.Riendf said:
Why for a new codebase, use telnet at all..if people have internet, they have a brownser, better provide them a nice client as well. So they don't need anything to play your game but go on your webpage.

You make it sound like an "either or" scenario. It's not. Creating a nice custom browser client may well bring in new players. Blocking other clients is unlikely to increase your playerbase, however.

Many muds already offer custom browser clients that work the way you describe, and there are several generic browser clients that can connect to any mud. But because the muds use telnet, players can also use the wide range of other mud clients that have been developed over the last couple of decades.
04 Oct, 2011, zany wrote in the 7th comment:
Votes: 0
Ideally we would also have a webpage client; coding with PHP would make this extremely easy, as would forum and game integration.

How difficult is it to support the many mud clients out there and what should we know about them? Should we just support basic cmd prompt telnet and assume other mud clients can operate with that?
04 Oct, 2011, Rarva.Riendf wrote in the 8th comment:
Votes: 0
KaVir said:
Rarva.Riendf said:
Why for a new codebase, use telnet at all..if people have internet, they have a brownser, better provide them a nice client as well. So they don't need anything to play your game but go on your webpage.

You make it sound like an "either or" scenario. It's not. Creating a nice custom browser client may well bring in new players. Blocking other clients is unlikely to increase your playerbase, however.

It was not my intention. I don't say 'drop telnet', but 'dont build an engine around it'.
04 Oct, 2011, KaVir wrote in the 9th comment:
Votes: 0
zany said:
How difficult is it to support the many mud clients out there and what should we know about them? Should we just support basic cmd prompt telnet and assume other mud clients can operate with that?

They can, although most muds offer more than that - ANSI colour and the ECHO telnet option are extremely common, for example. An increasing number of modern muds and clients also support more advanced telnet options, many of which are designed specifically for muds.

Rarva.Riendf said:
KaVir said:
Rarva.Riendf said:
Why for a new codebase, use telnet at all..if people have internet, they have a brownser, better provide them a nice client as well. So they don't need anything to play your game but go on your webpage.

You make it sound like an "either or" scenario. It's not. Creating a nice custom browser client may well bring in new players. Blocking other clients is unlikely to increase your playerbase, however.

It was not my intention. I don't say 'drop telnet', but 'dont build an engine around it'.

You said "Why for a new codebase, use telnet at all".

Several muds offer custom browser clients, but off the top of my head I can think of only one active text mud that requires you to play through your browser - Archons of Avenshar. In a discussion about mud clients last year, the owner of Archons of Avenshar mentioned "We'd LOVE to pick up more players at AoA! However, you may only play AoA with the Flash Client, and that has most likely turned off a lot of MUDders who prefer to use their own client."
04 Oct, 2011, Rarva.Riendf wrote in the 10th comment:
Votes: 0
Indeed my bad. I was thinking telnet should come last, as an addon, but not be part of the codebase engine. Something you can easily drop without having to rewrite anything in your engine.
04 Oct, 2011, Runter wrote in the 11th comment:
Votes: 0
I checked out this Archons of Avenshar client. I think it's a little premature to determine that the reason they don't have more players is because they turned off a lot of mudders who preferred to use their own client. How do I know that? Well, most muds allow you to use your own client, and most muds are bare and empty.
04 Oct, 2011, KaVir wrote in the 12th comment:
Votes: 0
Runter said:
I checked out this Archons of Avenshar client. I think it's a little premature to determine that the reason they don't have more players is because they turned off a lot of mudders who preferred to use their own client.

I'm just quoting the owner/developer.

However if you look at other muds that also offer comparable flash clients, you'll see that a not insignificant number of their players prefer other clients - sometimes because it's the client they used originally, other times they're intentionally switching for whatever reason.

Obviously we can only speculate what impact Archons of Avenshar's decision has had on its playerbase, but I think it would be difficult to argue that it's had no impact at all.
04 Oct, 2011, Runter wrote in the 13th comment:
Votes: 0
KaVir said:
Runter said:
I checked out this Archons of Avenshar client. I think it's a little premature to determine that the reason they don't have more players is because they turned off a lot of mudders who preferred to use their own client.

I'm just quoting the owner/developer.

However if you look at other muds that also offer comparable flash clients, you'll see that a not insignificant number of their players prefer other clients - sometimes because it's the client they used originally, other times they're intentionally switching for whatever reason.

Obviously we can only speculate what impact Archons of Avenshar's decision has had on its playerbase, but I think it would be difficult to argue that it's had no impact at all.


I think it's pretty clear that you linked developer in his own words to lend credibility to the argument that's actually your position. And it's a position I disagree with. This isn't evidence at all, except that his game is a flop.

The entire debate isn't whether it has no impact. It's whether it has negligible impact, and if other factors are actually the deciding factors. Custom clients themselves are no good if the custom client is an inferior interface when compared to a mud client. Most all custom mud clients I try treat it as a toy for letting people dip their toes before they go and use a real mud client. And this guys in specific was no exception. It's not surprise that these mud clients wouldn't be very popular.

I think these days it's a little naive to think that there's a difference in the minds of players between the interface to play the game and the game itself. If one stinks, both stinks.

All in all, anyone treating this type of thing as even a shred of evidence is falling into gross fallacious territory.
04 Oct, 2011, Rarva.Riendf wrote in the 14th comment:
Votes: 0
Yep I looked at the screnshot as well the client does nothing but show you hp/mana in pretty bar, and that's it.
No map, no buttons, no triggers no nothing. No wonder you would want to use your own client, than suffer to be restricted to this one.
04 Oct, 2011, KaVir wrote in the 15th comment:
Votes: 0
Runter said:
I think it's pretty clear that you linked developer in his own words to lend credibility to the argument that's actually your position.

Actually I thought I laid out my argument pretty clearly in my first post:

KaVir said:
You make it sound like an "either or" scenario. It's not. Creating a nice custom browser client may well bring in new players. Blocking other clients is unlikely to increase your playerbase, however.

Many muds already offer custom browser clients that work the way you describe, and there are several generic browser clients that can connect to any mud. But because the muds use telnet, players can also use the wide range of other mud clients that have been developed over the last couple of decades.

Imagine two muds, completely identical in every way except that:

Mud X: Can only be played through its custom browser client.

Mud Y: Can be played through its custom browser client, but also through telnet clients.

My argument is that Mud Y would attract at least as many players as Mud X, because it's a superset of Mud X - it offers everything Mud X offers and more.

Whether you consider it worthwhile is of course another question, much like any other design or marketing decision. Is it worth supporting older clients? Is it worth supporting newer clients? Is it worth offering sound? Compression? Energy bars? Is it worth having a newbie school? A tutorial? Help files? Is it worth having a website? A domain name? A paid banner on TMC? A promotional tattoo on your forehead?

We have limited resources, and it's up to each mud developer to decide how best to use them. But I disagree with the suggestion I've seen made a few times elsewhere (and which I thought was being made again here), that dropping support for telnet clients would somehow result in a more popular text-based mud.

Rarva.Riendf said:
Yep I looked at the screnshot as well the client does nothing but show you hp/mana in pretty bar, and that's it.
No map, no buttons, no triggers no nothing.

Huh? It has a very nice map, actually. It has buttons too, although not many. No idea about triggers.
04 Oct, 2011, Rarva.Riendf wrote in the 16th comment:
Votes: 0
I counted 3 buttons, one that looks like inventory (typing 'i' is way faster ,making the button totally useless, the other two are probably as useless…) Any client works it salt will allow you macro for those kind of stuff. (I admit I don't even count the arrows for moving as buttons).
The map looks nice, I would not say it is nice (shows vicinity only, pretty useless as well).
When you want to provide a client, make it so you dont 'need' another. This client is definitely not on par with a mush/cmud/mudlet. It is just enough for casual gaming.
04 Oct, 2011, Arynth wrote in the 17th comment:
Votes: 0
Having looked at PHP at one point myself, it's usually more helpful to search for PHP Telnet Servers, or PHP Socket Servers, than for PHP Muds. I found man's blog about creating a basic Setup for telnet/socket communication using PHP here: PHP Developer Blog. I played with it, and it seemed to work very well. He walks through the steps of making the classes, so it's a little more helpful to the OP regarding learning more about it. It does not, however implement any form of a game as would normally be considered. It is a Socket Server that has the ability to have commands issued and answered. Anyone using it would be responsible for actually making a world, characters, NPCs, etc… from this.

As far as using PHP to make a mud? It should work just fine. It may not be as fast as compiled code, but it should work for all but the largest worlds with huge player bases. If the OP manages to create a game that does that, I'm sure someone would be glad to help him change technologies. By then, he may have learned enough to do it on his own any way.
04 Oct, 2011, David Haley wrote in the 18th comment:
Votes: 0
KaVir, your argument is sound, but you emphasize the useless question and minimize the interesting question of something being worthwhile.

Your problem is that you trivialize the argument that people are making and substitute a tautological statement. Presumably, people proposing a custom client are adding important features to that client that will not be available on generic clients. And therefore, the game experience will be somehow, presumably, superior, thus attracting more players.

In other words, you are confusing dropping telnet support with adding features that are not possible in telnet clients. It is not the dropping of telnet that is proposed to attract players: it is the adding of features.
04 Oct, 2011, KaVir wrote in the 19th comment:
Votes: 0
Rarva.Riendf said:
When you want to provide a client, make it so you dont 'need' another.

You don't "need" any particular client, its all a matter of personal preference. Which kind of ties into my earlier point.

Rarva.Riendf said:
This client is definitely not on par with a mush/cmud/mudlet.

I'm not sure how feasible it would be for a browser-based client to offer the same functionality as MUSHclient, CMUD or Mudlet. But even if you did manage it, it wouldn't matter whether or not your mud used telnet - you could still offer exactly the same features.

As I said in my first post, creating a nice custom browser client may well bring in new players - and indeed several big commerical muds have invested in such clients specifically for that reason. But they also support telnet. The two are not mutually exclusive.
04 Oct, 2011, David Haley wrote in the 20th comment:
Votes: 0
KaVir said:
I'm not sure how feasible it would be for a browser-based client to offer the same functionality as MUSHclient, CMUD or Mudlet.

No reason to make this claim. Is there a browser client that has feature parity? No. Is it feasible? Absolutely.

KaVir said:
The two are not mutually exclusive.

Yes, they are, eventually. Well, perhaps they are compatible in this tautological argument where of course you could write some telnet interface. But if you have interesting features in the custom client that give a true competitive advantage, there comes a point where it simply makes no sense to use the inferior interface. In fact, there are game mechanics that you could do with graphical interfaces in a custom client that you simply couldn't replicate in a traditional text interface with any measure of usability.
0.0/133