[Home] [Downloads] [Search] [Help/forum]

Register forum user name Search FAQ

Gammon Forum

[Folder]  Entire forum
-> [Folder]  MUDs
. -> [Folder]  MUD Design Concepts
. . -> [Subject]  New C++ codebase

New C++ codebase

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Pages: 1 2  

Posted by Nick Cash   USA  (626 posts)  [Biography] bio
Date Thu 06 Oct 2005 08:57 PM (UTC)
So, finally figured I would take on this task (after I do a few other things). My collge professor said I could do it for lab credit, so thats all well and dandy.

I just wanted to ask what some of you more experienced C++ coders would suggest on things. Anything I should be aware of? Know of some really nifty techniques? Perhaps some pitfalls to look out for?

Any tips in general would be nice. Thanks, as always. (yes, its been a while :P)

~Nick Cash
[Go to top] top

Posted by Nick Cash   USA  (626 posts)  [Biography] bio
Date Reply #1 on Tue 11 Oct 2005 05:12 PM (UTC)
Wow...not one thing?

~Nick Cash
[Go to top] top

Posted by Zeno   USA  (2,871 posts)  [Biography] bio
Date Reply #2 on Tue 11 Oct 2005 05:15 PM (UTC)
I can't offer many ideas right now, I just started taking C++ myself.

Ksilyan would probably have more insight than me, but he hasn't been around for a little, probably busy with life.

Zeno McDohl,
Owner of Bleached InuYasha Galaxy
[Go to top] top

Posted by Nick Gammon   Australia  (23,016 posts)  [Biography] bio   Forum Administrator
Date Reply #3 on Wed 12 Oct 2005 07:11 AM (UTC)
Wow, a direct question about something I have been mulling over for a while in my head. :)

Give me a day, and I'll put some detailed thoughts down.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Nick Gammon   Australia  (23,016 posts)  [Biography] bio   Forum Administrator
Date Reply #4 on Wed 12 Oct 2005 09:48 PM (UTC)

Amended on Wed 12 Oct 2005 09:49 PM (UTC) by Nick Gammon

You could probably do a lot worse than read these books. I got one locally, two from Amazon.

"Designing Virtual Worlds" by Richard Bartle

ISBN: 0131018167

Summary from Amazon:


Designing Virtual Worlds is the most comprehensive treatment of virtual world design to-date from one of the true pioneers and most sought-after design consultants. It's a tour de force of VW design, stunning in intellectual scope, spanning the literary, economic, sociological, psychological, physical, technological, and ethical underpinnings of design, while providing the reader with a deep, well-grounded understanding of VW design principles. It covers everything from MUDs to MOOs to MMORPGs, from text-based to graphical VWs.

The book gives a great treatment of design issues of MUDs and MMORPGs, starting with the history of the first MUD game written by Bartle himself.

If covers all sorts of things, such as world economies, character death, management of griefers, and heaps more. Plus, it has heaps of references to other works, including URLs.

"MUD Game Programming" by Ron Penton

ISBN: 1592000908

Summary from Amazon:


Develop your own Multi-User Dungeon games! Multi-User Dungeon games are still going strong. It's no wonder. They're easy to create and easy to access. They also have an additional appeal for game programmers. They serve as the foundation for today's Massively Multiplayer Online Role Playing Games. In order to create an MMORPG, you need to know MUD programming. Get ready to build your foundation! If you have a basic knowledge of C++, "MUD Game Programming" gives you everything you need to know to begin programming your own MUD games. The fundamentals of network basics are put to the test as you work your way through a simple MUD program. Put your new skills to work as you wrap things up with a more advanced, robust MUD. Pull out all the stops and test your creativity with the flexible aspects of your new MUD engine.

This book gives more technical detail than Bartle does, including code in C++, and an accompanying CDROM with the actual server source code on it. He presents two MUDs, a "simple" one and a more advanced one. The more advanced one uses Python as its scripting language.

There is heaps of detail in this book, including stuff like network code in C++, comments about world economies, examples of serialization (saving/restoring) and so on.

"Character Development and Storytelling for Games" by Lee Sheldon

ISBN: 1592003532

Summary from Amazon:


This is a book of ideas and of choices. Knowing which choices to make is not teachable. It's part of that creative instinct we call talent whose secret voice guides us every time we sit down at the keyboard. All stories are not identical. They are shaped by all those unique facets of the human beings who write them. All any writer can do when he wants to share his knowledge with others is be as open and giving as possible; and hope others can learn from that. You hold in your hands most of what I know about writing for games and much of what I believe and practice no matter what kind of writing I'm doing. It is meant to inform, to instruct, and maybe even inspire. It is as much about game design as it is writing for games. The two are virtually inseparable. The book itself has been designed as a quest. We are all of us on a journey toward a destination for which there is no single road. --Lee Sheldon, Author

This book is interesting reading too, and is much more about the design of the story rather than the details of implementation. The concepts presented here are more about "why would someone play my game?" rather than "how much gold will it cost to take the boat from City A to City B?".

In other words, you can have the most brilliant programming, hard-working admins, great room design, and still have no players because the "storyline" is not engaging. This book talks about that.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Nick Gammon   Australia  (23,016 posts)  [Biography] bio   Forum Administrator
Date Reply #5 on Wed 12 Oct 2005 10:04 PM (UTC)
Another thing you can look at is the "tiny MUD server" I released here on this forum a while back.


This gives you the basics of the network code, and a command-handler framework, that takes commands from the player and feeds them into the MUD. Using this as a basis will eliminate the initial tedium of writing stuff to handle incoming network connections and so on.

The post above explains how you would add new commands, and more questions for players creating new characters.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Nick Cash   USA  (626 posts)  [Biography] bio
Date Reply #6 on Thu 13 Oct 2005 04:29 AM (UTC)
Nifty. I'll look into the two books I don't already have. I have a ton of reading I need to do.

TinyMUD looks like a good way to start :)

~Nick Cash
[Go to top] top

Posted by Nick Gammon   Australia  (23,016 posts)  [Biography] bio   Forum Administrator
Date Reply #7 on Mon 17 Oct 2005 03:15 AM (UTC)

Amended on Thu 20 Oct 2005 09:40 PM (UTC) by Nick Gammon

My advice to anyone wanting to write a MUD server from scratch is:

Stop! Don't write any code until you have got a detailed design of your MUD. This doesn't have to be a technical design, but rather, what the MUD will offer to the player.

Why? I have tried the other way a couple of times, and it is a mistake. The "other way" is to start programming madly, and then after a few months, start trying to reach agreement with your other admins/developers about fundamental issues. The problem is these issues may conflict with code you have already written.

The issues described below can be considered by anyone interested in running a MUD - they don't have to be programmers. Unless you can write down some sort of answer to these questions you are not ready to start yet.

Here are some design points to consider:

Text or graphics?

  • Do you want a straight text-based MUD, or are you planning on requiring a custom client? If a custom client is required, you have doubled your work immediately, because you are writing both a client and a server.

Rooms or co-ordinates

  • Are you planning to have things that require know exactly where players are in relation to each other (rather than just "being in the same room")? If so, you probably need some sort of co-ordinates for everything, rather than just have room 1001, 1002, and so on.

    Things that might require positional information are:

    • Ranged weapons (when are they in range?)

    • Area-of-effect spells (what mobs are within 10 yards of the spell?)

    • Needing to be in front, or behind things (eg. for backstabbing)

    However if you do decide to do that (store co-ordinates for everything), the work load is immense. Here are some problems:

    • Room design is harder - not only do you need to design rooms, you have to place things in them exactly.

    • For anything that moves, like computer-controlled mobs, you need to work out things like pathing algorithms, so they can walk from A to B without going through walls, tables, rivers, and so on.

    • You need some sort of line-of-sight algorithm, so that a mob doesn't "see" a player, who might be very close, but with a solid wall between them.

    • Decisions about whether aggressive mobs see and attack a player can no longer be a simple test of whether they are in the same room, but based on distance apart, line of sight, whether obstacles are in the way (like canyons, rivers etc.).

    • It is hard to describe positional information in a text MUD anyway. You will probably need a graphical client.


  • Are you planning scripting, so that room designers can write simple scripts to make things happen without having to change core code (eg. to make a mob's behaviour be conditional on what you are carrying). If so, which language? Is it compiled or interpreted? What happens with an interpreted language if a runtime error occurs?

Resets / repops

  • What is your policy for resetting, or repopulating, areas once mobs have been killed by players? Every 15 minutes? Or after a certain interval elapses after a mob dies it is replaced?

  • The same question arises for resources that players need. For instance, if they have to collect an orb from a mine, and one player takes it, how long until it is replaced?


  • Do you want fighting? If so, what are the rules? Do attacks take time (eg. a slow sword swing, or a fast dagger strike)? Can strikes be resisted, dodged, parried, evaded, and so on?

  • Do you have player-killing? (player vs. player). This can make your MUD more exciting, however you need to design in the rules. Can anyone attack anyone else? It is consensual? Can you only attack an opposing faction? What about NPCs (mobs)? What is to stop level 100 players wandering around killing your newbies 5 minutes after they connect to the game?

  • Do you have magic spells? If so, how do they work? Do they take time to cast? Can they be interrupted, resisted, repelled, reflected? What do they consume (eg. mana).

  • What "cooldown" do spells or abilities have? For example, a powerful spell might only be useable once every 10 minutes, thus you could say it has 10 minute cooldown.

  • Can you run from a battle? With what degree of success? Can you be chased? If so, how far?

  • Can combat occur in towns or "safe places"?

  • Do you have "area of effect" spells? (ie. a spell that hits all mobs, not just one)

  • Can characters freeze others in place (eg. to escape)?

  • Can characters hide (eg. to sneak past something)?

  • What happens if a player loses his/her connection in the middle of combat, intentionally or otherwise? Does their character keep fighting (or being attacked) until it is dead? It is removed from the game after 30 seconds?

  • If multiple characters are attacking one mob, which one does the mob fight back? The weakest? The first to attack it? The last to attack it? The one causing the most damage? The one who is nearest to death? The one who is healing others?

Races / classes / factions

  • Do you have different races (like orcs and goblins)? If so, what makes one different from another? What are you doing to make them balanced, so that one race is not all-powerful, or too weak?

  • Do you have different classes (like mages and warriors)? If so, what reason would players have for choosing one over the other? What are you doing to balance them? You probably need a paper-rock-scissors model, so that no one class (or race) can defeat, or be defeated by, all other ones.

  • Do you want different factions? (eg. good/evil, humans/martians, alliance/rebels). Factions can add interest to a game because they give a natural "side" that players can join. However if you have different factions then you have extra complexity (for example, deciding who fights who), and you would need cities/towns for each faction.

Character attributes

  • Most MUDs assign some sort of attributes to the characters (eg. strength, dexterity, wisdom, luck). What ones will you have? What does each one do? Try to be specific, not just "wisdom makes you smarter". For example, "each point of wisdom gives you 10 mana", or "each point of strength adds 1 extra damage to a sword-wielder".

  • How are the initial attributes assigned? Randomly? A table per class / race?

  • How do players increase their attributes? Wearing equipment? Going up levels? Spells? Do they choose themselves what attribute is increased? (eg. each level they may be assigned 5 new attributes to distribute as they see fit).


  • Work out in advance what the rules are for applying each attribute, not just vague talk about how "dexterity will be useful". For example:

    • Each 10 points in dexterity increases your chance to dodge a melee attack by 1%

    • Hit points lost in a melee attack = (attacker_attack_rating - defender_defense_rating) * weapon_damage_amount + dice_roll (2, 3)

    Doing this will help focus on what attributes you want in your MUD, and what they will be used for.


  • Do you have transport systems (cars, boats, trains, aircraft, portals, teleports, horses)? If so, how do they work? What do they cost? Can anyone use them? What happens if a player logs out while on a boat?


  • What happens when a character dies? Does it lose money, experience, equipment, or suffer damage? How long before it can be played again? Any penalties?

  • Can players resurrect other players? What are the requirements? How long does it take? Does it consume a reagent? Have a cooldown time?


  • Can players form groups? Is there a limit to a group's size? What happens if the group leader leaves? Is there a limit to level differences? (eg, no grouping level 1 players with level 100 players)?

  • Can players automatically follow other players?

  • What are the rules for looting mobs once killed (inside a group)?

  • What are the rules for gaining experience when a group kills a mob, or completes a quest? Do these vary if some group members are not in the same room? Or a long way away?

  • If a group kills a quest mob (eg. a boss) does the entire group get credit?

  • If a quest mob has a quest item (eg. a pendant) does the entire group get it, or only the player who looted the mob?

  • If a group kills a mob, but a character in the group dies half-way through the fight, does it get credit for the kill? If there is a quest item does s/he get that too?


  • Can players form guilds (groups with some common purpose)? How? At what expense? Are there membership limits (eg. only orcs).

  • What requirements are there to form a guild? Disband it? How do players get added to a guild? Removed from it? How do they remove themselves? Remove someone else? Do they have a guild meeting place?


  • Think about your game economy. MUD games tend to suffer from inflation because there is an unlimited amount of resources that can be obtained (you kill a mob, it comes back 5 minutes later, and mobs generally carry cash or valuable items). You need to design in "cash sinks" - ways that force players to spend their cash so there isn't too much of it around. For example, charge for transport, repairs, training, food, etc.

  • Can players trade with each other? (eg. sell a sword for 5 gold pieces). If so, how do they do that? Do they have to be in the same room or close by? If not, how would they do it? Do you have a mechanism to avoid cheating? (eg. a player pays his 5 gold but is not given his sword).

  • Do you want some sort of auction system? This could let players put goods up for auction, and let them sell to the highest bidder. You need to design the rules for such a thing.

  • How do players buy/sell goods? From shops? Wandering salesmen? Can they sell anything to anyone, or does it have to be a dealer in that product? What is the buy/sell markup? A fixed percentage or set for every object in the game? Are shops always open? Do they run out of goods? If a player sells something to a shopkeeper, is that then available for someone else to buy?


  • Do you have quests? (eg. "your task is to kill 5 kobolds", or "please take this letter to the mayor"). How are they defined (eg. in a script)? What are their rewards? Does one quest depend on another?

  • If you choose to have quests you will probably need to spend hours (if not weeks) designing a suitable set of quests, for each level that players will be in your game.

  • Can quests be shared with other players?

  • Who gives out quests?

  • Who accepts completed quests?

  • How do you abandon a quest? Re-gain it?

  • Is there a limit to the number of quests you can do?


  • Do players need to train to learn things? From where? At what cost? What are the prerequisites? Can they learn everything, or do you limit them to choices (eg. you can learn 5 out of the available 10 skills)?

  • How are skills developed? Through practice? Trainers? Purchasing things?


  • Can players learn things (eg. metalwork)? Where do they learn? What materials are required? What cost? What can they make? What use are the made products (eg. swords could be sold). You may need to define, for each skill that players can learn, something like this:

    • Skill level required to make it.

    • Do they know how to make it? (eg. have the recipe)

    • What reagents are required? That is, the things that are consumed in the process (eg. leather to make shoes)

    • What tools are required? That is, things that are needed but are not consumed (eg. a leather-worker's needle).

    • Do they need to be at a certain place? Eg. a forge for metalwork, a fire for cooking.


  • Most MUDs have objects - that is, things that can be picked up, carried around and used. What are you planning to have? What will they do? Where do players get them? What use are they? Can they be bought or sold? Can they be made?

  • Does equipment wear out? To what rules? How is it repaired? At what cost? Where?

  • Can objects be discarded (left lying on the ground), or destroyed?

  • How many objects can a player carry at one time? Can they purchase or obtain extra capacity? Is capacity based on weight, number, volume?

  • What attributes do objects have? An object might have:

    • Armour class (wearing it increases armour)

    • Attack rating (wielding it gives X amount of attack, eg. a sword)

    • Attribute modification (eg. wearing it increases wisdom)

    • A use - eg. using a key unlocks a door, eating food increases health

    • Value - how much you can sell it for

    • Wear and tear - how much damage it has suffered

    • Minimum level number to use it

    • Restrictions on use - eg. only mages might use wands

    • Can a player carry more than one of it? If so, is there a limit?

    • Is it a quest item? If so, for which quest(s)?

    • Does it disappear if the player disconnects?

    • Can it be sold? Traded?


  • Do you have an in-game mail system? If so, what can be sent? Messages? Objects? Money?

  • Where are mailboxes? Does it cost to use them?

  • How long does mail take to be delivered?


  • Do you have a "bank" or similar storage place where players can deposit things that they cannot fit into their inventory?

  • How much can they store in the bank? Where is it/them? How much does it cost to use it?


  • Do you log everything that happens? Eg. what players say, who they kill, what trades are occurring?

  • In the event of a dispute, can the log be easily perused?


  • Do players have levels? (eg. you start at level 1, and hope to reach level 100). How many? How do you advance levels? What advantages are there to being a higher level?

  • What do players do when they reach the highest level?

Making money

  • Do you - the developers of the game - plan to make (real) money from it? Are you going to:

    • Charge by the hour to play?

    • Have a monthly subscription?

    • Have a free trial period?

    • Sell in-game goods or services for real money?

    • Sell the game itself (to other aspiring MUD admins)?

  • Who collects the money, and how?


  • Who "owns" the game? If you are developing it from scratch, using a team of people, what happens if one leaves? Who (if anyone) owns:

    • The name of the game?

    • The computer program?

    • Any scripts used in a scripting language?

    • The room design (eg. room descriptions)

    • Other designs (eg. quests, object design)

  • Can someone leave your development team, take a copy of everything, and start a competing game?

Running the game

  • What server are you going to run it on? A commercial server or the private one belonging to one of the developers?

  • How are you going to administer it 24 hours a day / 7 days a week / 365 days a year? What happens if the chief (or only) programmer goes on holiday for a month and it crashes while s/he is gone?

  • Are you planning to have customer service people online all the time to help players? Will they be paid? How much?

  • What will you do to help players that are stuck (eg. in a room with no exits), or have lost all their goods through some bug (or their own fault)?

  • What method do players have to report bugs (eg. misspellings, or broken quests)?

Handling problem players

  • Eventually you will have a "problem" player. How do you deal with him/her? They may do things like:

    • Have an unsuitable name, like a swear-word, or a name that implies they are an admin.

    • Use abusive language.

    • Harrass or irritate other players.

    • Make life hard for other players by killing mobs that they are trying to kill or otherwise disrupting their quests.

    • Cheat, eg. by promising to pay for something and then not pay.

    • Exploit game mechanics or bugs to become super-powerful.

    • Camp out valuable resources or important mobs, getting to them before anyone else can.

  • You probably need some "self-help" mechanism for other players (eg. being able to ignore an annoying player), with a fall-back of being able to get help from a customer service person in extreme caes.


  • Do players create "accounts"? That is, a central log-in point for all of their characters? Or is each character treated on its own? Is there a limit to how many characters one player can have?

  • Do you allow multi-playing - that is, one person controlling multiple characters simultaneously? It may be hard to stop simply based on IP address these days, as many IP addresses are shared by routers using Network Address Translation (NAT).

  • Do you "lock out" accounts for some reason (eg. non-payment, misbehaviour)?


  • Every game will start of with "newbies" - even if they are experienced MUD players they will be new to your game. What do you do to help them? You might have help files, easy quests, a more experienced player assigned to help them, "newbie" chat channels, and so on.

  • What do new players get to choose when they start playing? Character name / gender / race / class / description?


  • Players expect to talk to each other - do you have multiple chat channels? You probably don't want level 100 players having to put up with newbie questions in the middle of a difficult quest. However newbies will need help too. Do you "zone" your chats, so the chats are relevant to where people are (eg. zoned to the current town)?

Mob / NPC artificial intelligence

  • AI (artificial intelligence) is the programming that controls your mobs / NPCs (Non Player Characters) so they behave in a reasonably interesting way. How do you plan to have this work? Do all mobs behave the same, or do humanoids behave distinctly differently to (say) spiders?

  • If NPCs are spell-casters, what spells do they choose to cast?

  • Do NPCs run away if facing an overwhelming foe? If so, how far?

  • Do NPCs go and get help?

  • Inside what range do aggressive NPCs attack?

  • If the player runs away, does the NPC chase it, and if so, for how long?


  • How is your virtual world organised? Is it Earth-like with continents or seas? Science-fiction where each town is on a different planet? Where are the towns? What is the purpose of each one? How do you travel from one to another?

  • Is there weather? What does it affect?

  • Is there day/night? What does that affect? Are shops open all the time?

  • Do players need to carry torches (light sources) inside parts of the world in order to "see"? How long do they last? Where do they get them?

Instanced dungeons

  • Do you plan to have "instanced dungeons"? These are areas of the game where players (or groups) get their own copy of a particular area. The point of this is to allow a group to play on its own, and not find that someone else has just killed the boss, or is harrassing the group. If you do plan on this, then it impacts on game design, because you may need to record an instance number alongside a player's location (eg. player Nick is in room 1002, instance 3).


  • Can players have pets? (eg. a pet dog) Is it for combat or local flavour? If for combat, how is it controlled? What happens when it dies? How is it resurrected / replaced? Does owning a pet cost anything (to purchase, or for upkeep)?

Game balance

  • What can you do to stop high-level players helping their friends with inappropriate equipment? (eg. level restrictions on good gear).

  • Is each class / race / faction balanced? You can be sure that if players work out that "orc warriors" are much more powerful than everything else, then soon the game will be filled with orc warriors.

  • Are attributes balanced? If one attribute (eg. strength) has a disproportional affect on combat, then every player will put all their points in strength (if they can).

Making characters different

  • You will probably want some sort of system that makes players choose between mutually exclusive features for their characters, so that you don't have, after 3 months, a MUD filled with dozens of characters who are all the same because they have all "maxed out" on every possible attribute.

    Examples are:

    • Choosing different classes / races, where each one offers something the others don't

    • Choosing different professions, which offer different things in the game (eg. make armor OR make potions, but not both)

    • Wear different clothing, where a particular piece of armour can add protection or offensive power, but not both

    • Give players optional points to choose from, where they have to choose 20 out of a possible 50, so it is unlikely that every player will choose the same 20. Points might be spent in offense, defense, stealth, long life, short battles, and so on.

Saving things

  • Players expect their characters to be there next time they connect. When is game data saved? Every minute? Every time a player changes rooms? Do you save to lots of small files (eg. one per player, like SMAUG does), or one big file (like PennMUSH does).

  • Do you save to flat files or an SQL (or similar) database?

  • What is saved? If a player moves an object from one room to another does the game remember that?

  • If the server crashes and is restarted, what state is everything in? Are all mobs repopulated into their default positions? Or, does the game remember where they all were 5 minutes ago?


  • How do builders extend the game? Dynamically while players are online? Offline by editing area files?

  • Do you have some sort of "builder interface" used only by builders to extend the game while it is running?

  • Do you provide some sort of web-page interface for builders?

  • Does the game need to be restarted to incorporate additional content?

If I have forgotten some points, please feel free to post your own ideas below.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Nick Gammon   Australia  (23,016 posts)  [Biography] bio   Forum Administrator
Date Reply #8 on Mon 17 Oct 2005 03:49 AM (UTC)

Amended on Fri 01 Feb 2013 06:27 AM (UTC) by Nick Gammon

Having said all of the above, my initial recommendations from a coding perspective would be:

  • Write in C++ using gcc. This is a cross-platform compiler, you can use it on Windows, as well as on Unix or Macintosh.

  • Use the Standard Template Library (STL). This is a C++ library that greatly simplifies maintaining things like linked-lists, or maps (a map might be used for looking up a player name from all connected players). Using STL is covered elsewhere in this forum.

  • Have some sort of source-control system. I use CVS*. This lets you keep track of changes, and if you have multiple developers, makes tracking who changed what much easier.

  • For scripting I have been very happy with Lua. This is a cross-platform scripting language that is very mature and powerful, as well as being fast with a small "footprint". It is very easy to incorporate into your program, both calling Lua scripts from the server, and providing "call backs" so that Lua scripts can call server code. Call-backs might be provided for things like sending text to the MUD player, disconnecting players, and so on.

    Also I think now that Lua provides a very flexible container model that would be very useful for MUDs, namely its "table" data type. Tables in Lua are associative arrays (that is, arrays of things that can be looked up by name), and tables can contain other tables.

    Thus, a Lua table might store all connected players, and for each player there is a table entry of all its attributes. Things the players is carrying around (its inventory) would be another table within the player table.

    Lua data can be serialized both in and out without much trouble, so the effort of storing MUD data would be quite small.

[EDIT] * Nowadays (2013) I use git.


- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Nick Gammon   Australia  (23,016 posts)  [Biography] bio   Forum Administrator
Date Reply #9 on Mon 17 Oct 2005 09:04 PM (UTC)
Another thing to consider when writing your own MUD is to try to estimate how long it will take.

I have been on a couple of projects where, in October, a new MUD that is being developed talks about being up "by Christmas" - 3 months later.

Now, 3 months might sound like a long time, but when you start estimating building time, it isn't.

Just to show the general idea, let's estimate how long it would take a builder to add one room to the MUD. Adding a room would involve:

  • Designing it into the overall scheme of things

  • Giving it a name and description

  • Setting flags for it, like indoors/outdoors, light/dark and so on.

  • Populating it with objects (decorations, or things the players can use)

  • Adding mobs to it

  • Typing all the above into your room building program

Say, 15 minutes to do all of that, although that may be optimistic.

Now, estimate how many rooms you want. According to MudConnector, 3,000 rooms or less is a "small" MUD, but let's start modestly, and assume we are doing a small MUD.

My experience has been that developers of a new MUD talk about a "new, huge, great" MUD, not a small one, but we'll assume we start small.

Now, at 15 minutes per room we can do 4 rooms an hour.

That's 750 hours for room design. How many hours a day can you spend at it? Unless you are working full-time on the MUD, probably 5 hours is a reasonable estimate. That's 150 days. Even if you are working full-time on the MUD, you need to spend some time answering emails, and working on other aspects of the MUD.

Now assume you work at it for 6 out of 7 days a week. This allows some time for doing other things with your life.

150 days at 6 days a week is 25 weeks.

So the upshot is that the room building alone will take half a year.

Of course, if you have 2 or 3 builders working simultaneously then that time can be reduced, but you will be trading off to a certain extent the extra people, with the time needed to coordinate your efforts.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Nick Gammon   Australia  (23,016 posts)  [Biography] bio   Forum Administrator
Date Reply #10 on Sun 23 Oct 2005 11:40 PM (UTC)

Amended on Mon 24 Oct 2005 09:47 PM (UTC) by Nick Gammon

Below are some thoughts I had when working on a MUD server a while ago. You may not agree with everything below naturally, but at least consider the various aspects of combat / effects described below. They may give you ideas that will change the way you develop your MUD server. It is much easier to design things like this in from the start, then writing a combat system, and then going back and rewriting it because you hadn't allowed for something like casting time, or effects that occur over time.

Fighting, spells, potions, scrolls – all actions?

After writing some fighting code I have started to wonder whether fights, spell-casting etc. are not all part of some generic “action you take”.

For a start, it seems that fighting and casting damaging spells are variants of the same thing:

  • They require knowledge (eg. swordsmanship, or the particular spell)
  • They consume something (eg. arrows, mana, damage to sword)
  • They take time to do
  • The may or may not succeed (eg. the arrow may miss)
  • The target might resist it (eg. armour, spell resistance)

Then we consider that a beneficial spell (eg. heal) is actually very similar to a damage spell (eg. fireball), except that one raises HP whilst the other lowers them.

Then you have things like scrolls, potions, wands, traps etc. which effectively do a similar thing.

Also, walking around is effectively much the same:

  • You require something (to be awake)
  • You consume something (movement points)
  • It takes time to do (depending on the terrain and room size)
  • It may not succeed (because of a locked door)
  • It results in a status change (you end up in a new room)

Now it seems time-consuming and inconsistent to have hundreds of lines of code in the server which all do similar things:

  • spells
  • movement
  • fighting
  • healing
  • scrolls
  • potions

This leads me to propose that all of these things be defined as variants on a single thing – an “action” – that has some sort of “effect”.

Actions vs. Effects

To explain this last point a bit more, it seems to me that there are two major things here:

  • Actions – something you do
  • Effects – what happens when you do it

The distinction is important, I think. An action may or may not have an effect, for instance. You fire the arrow but it misses. You cast the spell but the target is immune. You try to open the door but it is locked. However a given effect (like “cure”) might be caused by different actions (potion, spell cast, healer).

Think of an action as a “verb”, and the effect of the action as a “noun”.

Effects and their resolution

I think the neatest way of separating actions from their effects is to define an action as having a “parcel of effects” (which might be a single effect).

For example, firing a poisoned, fiery arrow at someone might have the following effects (if it hits):

  • They are physically hurt by the arrow
  • They are poisoned for 60 seconds
  • They take fire damage

Whether any of these effects actually happen depends a bit on the target rather than the person firing the arrow:

  • They may be wearing armour and not be affected by the arrow
  • They may be immune to poison
  • They may be immune to fire

To work all this out we need an “effect resolution phase”, described later.

For now, let’s consider these three steps:

  1. Action
  2. Effect resolution
  3. Effect


Actions are things that characters (players, mobs) do which may or may not have an effect. Actions may even be initiated by things (eg. traps, portals). Actions may be directed at things too, eg. you attack a door in an attempt to break it open.

They have the following components (not all may apply in every case):


You need basic knowledge to use something (eg. swordsmanship, knowing a particular spell, swimming, climbing). You have the knowledge or you don’t. This knowledge may be innate (you have it immediately), taught (learned), purchased, acquired, bestowed etc.

Some knowledge may have pre-requisites (eg. require a level, need to learn one spell before you can learn another).

David knows “cure light wounds”.
John can swim.
Nick can pick locks.


Skill is a measurement of how well you can apply the knowledge. It may improve in time. Your skill level will affect how well the action is applied (chance of success).

bow and arrow require dexterity
swords require strength
spells require intelligence


This measures how “hard” (or much) the action will be. For a sword, it might be how hard it hits, for an arrow how accurately it lands, for a spell how much power is in the spell. For movement it might affect how fast you walk.

bow and arrow – accuracy
sword – strength
spell – magic power
walking - strength, stamina
negotiation - charisma

Consumption (reagents)

The action will consume something - a reagent. If you don’t have (enough of) it to start with you cannot perform the action.

bows and arrows – arrows
swords – stamina, wear-and-tear on the sword
spells - mana
scrolls - the scroll itself
potions - the potion (or some of it)
movement - stamina or movement points
making a shirt - cloth

Requires - object (equipment)

Some actions may require the possession, equipping, or proximity to, an object. This would be different from an object that is consumed. For example, the bow is not consumed by firing an arrow.

archery - bow
spell - a wand
sailing - a boat
locked door - the appropriate key
mining - a pick
smelting - a forge
fishing - fishable water

Requires – flags

The enactor may need one or more “status flags” to perform this action. Some actions may require a “room flag” to be set.

to do most things you need to be awake.
to use a weapon you must be fighting
to swim you may need to be in a room with water in it
to fly you may need to be outdoors
to dig you may need to be outside where there is loose soil

Inhibit - flags

Some “status flags” will inhibit the action. Some “room flags” will also inhibit actions. For example, a “peaceful” room may inhibit fighting, a “quiet” room may inhibit spell casting.

sleep would inhibit most actions
silence would inhibit spell casters
blindness would inhibit archers

Performing an action

Preparation time (casting time)

This is the time needed to prepare the action.

fitting an arrow to a bow requires 2 seconds
preparing a spell requires 3 seconds

Interruption of action

It might be possible to be distracted during the preparation phase. The caster may be slowed or cancelled by interruptions, such as an attacker hitting you while you are casting a spell. These interruptions might simply extend the preparation time, or cancel the action altogether.

the kobold hits you, delaying the spell-cast by 1 second
the gnoll stuns you, cancelling the action
the mage silences you, making spell casting impossible for 5 seconds

Chance of preparation success

After the preparation time elapses you may be ready to perform the action. At this stage this is unaffected by the target. For example, you may spend 10 seconds preparing a spell to be cast at a target that happens to be immune to it.

Preparation success would be related to your skill level in this action.

Nick has 40% success of fitting an arrow to his bow.
David has 70% success of preparing the spell “fireball”.

Launch the action

This “commits” the action, so that it is performed and cannot be revoked. Any consumption cost is now incurred (eg. mana, arrow, wear-and-tear). Once the action is launched the enactor can start doing other things, once the recovery time is up.

Nick fires the arrow.
David casts the spell.
John walks East.

In-transit time

This is the time taken for the action to “reach the target”, or “be performed”. This may conceivably vary depending on the circumstances (eg. casting a spell on yourself may be quicker than casting it on someone else).

The arrow speeds towards the target for 3 seconds.
The fireball takes 2 seconds to reach the orc.
John takes 5 seconds to walk East.

There might be a case to be made that walking takes “preparation” time rather than “in-transit” time. I’m not sure about that.

Recovery time (cooldown)

This is the time taken for the action-taker to recover from the action. The preparation time and recovery time combined are basically to stop actions occuring ridiculously quickly.

During the recovery time the action-taker (enactor) may be limited in what s/he can do until recovery is over.

Nick rests after firing the arrow for 3 seconds.
David’s mind is a blank for 8 seconds after casting the spell.
John sits down after walking East.

Various actions may have individual cooldown times. A powerful spell may have a 10 minute cooldown, however a normal spell may be able to be recast immediately. You will need to consider whether various similar spells share a cooldown timer. That is, casting spell A also invokes the cooldown timer for spell B.

To stop players simply quickly switching between spells (or other actions) in order to defeat the cooldown mechanism, you probably need a "general cooldown" which is a short delay after every action, that prevents another one from occuring (say, 1/2 second or so). Otherwise players may program their clients to fire off 100 spells in 1 second.

Effect of action

After the in-transit time, the “action” has now (almost) reached the target.


The action may miss the target and do nothing. The chance of a miss would be dependant on the skill of the attacker, independent of the defender (unless the defender simply runs away).

The arrow misses the orc.
The spell misses the kobold.
John leaves the room before the fireball hits him.


The target may dodge or defend against the action. (The “miss” described above might be a variant of defense, although it seems to me that a badly-aimed arrow might miss even the most stupid creature).

Dodging would be dependant on the skill of the defender rather than the attacker, so this is separate from the "miss" calculation.

Alternatively the defender could block the attack, say by using a shield, or some sort of magic shield. The blocking could reduce the attack amount (eg. you block 20 out of 40 points of attack). Since blocking is effectively absorbing an attack onto a shield, the act of blocking should probably increase the wear amount for the shield.

There could be a formula for the “chance to hit” being a combination of the attack rating of the attacker, the defense rating of the defender, and their respective levels. The formula may be different for spells (and doors) but there would be cases where the action is ineffective.

The arrow glances off the orc.
The spell has no effect.
The door cannot be opened.
The lock cannot be forced.


Finally, assuming the blow has reached the target, and not missed, been dodged or blocked, there is a final mitigating factor - the armour of the defender. Armour may only defend against certain attacks (you would need to define those), for instance armour may not defend against magic, or being garotted.

Assuming the attack is the sort that armour defends against, then a simple muliplication of the armour defence amount by the amount of the attack should give the reduced attack.

You are hit for 40 hp.
Your armour absorbs 30%.
Resulting damage is 21 hp.


If the action reaches its target its initial force (the action “force” as described earlier) may be modified for this particular target, based on its resistance etc. For example, a “ring of fire” cast into a room may affect creatures differently depending on what they are.

The orc is susceptible to fire and takes double damage.
The fire-worm absorbs the fire and becomes more powerful.
The gladiator resists the fire and takes half damage.
The metal box is immune to fire.
The ghost is immune to physical damage.

We will cover this later under “effect resolution”. Suffice to say that at this point the action has “succeeded” or “reached the target” and now the effects attached to the action need to be resolved.

Multiple effects

Actions may be defined as having multiple effects (see below for the description of the “parcel of effects” idea).

For weapons that deal a “double blow” this could be simply implemented by attaching two “hit” effects to a single action.

Effect – what the action does

Finally we reach the outcome of an action – the effect it causes. Without some sort of effect there isn’t much point to having actions in the first place.

An effect can basically be described as a “status change” - something changes in the target or their environment.

Nick gets better.
Nick gets sicker.
Nick is blinded.
Nick is cured of blindness.
Adam is now immune from future blindness attacks.
David has more gold.
David has less gold.
David has more stamina.
Adam falls asleep.
David’s accuracy increases.
John moves to a new room.
John obtains a “rod of healing”.
Adam learns “cure light wounds”.
Adam is no longer hungry.

To summarise, an effect might:

  • Increase or decrease a stat immediately (eg. HP, stamina)
  • Increase or decrease a stat over time (eg. HP gradually increases)
  • Set or clear a status flag (eg. blindness, sleep)
  • Provide immunity to future status changes (eg. immune to sleep)
  • Give you something (eg. an object, gold, a ring, a scroll)
  • Take something away (eg. an object)
  • Give you knowledge (eg. a new spell)
  • Change your location (eg. move you to a new room)

Effect resolution

Actions will have a “parcel of effects” attached to them - that is, one or more effects that potentially occur when the action succeeds, as described previously.

Taking each effect in turn (for each target, if there is more than one), we would consider:

Elemental considerations

Some effects may belong to “elemental groups” which are major groups of “types of things” that happen. These would be expandable by the MUD, but might be things like:

  • Physical
  • Magical
  • Holy
  • Fire
  • Lighting
  • Water
  • Ice
  • Nature
  • Shadow
  • Gravity
  • Red
  • Green
  • Blue
  • White
  • Black

The “class of effect” (elemental group) may well affect the next section - susceptibility etc.


This will be a multiplier which indicates the susceptibility of this particular target to this effect. The multiplier may vary by elemental group (eg. be susceptible to fire but resistant to ice).

Normal - takes 1.0 times the “normal” effect (in other words, normal damage taken)

Susceptible – take 1.5 (or some figure > 1) times the “normal” effect

Resistant - takes 0.5 (or some figure < 1) times the “normal” effect

Immune - the effect does nothing (ie. the multiplier is zero)

Absorb - takes -1.0 (or some negative figure) times the “normal” effect

The multiplier might be fixed (eg. always immune) or some chance factor (eg. 20% chance to resist 50% of an attack).

The multiplier may be dependant on respective levels (or statuses) of the attacker vs the defender. For example, being attacked by someone much lower level may give you a much higher chance of resisting the attack, conversly, if the attacker is much higher level your chance of resisting might be much lower.


The target might reflect certain effects back at the originator of the effect (or someone else).

Triggers (bufs / debufs)

The target may be temporarily immune to the effect (as opposed to permanently immune because of its very nature). This could be because someone had previously applied a “prevent poison” or “sleep ward” spell, potion, or similar.

If so, the effect is cancelled, and the temporary immunity may be consumed (cancelled).

Putting this more generally, the target would be searched for “triggers” which match this effect. For example, a poison effect would search for “immune to poison” triggers.

This trigger would then modify the susceptibility/resistance/immunity/absorption for this particular effect. The trigger is then discarded.

A trigger might have "x charges" so that rather then being immediately discarded, a charge is used. For example, a "resist poison" trigger might have 5 charges, which resists 5 lots of poison, and then self-cancels.

Alternatively, a trigger might make you more susceptible to something (like poison) rather than less.

Triggers may be more general than that, I’m not sure how this would be implemented. For example, being hit with an arrow might teleport you somewhere else.

Power of effect

Some effects (those that change your status by a varying amount) will need to be given the power of the underlying action.


An swordsman hits you with his sword. He is very strong, so the action “carries with it” a power of 30.

The “power of 30” is passed down to the “sword blow” effect.

The target is susceptible to sword blows by a factor of 1.5.

The resulting damage is 30 * 1.5 = 45 HP, which are subtracted from the target.

Effect application

Once past the effect resolution phase, we now have an effect that is “going to happen” (ie. the target is not immune), and has its power multiplied by an appropriate amount. The effect is now applied to the target.

The different ways effects might be applied are:

Immediate stats change

There is an immediate stats change (eg. HP increases) and the effect is then discarded.

Immediate flag change

The effect is attached to the player’s effect list as a “status change”.

You become blind.
You fall asleep.

Change stats for a time (buf / debuf)

There is an immediate change to your stats (eg. stamina increases) which stays static for a period of time, and then terminates (with the status change reversing back to normal). This could be used for temporary increases to strength, stamina etc.

This is done by attaching the effect to the player’s effect list, so that checks for his current stats take into account the temporary extra (or less) amount.

Change flags for a time

The effect is attached to the player’s effect list as a “status change”, which wears off after x seconds.

You become silent for 30 seconds.

Gradual change

There is no immediate change, but every x seconds (say, every 5 seconds) a status change occurs (eg. HP decreases by 5 points). This happens indefinitely until “cured” somehow.

Gradual change for a time

There is no immediate change, but every x seconds (say, every 5 seconds) a status change occurs (eg. HP decreases by 5 points). This happens until the time limit elapses (say, after 30 seconds).

Implementation of time-based effects

All effects that occur over a period of time and then automatically stop can be implemented by adding an “indefinite” effect, and also adding a “cancel this effect” event to the event queue. Once this event fires the effect will be removed (if it hasn’t already been removed by other means).

Trigger effect (bufs / debufs)

A “trigger” is installed which is searched for by other effects. (eg. “silence ward”) might have a chance of defeating the “silence” effect.

Trigger effects may be:

One (or more) shots (once used for x times they are discarded)
One (or more) shots, time limited (if not used after 2 minutes, they are discarded - during that time they can be used x times)
Unlimited (can be used indefinitely)
Multiple-use, time limited (can be used multiple times, but wear off after time)

Trigger effects may do various things if triggered.

Cancel an incoming effect (eg. “resist poison” cancels a “poison” effect)
Cause something else (eg. water-based spell causes bomb to explode)

Delayed effect

An effect may cause an action after x seconds.

The “death” spell will cause John to die if not removed within 3 minutes!

Implementation of trigger and delayed effects

Both of these are variations on a theme - an effect that happens later rather than now.

These can probably both be implemented as an effect that “converts” from its original type (trigger or delay) to its new type.

Removal of effects

Effects that occur over time (eg. poison, blindness) can be “cured” by defining a suitable “counter-effect” - one that removes it. This is really a different effect-type - the “remove other effect” type.

You are no longer blind.
You are no longer asleep.

Detection of effects

To see if a character has a “temporary status change” (eg. blindness, sleep) we would search the “effects list” for this player to see if that effect was present.

Giving things

An effect may be defined to give an object to the target.

The “cure hunger” spell gives Adam a loaf of bread.

Taking things

An effect may remove an object from the target.

The “destroy weapon” spell destroys your sword!

Transferring ownership

An effect may take something from the target and give it to someone else.

You steal a potion from the orc!

Acquiring money

An effect may transfer or create money.

The “pilfer gold” spell lets Adam steal 50 gold pieces from the goblin.

Acquiring knowledge

An effect may bestow knowledge.

You now know “cure heavy wounds”.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Zeno   USA  (2,871 posts)  [Biography] bio
Date Reply #11 on Sun 23 Oct 2005 11:43 PM (UTC)
Wow, thanks Nick. This'll help a lot for anyone. One question, where did you (or anyone else) learn sockets (in the programming sense)? In a college? Self-taught online?

Zeno McDohl,
Owner of Bleached InuYasha Galaxy
[Go to top] top

Posted by Samson   USA  (683 posts)  [Biography] bio
Date Reply #12 on Mon 24 Oct 2005 02:43 AM (UTC)
This is an immense amount of information! Wish I had read alot of this when I first got my hands dirty so long go, might have saved me some frustration :P

If you have a way to pin topics for eternity, this would definitely be worthy of such an honor so that it can be read by many more to come.
[Go to top] top

Posted by Conner   USA  (381 posts)  [Biography] bio
Date Reply #13 on Mon 24 Oct 2005 03:52 AM (UTC)
Incredible job, Nick.. if you were to build a mud following everything you've laid out here, it certainly sounds like it'd be a great game to play and a very flexible environment packed into a tiny code footprint. I'm with Samson on this, this is a lot of very clearly well thought out info that deserves to be preserved for as long as possible.

Come test your mettle in the Land of Legends at telnet://tcdbbs.zapto.org:4000
or, for a little family oriented medieval fun, come join us at The Castle's Dungeon BBS at telnet://tcdbbs.zapto.org
or, if you just want information about either, check our web page at http://tcdbbs.zapto.org
[Go to top] top

Posted by Nick Gammon   Australia  (23,016 posts)  [Biography] bio   Forum Administrator
Date Reply #14 on Mon 24 Oct 2005 09:14 AM (UTC)
Thanks for the compliments, I hope it helps.


One question, where did you (or anyone else) learn sockets (in the programming sense)? In a college? Self-taught online?

Self-taught certainly. From memory, I inspected how existing MUD servers worked to get the general idea, and then read in detail how the various socket routines are supposed to work.

Then I wrote some small servers myself from scratch, carefully reading the descriptions for the various routines (like socket, listen etc.), omitting lines I couldn't see a use for, to get compact, clean code (as far as possible).

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.


This is page 1, subject is 2 pages long: 1 2  [Next page]

It is now over 60 days since the last post. This thread is closed.     [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.


Written by Nick Gammon - 5K   profile for Nick Gammon on Stack Exchange, a network of free, community-driven Q&A sites   Marriage equality

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( https://gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Hosted at HostDash]