So as I begin learning C, I came upon a quandary that led me to think:
"I don't get it."
Not C. Not the code itself. I am thinking to myself, how does it all come together? So this code points at this code. This other code will make this text appear.
But, in a MUD, things are happening. You have an inventory. Items and people are moving from room to room.
How does all this code come together to form the game? Granted, I am in the early stages of learning C, but I am having trouble seeing the big picture, visualizing how all these items come together to form the game.
Is there a lamens understanding that someone can lay on me?
Quite a few people, over the years, have decided to start a MUD with the idea of using that experience to "learn C programming" or some such. Despite their simplistic interface, this is the equivalent of deciding to learn how to be a doctor by starting with surgery. A MUD is one of the most complex systems you're likely to encounter, so it's perfectly understandable to be overwhelmed by it.
At its heart, a MUD is a giant state machine. It has lots of code to keep track of the states of all kinds of things, many of which are directly tied to in-game objects, and many of which are not. The heart of the game loop will look something like this:
while( not done ) handle new connections send output to sockets get input from sockets process player input update combat update world enviornment periodic events
When you type 'inventory<RETURN>', that shows up as input on the socket you're connected through. There's code to move that to your command buffer, more code to parse it and make sure it's valid, more code to decide it was a command, and which chunk of code needs to be run to do that command.
That function will look through the data structure that's associated with your player object to see what you have in your "inventory", and what it should present to describe each item. Once that's done, it may also pass through some additional formatting for your particular choice of terminal output (color, HTML, etc), and finally be put in the output buffer for your player.
Next time through the loop, code will take the output from your buffer and send it out through your socket to be displayed by your client however it does things.
As to how such a monstrosity came to be…. well… many years and many people spending their time evolving things. :)
Quix gave a pretty good overview. The idea of a state machine is fairly important. It's easy to think of a MUD as a place where everything is happening concurrently, this player is fighting that monster, this player is managing an inventory, and so forth. But in reality, things are happening very sequentially. (There are extraordinarily few codebases that use multi-threading to make things truly happen concurrently.) Understanding this is one of the first steps toward understanding how things come together; then you start looking at a diagram like Quix presented and you see how the game gives the illusion of simultaneous activity.
I'd also agree that a MUD seems simple but is not. It is much easier to start by writing a chat server, and even then, it's easier to write simpler programs yet like a simple input/output loop that does something trivial. Writing a silly bank that lets you ask for your balance and add/remove money is a fairly standard early exercise.