13 Feb, 2014, duanuys wrote in the 1st comment:
Votes: 0
have moderate knowledge in C++ I began a few weeks ago, and while I can say I am not a master with this stuff, I am learning as I go. I can write up a simple program in very little time, but where is all the fun if all you can do is just make a simple mathmatical program using C++. I have always been a MUD player since I was young, and even though I took long breaks inbetween my MUD 'phases' every single time I am always wanting to program these kinds of games. It is one thing playing something like this game, but making one feels like more of an achievement then playing for years on one, because in the end doesn't matter if you have 1000 players playing your MUD or it is just you, you can still say "that is my creation"

With all that dramatic BS out of the way I have downloaded the sources code of diku++ from this website to kind of see how a game is structured using C++. The good news is, when i scan through the source code it makes sense to me, somewhat I would have to go into depth in studying the nature of the different variables and where they lead too, but nonetheless I can make out what it is doing with the familiar code structure.

Simple question.. How do I start with my own MUD? It is a very vague question I know, but even as long as I have been playing, and been exposed to programming there is always one thing that lacks in my knowledge and that is.. where do I begin? Do you start by making a menu? a welcome screen?

I already started making my own MUD type of game, but to be honest even though it contains ifs and else statements, a few good loops and menu options, I even created a program that the user has to enter a predetermined username and password… but even with all those gadgets, the game still feels linear.. even though there isn't any kinds of monsters or the ability to chat, those come much much later. I am talking about the core foundation of a mud. HOw does that start? And is there a place on the internet, here included, where people like me are asking the same question and is willing to get together, virtually, and starting creating a game together.

I know its a lot of questions and I appreciate the time the people took to read this. Any responses would be greatly appreciated!
13 Feb, 2014, quixadhal wrote in the 2nd comment:
Votes: 0
I realize you're comfortable with C++, but I'll still suggest you think long and hard about using it for a text MUD. Even using std::string, C++ doesn't have a native string type, and manipulating text is still a pain in the arse… and that's what you'll be doing 95% of the time.

As for how existing MUD's work, the core of a Diku-type game is found in comm.c. Usually a function called something like game_loop(). Read that and understand it. The simplified version would look like:

while( !done) {
pull incoming socket data into buffers
handle player input
do combat updates
do environment updates
flush outgoing buffers to sockets
}


An LPMUD (which I always suggest looking into) is a bit different. In an LPMUD, the driver itself is a language interpreter that handles socket connections and file I/O. It runs LPC soft-code to create and run the game universe. At its core, it basically does this:

Quote
At boot time:
load the "master" object, which has to have a function to handle new connections.
load any other objects which were listed as "preload" objects.

At run time:
When a new connection appears, call the function in the master object to handle it.
Typically, this creates a "user" object which can then receive input from the socket and be the player object.

When data comes in on a socket, call the receive() function in the object attached to that socket.
This is the LPC object created by the new connection handler. The receive function is called with the data
from the socket, and it does whatever it does with it.

Handle any pending call_outs.
A call_out is a delayed function call form an LPC object into another LPC object. It can be scheduled for some time
in the future, or as soon as possible. The LPC driver enforces a limit on how long a given object's code can run, so to
prevent resource abuse (or accidents), it's not uncommon to break your code up into chunks and have each chunk
schedule the next chunk as it finishes (like an old batch system).


As you can hopefully see, they both accomplish the same thing, but in very different ways.

If you want to make a GAME, I highly suggest looking at an LPMUD, because the heavy lifting has already been done for you. There are also other hybrid systems like NakedMUD (C and Python) that fall somewhere in between those extremes. If you want to code your own DRIVER, by all means have fun. Just realize that hundreds of others have also marched down that path, and the corpses of their work litter it. Most people get about to the point of having rooms and simple combat, and then they run out of energy as the sheer volume of details you need to handle becomes clear.
14 Feb, 2014, Idealiad wrote in the 3rd comment:
Votes: 0
Hey duanuys, I came across an interesting site recently that you might find useful,

http://reboot-mud.readthedocs.org/en/lat...

It's not C++ but it's a decent start on the concepts.
19 Feb, 2014, duanuys wrote in the 4th comment:
Votes: 0
quixadhal said:
I realize you're comfortable with C++, but I'll still suggest you think long and hard about using it for a text MUD. Even using std::string, C++ doesn't have a native string type, and manipulating text is still a pain in the arse… and that's what you'll be doing 95% of the time.

As for how existing MUD's work, the core of a Diku-type game is found in comm.c. Usually a function called something like game_loop(). Read that and understand it. The simplified version would look like:

while( !done) {
pull incoming socket data into buffers
handle player input
do combat updates
do environment updates
flush outgoing buffers to sockets
}


An LPMUD (which I always suggest looking into) is a bit different. In an LPMUD, the driver itself is a language interpreter that handles socket connections and file I/O. It runs LPC soft-code to create and run the game universe. At its core, it basically does this:

Quote
At boot time:
load the "master" object, which has to have a function to handle new connections.
load any other objects which were listed as "preload" objects.

At run time:
When a new connection appears, call the function in the master object to handle it.
Typically, this creates a "user" object which can then receive input from the socket and be the player object.

When data comes in on a socket, call the receive() function in the object attached to that socket.
This is the LPC object created by the new connection handler. The receive function is called with the data
from the socket, and it does whatever it does with it.

Handle any pending call_outs.
A call_out is a delayed function call form an LPC object into another LPC object. It can be scheduled for some time
in the future, or as soon as possible. The LPC driver enforces a limit on how long a given object's code can run, so to
prevent resource abuse (or accidents), it's not uncommon to break your code up into chunks and have each chunk
schedule the next chunk as it finishes (like an old batch system).


As you can hopefully see, they both accomplish the same thing, but in very different ways.

If you want to make a GAME, I highly suggest looking at an LPMUD, because the heavy lifting has already been done for you. There are also other hybrid systems like NakedMUD (C and Python) that fall somewhere in between those extremes. If you want to code your own DRIVER, by all means have fun. Just realize that hundreds of others have also marched down that path, and the corpses of their work litter it. Most people get about to the point of having rooms and simple combat, and then they run out of energy as the sheer volume of details you need to handle becomes clear.


Wow thanks. Out of everyone online that I have asked that question, yours is the most clear that doesn't give me a vague answer. Since posting this question, I have started to develop my mine game.. and I am not even where you said most people find themselves. I barely got through a simple program and began to foresee the sheer amount of data that needs to be handled. It also gets really frustrating when a single letter can devoid your program from compiling.. thats always fun lol. But nonetheless thank you for your reply it really helped. I think at this stage I will volunteer to become a imm on a MUD that someone has already made. Hopefully from there I can become a coder and learn as I go with people who know what they are doing. I suggested C++ as a coding base because that is my native language that I have to work with here at my work. I do extensive AutoCAD work, and the program is written in C++. Thanks again!
19 Feb, 2014, plamzi wrote in the 5th comment:
Votes: 0
duanuys said:
I think at this stage I will volunteer to become a imm on a MUD that someone has already made. Hopefully from there I can become a coder and learn as I go with people who know what they are doing.


That's a wise decision that few people make. The most successful coders and game designers followed exactly that path.

I further advise that you pick a game you are actually excited about, possibly one you have a prior relationship with as a player. That also helps a lot.
0.0/5