I Could Use Some Advice

I'm still learning C++ but I have the basics down for now.

I want to write a MUD in C++ and I want to know what a sample code of a MUD would look like?

If someone could post one here that would be amazing.

Thank you.

-Nos

I'm not 100% sure what you mean by MUD but I wouldn't jump in to deep most peoples first games are like tic tac toe or hangman. Build experiance on small stuff before jumping into large projects. Read source codes that other people have made to find tricks and techniques.

MUD = Multi-User-Dungeon.

It's a TEXT based game. No graphics.

The first complication that springs to mind about a MUD is that it involves networking. Have you done any client/server socket code? You will need to.

Unless you mean a single user game akin to a MUD, ie, a text adventure. Then you don't need to do any networking, but also, you do not need to bother looking at MUD code, because that is not quite what you are looking for.

A text adventure is probably a pretty good C++ beginner project.

Yeah I know all about the networking but for now I'm going to make it just for me to use.

I dunno any sources of code for this, but I haven't googled.

IMO, you're better off just doing a bit of planning and figuring yerself. Think about it in OOP terms, like probably you need a "player" class and a "location" class.

The locations could be organized like a graph tree, using member pointers like this:

Code:

---

class location {
    location *north;
    location *south;
    location *east;
    location *west;

---

Maybe you want an up and down as well; alternately, you could just do this:

Code:

---

class location {
    map<string,location*> neighbourList;

---

Since locations may not always be connected in a simple compass like way. So here the string key might be "red door" and the value a pointer to the location thru the red door.

Try whipping up a few locations and connecting them together. Do not create them with the pointers*, just use the pointers to connect them. Your player can be pretty simple to start:

Code:

---

class player {
      location *current;

---

So current would be a pointer to the player's current location.

Then you want to use an event loop:

Code:

---

while (1) {


}

---

The game takes place inside the loop.

* these could all be references& too, probably that is better.

Alright, alright.

simple character, yes. Right now I just want to move around the world.

Thanks for the code. I'll tweak it and post the new code on here if you want.

Quote:

---

Originally Posted by nosfearatu

Thanks for the code. I'll tweak it and post the new code on here if you want.

---

You are always welcome to post code, altho IMO it's best saved for cases where you are having a problem ;)

You may also want to google "event loop", which is the basis of how virtually all realtime interactive (and many other kinds of) applications work. There is a wikipedia article:

http://en.wikipedia.org/wiki/Event_loop

altho it seems overly focussed on "messaging" to me. "Waiting for and dispatching events" can include, eg, frame generation in 3D games, or in the case of a text adventure, input from the user.

Before doing a MUD you need to do a single-player version of the dungeon. Get that working and design it with the idea in mind that you later want this to be a MUD. After all the multi aspect of it comes down to sending this or that over sockets and could easily be added later provided your design accounts for this. A message based approach is usually the most appropriate way to do this but certainly not the only way or necessarily the best way.

As to a single player dungeon you only need a map, some baddies, some treasures, some spells, some weapons, npc's if you want, etc. A single player dungeon crawl is an appropriate first game for newcomers and is a bit more exciting than tic tac toe and will offer more challenges. Don't worry about the graphics right now - just use text and get the system working. Then you can add the MUD portion and then you can add the graphics our output portion. If you program all this according to interfaces then it should be easier later to 'plug-in' new functionality or swap in/out various impls of your interfaces.