TerraMUDX [tMUX] User Community Forum Index
Author Message

<  Is there a DM on?  ~  MUD? What, Where, Why, How, Who?

wonko
Posted: Sat Feb 02, 2008 11:34 am Reply with quote
Site Admin Joined: 02 Dec 2007 Posts: 220 Location: ...somewhere outside the asylum
I am continually asked about MUDs and how they are mounted, so I thought I would puddle around in the topic here. Not sure if anyone is interested, we shall see.

[edit] I had better clarify: I am NOT interested in setting up a MUD for you, nor helping you establish yours, nor advise on how to code things for you. I am NOT going to link to any MUD made by you nor would I tolerate advertising of your MUD on mine. Call me territorial, paranoid or just plain mean - you would be right on all three counts. I have seen a MUD community ripped to shreds by such actions and would rather DELETE TMUX than let that happen again. [/edit]


Last edited by wonko on Sun Feb 03, 2008 9:23 pm; edited 3 times in total

_________________
wonko*
[*some assembler required]
View user's profile Send private message Visit poster's website
wonko
Posted: Sat Feb 02, 2008 12:11 pm Reply with quote
Site Admin Joined: 02 Dec 2007 Posts: 220 Location: ...somewhere outside the asylum
SERVERS

Acquiring a MUD Engine is fairly straight forward.

TMUX is originally based on the Mordor6.66 Engine - this can be downloaded at http://mordor.nazgul.com/treasures/

There are MANY codebases, including Circle, Diku, Smaug, Mirc, ROM, and many others - only a truly brave person would consider starting from scratch and writing the whole engine themselves.

GETTING the software is less important than having somewhere to PUT it.

MUDs require a SERVER - that is, a computer connected to the internet that other people can SEE and remotely connect to via Telnet. Your HOME PC might be suitable - if you have no problems with complete strangers logging in to that machine then go for it.

Few people would mount a MUD on a windows machine (of ANY flavour - regardless of how colourful it is) for a bunch of reasons - most importantly, the MUD process on a windows box is a system owned process - soo... if a user hacks a way through your MUD, then they enter your system at admin level - probably not an ideal situation.

Is HACKING an issue - certainly. Only an idiot does not consider security important. ANY service that invites unauthenticated strangers into a computer is liable to be hacked.

MOST MUDs are hosted on UNIX/LINUX machines, primarily because the codebase was originally written to work on linux/Unix, compile there and utilize the "out of the box" security inherent is a well maintained and sensibly configured 'nix box.

The HOST needs a C compiler [as most MUDs are written in C - that is a computer language - if this is news to you then that is also an issue] - Most MUD Codebases are written in ANSI C, which means standard compilers should cope with it fine [I think I use GCC on Linuz Redhat = Smeagol].

A MUD Server requires an OPEN PORT [or at least network translation (NAT) to fake this] - ALL game data to and from your players streams through this port - no port = no connectability.

Typically MUDs are fairly small system processes [on modern servers anyway] and generate dribbles of data traffic - bandwidth is ONE factor in LAG so your hosting solution would need to take this into consideration. The amount of RAM and processor action they consumes on the server is variable - each codebase is more or less efficient in this regard.

There are FREE hosting services available, I believe, if you look for them. They are ONLY useful IWHO if they provide FTP [to put files up on it] and SSH [secure shell access for you, the coder] and COMPILE rights [so you can edit and compile your code on that server] and EXECUTE rights [so you can run the resulting compiled daemon].

TMUX is run on smeagol - one of the school servers. NO, there is NO scope for you to put your MUD there, do not ask. Smeagol gives the impression it has ports open via NAT [network address translation]. It is behind a number of physical and software firewalls and that server withstands roughly 30 attacks a day, mostly from Bulgaria, Roumania and Korea] ... no, I am NOT joking. We assume NONE of them have yet been successful.


Last edited by wonko on Sun Feb 03, 2008 7:59 am; edited 3 times in total

_________________
wonko*
[*some assembler required]
View user's profile Send private message Visit poster's website
wonko
Posted: Sat Feb 02, 2008 12:22 pm Reply with quote
Site Admin Joined: 02 Dec 2007 Posts: 220 Location: ...somewhere outside the asylum
INSTALLING/RUNNING

MUD codebases usually come in zip [or gzip/tar] files - your first job is to get that file onto your server [typically using FTP]. then you need to EXTRACT the contents preserving the directory structure that was stored. Normally directories containing libraries, database elements and the actual code are kept separate.

You would then EDIT the code to suit your server details, address, port and so on. You would them COMPILE the code.

COMPILING simply takes the files full of typed instructions [SOURCE CODE] and turns them into a BINARY [or machine-runnable program = object code]. You then RUN the binary to activate the SERVER component of the MUD.

A MUD contains a SERVER component [the engine, database etc] and a CLIENT component [the user interface the player uses to play the game]. Clients are run on the PLAYERS MACHINE - clients talk to the server component.

MOST of the above stuff can be achieved by someone with LITTLE or no programming skills, but the ability to READ help files and follow install instructions.

Installing, compiling and running a MUD is the FIRST step. the next step is the big one.


Last edited by wonko on Sat Feb 02, 2008 12:41 pm; edited 1 time in total

_________________
wonko*
[*some assembler required]
View user's profile Send private message Visit poster's website
wonko
Posted: Sat Feb 02, 2008 12:26 pm Reply with quote
Site Admin Joined: 02 Dec 2007 Posts: 220 Location: ...somewhere outside the asylum
MANAGING a MUD

I would love to say I have got MUD management down pat, and provide you with guidelines that will ensure success, but that would be misleading.

Managing a MUD is as simple as nailing jelly to a tree.

Few young adults have the maturity to understand management of a multi-user environment, and confuse it with gathering their friends, granting them all admin rights and hoping things will work out.

A properly installed MUD usually comes with a stock standard ROOM, MONSTER and OBJECT database. Often there will also be communications, guilding systems and other things - you just need to work out how to get them working.

Making ANY change should be thought through with GREAT CARE.

TMUX offers NO management positons to students because of DESTRUCTIVE management practices that occurred in previous incarnations of the game, caused by a manager that ASSUMED a level of maturity and responsibility that was not there.

Power corrupts, absolute power corrupts absolutely. I have yet to meet a young adult who could resist the urge to gift friends and torment enemies.


Last edited by wonko on Sat Feb 02, 2008 1:06 pm; edited 2 times in total

_________________
wonko*
[*some assembler required]
View user's profile Send private message Visit poster's website
wonko
Posted: Sat Feb 02, 2008 12:40 pm Reply with quote
Site Admin Joined: 02 Dec 2007 Posts: 220 Location: ...somewhere outside the asylum
EDITING THE CODEBASE

Changing ANY standard functionality requires you to edit the SOURCE CODE, then re-compile, then re-run your binary.

A MUD is an HORRIFIC place to LEARN HOW TO PROGRAM.

MUD engines were NOT written by noobs, the coding conventions may not have ANY useful documentation and there may be NO available help supporting the changes you want to make.

IDIOTS make large changes without testing. NOOBs make cosmetic changes and pretend they know what they are doing. CODERS understand what something does BEFORE they change it. [wonko was both IDIOT and NOOB before finally becoming a coder]

MUDs are usually complex suites of FUNCTIONS, each of which do particular things [often each command itself is a separate function]. They interrelate in ways that are sometimes not obvious, even to an experienced coder - a change in one function CAN have a side-effect in another that may only manifest itself in an obscure set of game conditions [eg. a hidden player holding a quest object in a water realm room when an evil aggro monster enters at the same time as martial law is called during daylight hours when the room is flagged as dark always, when the player is wearing a particular piece of neck armor].

TESTING is important - EXPERIMENTING on your players is a great way to ensure you do not have any.

I would like to pretend this is straightforward - I have not found it so. Each codebase has it's own peculiarities. Read and understand before you edit is my advice - I do not care if you choose to ignore that advice but PLEASE do not ask me to help you fix something YOU have broken.


Last edited by wonko on Sat Feb 02, 2008 1:06 pm; edited 1 time in total

_________________
wonko*
[*some assembler required]
View user's profile Send private message Visit poster's website
wonko
Posted: Sat Feb 02, 2008 1:04 pm Reply with quote
Site Admin Joined: 02 Dec 2007 Posts: 220 Location: ...somewhere outside the asylum
CREATING A GAME ENVIRONMENT

Game managers that have games worth the disk-space they occupy are interested in creating a unique game experience. This usually involves CHANGING the ROOM, MONSTER and OBJECT database.

Serving up a bog-standard download game opens the game manager to all sorts of exploits - that is their problem.

A PLAN IS IMPORTANT. A theme, masterplan and some pre-thought is ideal and that takes self-control. Never underestimate the lure of releasing something before it is finished, or the urge to explain how something clever works as you see players struggle with it. Never underestimate the psycological blackmail you, the game manager, will be subjected to by your players fishing for clues and gifts.

FOOLS rush in and start building without some understanding of where their areas fit in the overall picture.

IDIOTS make stuff too easy to get therefore effecting game balance.

DIM-WITS assume that if there is an exploit possible, their players would _never_ use it.

TWITS assume that quality is less important than quantity, so build HUGE areas badly but rapidly and end up band-aiding forever to redress basic design flaws [or worse, change the gamespace under the playerbase].

NUMB-SKULLS ignore basic game tenets [like the game being suited to SINGLE player, yet letting a player have up to 5 characters on at once].

DICKHEADS interject into player conversations, or feel it is their responsibility to take ownership of all player behaviour on their MUD.

MORONS tell players where things are and how they work, making the actual discovery process unnecessary.

[and yes, wonko has been a foolish idiotiotic dim-witted twit, numb-skull dickhead and a moron in my time, prolly will continue to be because being otherwise requires superhuman self-control and you have to think out everything before you do it - really hard to do all the time]

I would like to say there is a QUICK way to make a quality game environment, but in my experience there isn't [some will successfully argue that tmux is not even so]. Attracting players and keeping them is a struggle with any game - a TEXTIVERSE has to work even harder as so many other games are more appealing offering easier to master game experiences for much less effort.


Last edited by wonko on Sun Feb 03, 2008 8:42 pm; edited 1 time in total

_________________
wonko*
[*some assembler required]
View user's profile Send private message Visit poster's website
wonko
Posted: Sat Feb 02, 2008 1:10 pm Reply with quote
Site Admin Joined: 02 Dec 2007 Posts: 220 Location: ...somewhere outside the asylum
GAME BALANCE

I used to have a really good help file on game balance, and I accidentally overwrote it with one on bank balance - doh!

Balance is a multi-faceted concept that encompasses many aspects of game play. In simple terms it can be thought of as reward for effort. In a multiplayer environment that simplification is complicated by many factors.

From the outset, TMUX was designed to have NO GIFTS. It was also designed in full understanding that players could have up to two characters working together on a goal. As such, some of the challenges are a little more rigorous for the SOLO player, but still not impossible as has been evideced by the many players who now enjoy solo challenges.

The rewards come in many flavours, all parts of devised schemes that assume two character groups minimum. It assumes progressions in levels that qualify players for increased rewards, but at higher risks.

Monsters are defined based on level - that is the amount of gold they carry [unless they are wildlife, then it makes little sense for them to drop money], XP they reward when defeated, proficiencies and stats follow a model meaning that the reward for defeating them is commensurate on the scale of the attack. Occasionally the stats will be atypical for that level, but always for a reason. As part of the masterplan, I decided on damage and reward ranges for monsters and have attempted to be consistent throughout. A traffic monster and a permed monster follow a slightly different recipe because the perm is a sitting duck.

Weapons are commensurate with the level of the monster that drops or guards them. The resale value is also part of that recipe, along with the damage range. It is rare that I make a waepon that is waaay outside the guidelines, and always for a reason.

Armor dropped or guarded follows an invented scheme based on the level of the critter that drops or guards it. I needed 12 levels or 'flavours' of armor and many of them are now evident in the game [cclot, cardboard, aluminium, fibreglass, stainless steel, carbon fibre, tungsten and so on]. I tried to think logically about what in teh scenario _could_ be used as armor and there are some things I am particularly pleased with. Their AC and number of hits are part of a graded range that is type-specific.

Striking a balance between reward and effort to gain teh reward is a fine edged sword. Make it too difficult and players will not bother. Make the reward too paultry and players will feel ripped off, make the spoils too bountiful and they will collect in huge mounds in killing fields. Availability of reward effects the game economy - tmux ecomony is a current challenge as I know I still have not got that right.

Availability of funds and things to do with those funds are an issue. It is clear that if you are rich, you will find it easier to stay so, if strapped for cash, you will struggle unless you are organised and thrifty. Player shops will add another element to tmux [coming with the country markets] and some vendor guidelines will be necessary else pricing wars and floods of otherwise rare items will hit the market from players who have the good sene to farm items they can get to. Previous incarnations of tmux had player shops and near the economic collapses of those games, rare or incredibly valuable items were being sold to noobs for nearly nothing. Still formulating a plan to control that.

It is interesting, from a social engineering perspective, that most aspects of human behaviour [good and bad] manifest themselves in interesting ways in-game. Entrepreneurs actively spruik rare wares or take noobs on tours of places they would otherwise never have seen, strut, preen, mark their territory and form alliances against perceived threats. Enterprising players make a killing collecting and selling [or bartering] goods, information has been bought and sold, addictive habits have been formed, characters have been levelled for money, graft, corruption and other things have all been present. Any game designer that thinks they can actually change human behaviour is an idiot.

I have also seen players that play for the thrill of the adventure, for the joy of working something out, for the love of the detail - these are the players that make the game creation process worthwhile. Some have seen the humour [I think I have put a lot of myself into the game], some have worked to understand the underlying stories, used logic to extrapolate solutions from a scattering of obscure clues and expressed real joy at playing. That is a major achievement because, at the bottom of it all, it is JUST TEXT and IMAGINATION - two awsomely powerful forces that coalesce into the player experience.


Last edited by wonko on Fri Jan 02, 2009 8:48 am; edited 2 times in total

_________________
wonko*
[*some assembler required]
View user's profile Send private message Visit poster's website
wonko
Posted: Sun Feb 03, 2008 8:14 am Reply with quote
Site Admin Joined: 02 Dec 2007 Posts: 220 Location: ...somewhere outside the asylum
WHY MORDOR?

I am often asked why I chose a Mordor MUD and not, say, a smaug or circle. The codebase makes sense to me, put simply. I can find what does what, and also for the most part HOW it does it. That is important to me because I am interested in changing the functionality not merely window dressing the game.

The features that can modify game objects [rooms, monsters, objects, players] are rich and varied, meaning it is possible to embellish them with lots of detail, control their actions in interesting ways.

Building is laborious and not glamorous in any way, but I can build using a combination of in-game commands and using a command-line editor - I like it as it makes sense to me.

I did NOT find the building experience in a CircleMUD a good one, and felt the features you could control for game objects was poor at best, reward schemes tortured and gameplay inflexible, but that is just me. I disliked the gameplay and interface in Smaug, Merc and ROM, so did not go down that path.

TMUX was not my first C coding experience, but it continues to be an interesting diversion. I _could_ program before touching anything, and before I edited anything, I worked out what it did. Again, that is just me, but have been around long enough to realise that it is really easy to screw something complicated by ignorance of the details. 'nuff said.

_________________
wonko*
[*some assembler required]
View user's profile Send private message Visit poster's website
Swampy
Posted: Mon Feb 11, 2008 4:59 pm Reply with quote
Member Joined: 22 Dec 2007 Posts: 247
Quote:
Player shops will add another element to tmux [coming with the country markets]


Does this mean that player shops are going to be introduced after all? Am just curious because for a long time i thought you were dead set against this.

"Availability of funds and things to do with those funds are an issue. It is clear that if you are rich, you will find it easier to stay so, if strapped for cash, you will struggle unless you are organised and thrifty"

Lol, this reminded me of a quote from the great gatsby. ( a book by F. Scot Fitzgerald.)

"there's just one thing, and nothing surer, the rich get richer and the poor get.... children"

_________________
From mud we come, to mud we return...
View user's profile Send private message
wonko
Posted: Mon Feb 11, 2008 5:37 pm Reply with quote
Site Admin Joined: 02 Dec 2007 Posts: 220 Location: ...somewhere outside the asylum
Players will be able to take out stalls in the market to sell second hand goods [loot] yes.

Players will have some control over the price, and will have some vendor guidelines to follow (or have their shop keeper license revoked)

It _does_ change the game dynamic, but players need something to do with their loot and their money, and the gamespace is large enough now to support this.

_________________
wonko*
[*some assembler required]
View user's profile Send private message Visit poster's website

Display posts from previous:  

All times are GMT + 10 Hours
Page 1 of 1
Post new topic

Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum