26 Aug, 2008, Kayle wrote in the 2nd comment:
Well, my suggestion for you is a simple one.
Check out some of the codebases in the Code Repository, maybe pick out a few that you like, and poke around at the code, maybe not start it up at first, but just look through the code. Perhaps even pick out one of the text ones from the Mud Listings and give it a try and get a feel for them. I think the first step in understanding a MUD is to play one. I can't really comment on the use of Java for a browser based mud, I'm more of a traditional client based MUD guy myself.
To directly answer your questions, Baring the Java one based on my limited experience with Java:
2: Muds are programs generally run on Linux-based servers and people generally connect using a domain name and port, for instance, something like Uh… off the top of my head… telnet://avpmud.com:4000 would connect you to AvPMud an Aliens Vs Predator themed mud. (Sorry Fear, Only thing I could think of. :P) It's generally done using a Mud Client like ZMud/Cmud or MUSHClient. There are a multitude of clients available but I think Z/CMud and MUSHClient are the two biggest contenders. Possibly KMuddy too. The application doesn't normally automatically start, You generally have to set up a script in the shell to run it, but once the game starts running, it's continuously running unless you cause a Segmentation Fault, which generally causes the MUD to stop running, and the process dies. People generally see each other as a one line description of text after a description of the room is given, for instance, taken from my mud:
Not all MUDs will look this way, for one, that's how things appear on my mud, but things might not appear the same way on someone elses. It's certainly a lot different if viewed from the Players perspective.
3: I think I answered this in my opening ramble. Yep. Looks like it. :P
Check out some of the codebases in the Code Repository, maybe pick out a few that you like, and poke around at the code, maybe not start it up at first, but just look through the code. Perhaps even pick out one of the text ones from the Mud Listings and give it a try and get a feel for them. I think the first step in understanding a MUD is to play one. I can't really comment on the use of Java for a browser based mud, I'm more of a traditional client based MUD guy myself.
To directly answer your questions, Baring the Java one based on my limited experience with Java:
2: Muds are programs generally run on Linux-based servers and people generally connect using a domain name and port, for instance, something like Uh… off the top of my head… telnet://avpmud.com:4000 would connect you to AvPMud an Aliens Vs Predator themed mud. (Sorry Fear, Only thing I could think of. :P) It's generally done using a Mud Client like ZMud/Cmud or MUSHClient. There are a multitude of clients available but I think Z/CMud and MUSHClient are the two biggest contenders. Possibly KMuddy too. The application doesn't normally automatically start, You generally have to set up a script in the shell to run it, but once the game starts running, it's continuously running unless you cause a Segmentation Fault, which generally causes the MUD to stop running, and the process dies. People generally see each other as a one line description of text after a description of the room is given, for instance, taken from my mud:
[Area name: Sanctum Immortalis] [Area filename: gods.are]
[Sector Type: inside] [Area Flags: noteleport]
[477][Room Flags: nomob indoors nosummon noastral dnd office]
Sanctum of the Forerunner
+———–+ This room has an almost antique feel to it. The walls are a
| | beautifully finished cherry with a touch of oak alternating
| | every so often. The floor is a perfectly done hardwood floor of
| O-O | a rich pine, with a beautifully designed, and incredibly
| | | defined symbol of the forerunner inlaid with the perfect
| @ | mixture of gold and silver. The symbol takes up the vast
| | majority of the center of the floor space, the rest dominated
| | by the magnificently carved desk from which the Forerunner
| | issues all decrees for the realms. At the foot of the dais upon
| | which the desk sits rest a pair of panthers of whom the
+———–+ Forerunner is very fond.
Exits: north.
{493} An ornate, blackened oak desk sits here upon a raised dais towards the rear of the room.
(Sovereign) Thannie is here before you.
<1000144hp 900000m 900480mv>
Not all MUDs will look this way, for one, that's how things appear on my mud, but things might not appear the same way on someone elses. It's certainly a lot different if viewed from the Players perspective.
3: I think I answered this in my opening ramble. Yep. Looks like it. :P
26 Aug, 2008, Omega wrote in the 3rd comment:
Okay, for doing a graphical mud, java/browser based would be a good idea, in my humble opinion.
As for how muds work, very simply, heres the break down.
[SERVER]
Waits for sockets to connect
Adds new connections to a list
Recieves input
Events/Updates
Sends output
Loops back to waiting.
Now, how does the application automatically start as you put it, well, you have it running at all times, watching, and waiting, putting it in a cron-job (linux) would do best, or your startup (windows).
How they work.
——————–
The server application opens a port, which allows your client to connect with. It checks the incomming information
to the opened port, and sorts it to the connected user. Parse all events/updaters for that moment, send out
any data that has happened since the updaters.
MMO's generally dish out the data right away, but muds tend to add it straight into a queue, to be parsed later.
How do people see each other. For a graphical mud, your server would most likely keep track of
coordinates, and if you are within range of another user, the server would transmit the appropriate
data to the other user.
case and point:
Dave is in range of bob. Server sends Dave (and bob) their coordinates information,
aswell as their 'base' character data, series of numbers/letters indicating class/race/equipment/face…
whatever options it consists of.
When the client gets that information, they display that on-screen.
In the mudding world, you tend to see things that are 'in the same room' as you. For the text based muds that is.
so you get the description, visible players, visible objects, and exits.
For graphical, you would have to have on both client and server side, layouts of the game data, so the server knows
where a player can infact be to gauge/control the output, and the client so it knows how to display the appropriate data.
such as standing on the edge of a cliff overlooking a small town. You may not see the ground in the town, but you may see the peaks of the buildings (such as a church)
With that being said, where to start for you.
I recommend getting the basics of socket/client relationships down, perfect example of that is to write a text based mud, or download one like socketmud, or rom, and learn how they interact with/from clients.
As for how muds work, very simply, heres the break down.
[SERVER]
Waits for sockets to connect
Adds new connections to a list
Recieves input
Events/Updates
Sends output
Loops back to waiting.
Now, how does the application automatically start as you put it, well, you have it running at all times, watching, and waiting, putting it in a cron-job (linux) would do best, or your startup (windows).
How they work.
——————–
The server application opens a port, which allows your client to connect with. It checks the incomming information
to the opened port, and sorts it to the connected user. Parse all events/updaters for that moment, send out
any data that has happened since the updaters.
MMO's generally dish out the data right away, but muds tend to add it straight into a queue, to be parsed later.
How do people see each other. For a graphical mud, your server would most likely keep track of
coordinates, and if you are within range of another user, the server would transmit the appropriate
data to the other user.
case and point:
Dave is in range of bob. Server sends Dave (and bob) their coordinates information,
aswell as their 'base' character data, series of numbers/letters indicating class/race/equipment/face…
whatever options it consists of.
When the client gets that information, they display that on-screen.
In the mudding world, you tend to see things that are 'in the same room' as you. For the text based muds that is.
so you get the description, visible players, visible objects, and exits.
For graphical, you would have to have on both client and server side, layouts of the game data, so the server knows
where a player can infact be to gauge/control the output, and the client so it knows how to display the appropriate data.
such as standing on the edge of a cliff overlooking a small town. You may not see the ground in the town, but you may see the peaks of the buildings (such as a church)
With that being said, where to start for you.
I recommend getting the basics of socket/client relationships down, perfect example of that is to write a text based mud, or download one like socketmud, or rom, and learn how they interact with/from clients.
26 Aug, 2008, kiasyn wrote in the 4th comment:
And no matter what language you're using, READ BEEJ'S GUIDE TO SOCKETS. It is awesome. http://beej.us/guide/bgnet/
26 Aug, 2008, kiasyn wrote in the 5th comment:
Also, I highly recommend checking out how Tyche handles sockets in TeensyMUD (although its in Ruby.).
26 Aug, 2008, war dharok wrote in the 6th comment:
Wow thanks for all of the advice! It looks like I have enough resources to read up on for a few hours thanks guys!
26 Aug, 2008, Hades_Kane wrote in the 7th comment:
I think one of the most important things you can do is pick a MUD that you like and spend a bit of time learning it as best you can as a player. That will teach you probably more about MUDs in one approach than anything else. Secondly, after you feel you know the game pretty well as a player, see if the Administration of the game wouldn't be against showing you a bit on how things work "under the hood" so to speak, and if they aren't, find what codebase they are using and start poking around yourself on your own server. Once you are very familiar as a player how things work, it will be immensely easier to look under the hood and see how mechanics you are familiar with actually get done.
That would be my suggestion at least. Either way, good luck!
That would be my suggestion at least. Either way, good luck!
Random Picks
About a year ago I started to get interested in video game programming (essentially to start making autos in the MMORPG runescape)
Anyways, I started learning C++ and made several cool programs which worked rather well. Lately, Ive become very interested in the programming aspect of how mmorpgs work. After reading a lot about Andrew Gower's (the creator of runescape) first graphical mud called devious mud I decided to start working on my own.
Ive decided to switch to java to make a graphical mud that is browser based. Right now I just need some advice from the community.
1) Is it a good decision to switch to Java to make a browser based mud?
2) Could anyone give me an overall idea on how Muds work? I understand that Ill have to have a server (most likely using my home computer w/ dsl) but how exactly do people join my server? How does the application automatically start? And how is it possible that other people can see other people in the application/graphical mud?
3) Whats a good way to begin for me? I was thinking a good way to start would be to make an irc. Or make an application where people are dots and can move around in a square using the arrow keys. They would be able to see one another and communicated via text.
Any help or info at all would be great. I know making a mud takes a lot of time but I just need some basic info and any ideas or help you have to offer.