Member Discussions

How difficult is it to include a non-combat character class in a MUD? How often is it achieved in a way that works?

One huge difference between pen-and-paper roleplaying games and MUDs is that in MUDS, it seems that usually all of the character classes are mainly different approaches to winning combat - the warrior kills with a sword, the mage kills with a fireball, the thief circles and backstabs, the cleric raises defenses and keeps hit-points up, and so on and so forth. It would be interesting to be able to play, say, a thief who focusses on thievery instead of butchery.

I am aware that there are MUDs where a non-combat character is viable if you wait around for an Immortal to come by and act as referee whenever you want to do something, but I'm talking about a system that doesn't require constant immortal fiat.

How difficult is it to include a non-combat character class in a MUD? How often is it achieved in a way that works?

I suspect not very often - the problem is that it's something which very much needs to be in the MUD (or mudlib) from day one. It's not something you can usefully bolt onto an existing combat-based MUD, because there have to be LOTS of non-combat opportunities, not just a few, in order for non-combat classes to become interesting.

To be fair, I think non-combat-related thief skills do get used quite often - picking pockets, and picking locks are both popular possiblities. It would be easy enough to incoporate a climbing skill in specific areas.

Other thief-type skills would also be relatively easy to incorporate such as a 'detect trap' or 'disarm trap' skill - except that, again, for that to work properly all of the traps in the game would have to be programmed sufficiently similarly for the skill to work on them.

Another problem is that the interaction between skills and situations is sometimes not implemented very logically. If you have a guard who won't allow a player through a gate, then typically that's all the code does - if you try and go through that exit, you are prevented from doing so, as long as the guard is in the room and alive.

What should happen is that the code should check whether or not the guard can actually see you. If you're invisible (or potentially even just sneaking) there should be a good chance that you can get past without having to engage him.

If you think about how one might actually try to get past a guard, there are countless possibilities besides killing him. Maybe your friend could engage him in battle and draw him away from the gate while you slip by unnoticed. Maybe you could throw a stick into the undergrowth a few yards away and he'll be dumb enough to go and investigate it so you can sneak in. Maybe you can generate an illusory monster so frightening he runs away in fear. Or perhaps you could bribe him. Or befriend/flatter him enough that he lets you through. Or disguise yourself as someone who is allied to his superiors, and present forged documents. Or seduce him. Or (given that this is fantasy) hypnotise him.

It's not too difficult to come up with a single instance of being able to use flattery/seduction/deception skills, but, if you want to have an entire character class dedicated to manipulation and deception then there need to be many opportunities to use its skills, not just a few.

One of the MUDs I'm a coder on has such a class called "Occupational", which basically lets you gain experience as a worker, from bussing tables to becoming a CEO of a company, but all in all the only purpose the class served was to make money and that's all it does. You use your CEO skill, you wait for about 30 seconds, and then you get a hefty salary for doing a good job if you succeed.

I'd like to see something advanced. Corporations that can own mines, refineries, factories, etc, and able to establish trade routers with NPC convoys. I have had this concept in the works for a long time but it's not been a priority.

This is why I like classless Muds so much to begin with. I can't imagine class Muds with crafters, diviners, planewalkers, and othe usually non-fighting character types to be able to survive in a class-based system without fighting skills.

When you setup a classless system, characters usualy get to blend what they want together.


OTHERWISE, you need to have some way of gaining experience and any other main feature of training, for these non-fighting classes to work with. Gaining experience in other ways can be a challenge, but I think it ultimately makes a more interesting Mud, and allows for mor ethan just hack and slash aspects.

Some people don't like to just fight. That's a truth.

I can definitely agree with others that non-combat classes has to be something included from the very beginning and given high-priority else you will slap on a miner class and the poor "miner" player will have nothing better than a little minigame that you slapped together in five minutes to keep them occupied "dig wall: You found a big piece of gold ore! Way to go!... Okay I'm bored"...

Attacking non-combat classes from the ground-up is the way to go entirely. The game world has to be designed to have a lot more depth to it than just kill, gain experience, make the high scores list, pk, sleep for five minutes and repeat. Coming up with creative ways for non-combatants to gain experience and "levels" is not difficult, obviously, the more skilled and practiced you are in your chosen area of expertise, the more your "experience/level" increases, so any action that is derivative towards that would work for an XP gaining action, though the progression should be slow and take some hard work before you become a master. However, in the event that you have a small p-base, which is the case with pretty much any mud fresh out of the blocks, even with the most involved non-combat system your "crafters" may grow bored because they quite frankly do not want to sit around and whittle toothpicks endlessly, so there has to also be other sort of minigames that any and all players are welcome to that will provide for an outlet from time to time, of course there should also be some minor benefit to doing these things so that they do not become trivial wastes of time.

But at the same time, one must take care to not forget about the combatants, since the majority of your playerbase will most likely still be drawn to that style of gameplay in the longrun. However, advancement for someone of the combatant way of playing should be similar in speed to that of crafters, in that if everyone takes a long time to be a master, it's not necessarily better to go one way or another, and there must also be certain protections put into place to protect crafters from mindless slaying at the hands of murderous PK'ers. While this does not mean flagging crafting classes "no-kill", but could be as simple as using realism to allow the crafting classes to defend themselves to some degree (the woodman's axe can be a very effective weapon afterall, or the blacksmith's hammer and would be historically accurate were they called upon by their town in the time of need) or making sure that those who do go on murderous rampages to a severe degree manage to have a run-in with the local authorities and have some sort of severe penalty for their bloodlust.

Anyway, I think I've lost track of where I was heading as so often happens to my cluttered mind, so I'll leave this post there with those thoughts and hopefully enlighten the conversation to some small degree.

Vopisk

Why does everything always have to take a long time to master, keeping people toiling away for years on end is also as tedious and booring as doing the same repeditive task over and over.
In 4 player years you should advance from apprentice to tradesperson and then in another 10 player years you should be concidered a master tradesperson, pretty simular as to real life.
I dont like the idea of classes, i think its too rigid and breeds an "I need to multiplay 5 alts to be complete" player mentality. Greater choice needs to be offered to players, let them choose what to be and how to be it, but at the same time dont let those choices restrict what and where they can go like happens in a traditional multi class system.
I think the POOL system(tm) is the way to go, every skill and spell is thrown into the pool and players can choose what ones to draw out and use.
Oh today i feel hack and slash, grab my armor and a sword and go slay everything in sight or today i feel like being a baker, find a field of wheat, harvest some grains, mill it into flour, and then bake that into bread or I hate the boss at the bakery, i quit my job there, head on over to the docks and sign up as a fisherman, all the while, using these trade skills working towards my next goal or level.
In everything simplicity is the answer. The more choice you offer to the players, the less likely they are to become boored, find ways to cheat or generally cause trouble.

Let me clarify slightly. FIrst and foremost it's key to remember that especially in today's ever expanding and changing MUD world when more complicated topics than the classic D&D structure are being attempted certain aspects of the game are changing as well. The key is not to force someone to play 200 hours of actual in-game time before they actually have a decent character, but likewise, if you are a crafter, your life will seem kind of hollow if you can max out your character in a good 4-10 hours as is the case with some (not all) PK driven games. When everyone is completely maxed out, that is, there is no further way that they can advance, that is what brings boredom and player apathy and more alts than actual players in your MUD. Character growth should be a 'lifelong' aspect of your game in order to always provide for a different experience.

To offer an in-game mechanical view of this, imagine that we do have a classless system wherein every player draws from a pool of skills, learning what is either a skill of interest to them or makes logical sense for their character to have. Giving those skills weighted values and requisites we can stop someone from knowing the 'Uber Fireball' spell and being a master of 'The Super Secrete Ninja Squirrel Sword' stance. However, if we further refine our technique, and add a 'Character Memory' stat, which does not even have to be visible to players, which is an idea I really like and will make an entire post about, we can control in the long run exactly how much any given player-character can know, so to speak.

If we use reality as a judge, we know that we can learn something, but if we do not use that knowledge on a regular basis it will begin to fade away, though to some degree we will always have knowledge of it, even if it is only to know that we were once able to do something. Now apply this theory to character skills and you can allow for a 'lifetime of learning' as the player uses certain skills they become more honed and further advanced in those skills, but if they devote their entire life to using a certain skill so they can become the 'Uber Grand Master of Cooking' then chances are they will forget a lot of other stuff that they might need if they ever take a step outside of the kitchen.

I know that there will be response that says that this is micro-management but it's really not if done properly. It could be horribly done and players would have to be in constant fear of their skills fading away and always having to practice/train them, however, if done properly, with slow half-lifes for both gaining and losing skills the game itself becomes the minigame, and nothing's better than knowing that if you learn a new skill and devote some good chunk of experience, trains, practices, etc... on getting it and later decide that it is a skill completely useless to your character, you can just ignore it and it will slowly fade from your memory leaving room for some other skill that you may want more.

Now that that is out of the way, taking the example offered by you of using 'in-game years' as a measure of character advancement the most important thing to recall is that game time passes differently in most newer games where people want to feel that they are on a slightly grander scale than 1 game-hour::15 RL-Minutes. Even assuming that you have an in-game month go buy in one real-life day, to get 10 years of 'character' time put in there really isn't terribly hard. However, by saying that character advancement should be complex and take a long time I was not referring to just generally getting started, for a character to advance to a 'moderate' level should be a rather quick process so that the newbie who's never played your game before doesn't feel like they have to devote years of their life to becoming at least decently succesful. What should take a very long time is to become the absolute best, to be the best blacksmith, or the best swordsman, or whatever. Something, anything that has that 'BEST' distinction should give any player a rather large sense of pride in having ascended the ladder that high, the more players have to work towards that goal, the more fulfilling it will be when they do reach it.

It is important to consider ways in which the mighty may fall, so to speak. If your game runs continually for years and years, eventually, everyone's at the top of the food chain again and newbies are left with a long, hard road ahead of them that may become a discouragement, unless they have a friend there to power-game and help them. In this case, such things as either perma-death or some other manner of cycling out characters is a good idea, perhaps age becomes a factor in skill-retention and your character comes down with Alzheimer's Disease, making it nearly impossible for your character to remember even things they've known their entire life, so you get to start over, which is where player-to-alt parenting and geneology come into the mix, but as I stated, I think this is a long enough reply about the implementation of a non-combat class, or any 'class' so to speak. I'll make another thread to go into further detail.

Vopisk

I've found good Muds that require you to play for a few years to get a really strong grasp on the mechanics, and another few years to build 'super-characrers', people tend to move on with their lives in real life, getting jobs, deciding it's time to move on or other circumstances.

The Mud I play on has roughly 50 people online on average, 25-90 people varying by the day. The average 'high' for the day is 90. A few years back, it was 100. Another few years before, maybe 110. It's a small falling of playerbase, but recently it has actually improved over the summer: Why? New school students, highschoolers, middle schoolers, now have gobs of time to play. They get their friends, and pretty soon we have 5 new active players from one person finding the Mud.

The real key to the survival of a Mud is community. Nobody likes to play a Mud that's empty. Keeping a good playerbase thriving is what will make a Mud last.... keeping a playerbase does require that sense of not being bored, though. I agree, spending hundreds of hours, in the 500 hour range to have a 'decent' character is a must.. otherwise, nobody likes to play cookie-cutter characters. Nobody likes to think that their efforts mean nothing, and that they're just like Bobob on the Mud who started 6 months after you, with less time spent on the Mud because no time is required.

A few incentives for playing by time on the Mud I play:

(Class-less Mud, based around Skills.. Skill Cap limits how many things someone can learn)

- 1.5 Hours online rewards 1 free practice
- 250 Hours online (or 10 IC years) gives 1 level worth of skill cap (Something to do, learn more, teach more)
- Everything in the game can be created by players (about 90% of it atleast), including weapons, armor, scrolls, items, houses, shops, etc. Crafters are REQUIRED for fighters, and make much money in doing so. Supply and demand.

There a bunch of littler features of aging, but we also have a high level restore youth spell to save age.

I find that more often than not the classic MUDs of Elves and Dwarves fall short in the who selection of classes. However, I am a hardcore RPer and these MUDs also fall short there also. To date the best choice for a non-combat class in a MUD is found in Star Wars MUDs.

Which are rather under rated with a small tight community of maybe 12 of us having alts on other MUDs and RPing the hell out of them. Most Star Wars MUDs though are based from SWR code which offers:

Diplomate, a class that allows you to take other planets and charm others.

Pilot, a cargo huller to a fighter pilot. Its your choice kill or not to kill.

Smuggler, sounds like a great class but often pointless, I'll touch on that later.

Slicer, this class has been showing up more and more, its your hacker used to gain info and take money. (Great for a spy RP)

Medic, a sketchy class mostly not finished in any MUD.

Jedi, Sith kill not Jedi. ;)

Engineer, your crafter often the richest players. I have maxed a bank account on my Jawa engineer in a MUD before.
-=Good old Leenui Enop, United Jawa Labor Force.=-

Those are your non-combat classes, of course all can be applied to combat if use right. Like in the case of an engineer, you make a guys armor and drop about 50 thermal detenators in a bag on a timer and let them blow up while you long gone. Pilots of course space battles, Diplomates mostly are RPers but they can charm Mobs to kill you. Though most Mobs will die in one hit which SW: Imperial Conmquest was trying to change till the server owner ran out of money.

The reason these non-combat classes are about though is because Star Wars MUDs, save a few, are all about RP and little else. You character can be leveled in one day and then you just RP, which keeps a few of us in there. Most new to MUDs, however don't like RP because they never played old school D&D. So its not a large pbased area a good pbase in the SW world is maybe 10 active players. Though most MUDs only reach 3-5 with new people shifting in and out every two weeks.

Now then their are problems with this though. Engineers have a need as the PKs are perm is SW MUDs unless you have a clone, but if you die your not getting to your corpse. So Engineers are always making armor and other things. However, classes like smuggler get a great title for RP but little else. They have the ability to smuggle weapons, which everyone can do so nothing special there. The can make spice, the SW drug, but no one ever buys it because its pointless. Thats really about it, so its a rarely played class.

So if your looking for a non-combat class then you have to look toward a mostly RP MUD which means Star Wars MUDs or MOOs and MUSHs for the most part because I've only seen one other catagory MUD that had RPers. Its not bad though you make friends with the folks easy because its all so small and everyone has played all the same MUDs as you so when you make a joke they get it. That kind of *CENSORED*.

May the Force Be With You,

Mr. Gogo

or

-=Leenui Enop, Leader of the United Jawa Labor Force=-

I think the idea of a 'non-combat class' is probably misguided, but I like the idea of non-combat gameplay. I think the best way to handle this sort of game is:

1) Make the system skill-based rather than class-based (so any character can learn any skill - but different characters might have different aptitudes for different skills, and skills might be inter-related or form a tree).

2) Abolish experience points.

The second of those is the more important one. If you remove the whole concept of experience points and, particularly, no longer derive the ability to advance one's character primarily from kill frequency, that changes the whole game balance.

An awful lot of MUDs come down to 'kill more in order to become powerful enough to kill still more'. If you want to make non-combat interesting, you have to sever the link between killing and levelling (and, indeed, between levelling and enhanced combat ability).

There ought to be all sorts of opportunities for advancement that do not derive from simple prowess. For example, suppose that, to solve a quest, it is necessary to talk to a local duke. How does the player gain access? If he's a killing machine, it might be necessary to serve in the duke's army for a while until he is decorated for bravery. Another character might be sufficiently skilled in courtly etiquette that he is recognised as noble and granted admission immediately - but that might also require the character to be dressed in sufficiently elegant clothing. So the player would have to either acquire tailoring skills, or use his bartering skills to get a good deal at an upmarket clothing shop. Or it might be possible for a player with cooking skills to send the duke a specially made cake which, if it proved sufficiently delicious, would prompt the duke to grant an audience to the chef. Or the player might try to gain admittance by stealth, or bribery, or by use of disguise skills, etc. etc.

Better yet, design a complete game without implementing combat at all. When you are finished, add it in as an afterthought. ;-)

Start coding without starting implementing combat as a start....

Indeed! Infact, while I'm still working on various global coding issues, such as areas, prog abilities, and into items/mobs, ya know, everything that effects the environment and play..well, in the process of doing so, one thing I like to do is make sure non-combat abilities exist to affect all of these before hand; making sure crafters have the abilities to affect a lot of the items made, that there are skills to interact with the environment, etc etc. Since I'm still early on in development I can't say the complete success of it, other than I had a combat system in place with killing and looting and the sort- I promptly removed it entirely when I found the desire to make sure that the surroundings were 'perfect' before moving onto such things as 'fighting'.

With this, before combat is official, with this way of designing/coding, there will already be very useful non-combat skills/spells used to get around, make items, interact, etc.



Too often I think people are bent around fighting they forget about making a world in the process.

I often get badgered about just getting fighting in so people can play, which I promptly tell them NO, not until everything I can possibly think of for environment play is out of the way.

No need to abolish experience points. In my (classless) mud, people can earn xp by killing mobs as well as building objects in a guild or playing casino... Simply implement several different ways of earning xp points.

> Better yet, design a complete game without implementing
> combat at all. When you are finished, add it in as an
> afterthought. ;-)

If you did that, I suspect your combat system would end up looking like most peoples crafting systems - something which has been half-heartedly tacked on, and which doesn't really fit with the rest of the game design.

Eliminating XP is as far as I can see not an option in any game where you wish there to be character advancement versus player advancement.

The best option I feel, or think I feel, is to reward players for their actions. Every action should have a reward associated with it. I'll avoid the social implications, and discussion about the rewards that come with interacting with other players, and focus on rewards for interacting with the game.

Classical Mud architecture doesn't reward you for using non-combat related actions. And so in regards to the OT, adding viable and fun non-combat classes are very difficult. But with proper planning while developing a new codebase, it can be quite a bit easier.

This goes hand in hand to the 'skill-based advancement' train of thought. But instead of increasing a skill, allot the xp for using that skill. Picking a lock? Gain Experience. Talking to an inn-keeper? Gain experience. The reason that people stick to the skill-based idea, is that it keeps you from being able to powerlevel really fast and applying it where you want. So scratch recieving experience.

Increase the robustness of the player-model. Make it so that they player gains a reward for actions and for repeated actions. Does the player talk to innkeepers a lot? You can track this. Does a player pick locks a lot? Track it. With the speed of computers these days, the power of databases, tracking a lot of information becomes easier resource-wise. So many video games these days track a lot of things. Fable, Farthest Chicken Kick. San Andrea's tracks a lot of things. But what they lack is a proper in-game response mechanism to these tracked items. Picking locks a lot is going to do more then just increase your skill in lock picking. It's gonna increase your dexterity, your concentration, you ability to sense or hear little clicks. With proper programming (Atomic OOP, or whatever the hell it's called) you can respond better and provide for a better gameplay scenario.

What about a system where you control more than one character at a time? I'm talking like the system in SW:KOTR where you have multiple characters that are essentially on autopilot and follow your active character but you can switch between the characters. Probably not like KORT in the fact that you only get to choose your main character. Or maybe you start off with just one character and you could recruit other characters around the system. This type of feature wouldn't have to be SW dependant, it would work even on a DnD or tolken based mud.

My point is that maybe eliminating the XP system isn't the only viable option to making the game more interesting or more unique.

I do agree that the idea of tracking each activity is a good one, provided there is proper implementation of in-game effects relative to such tracking.

On a side note: I do think it would be very difficult to implement a pause feature like KOTR has in order to help manage multiple characters simultaniously. But I'm sure that there are enough clients with triggers and aliases out there to facilitate micromanaging multiple characters in a scenario like this.

>If you did that, I suspect your combat system would end
>up looking like most peoples crafting systems - something
>which has been half-heartedly tacked on, and which
>doesn't really fit with the rest of the game design.

That all depends on the skill of the designer/coder.

The idea is that while you'r designing and coding items, basic skills, and how areas work, you're giving crafters the ability to influence all of that from the start.

Designing fighting after does not mean it would be 'half-heartedly' designed.... only if your designer is horrible at their job.

> > > Better yet, design a complete game without implementing
> > > combat at all. When you are finished, add it in as an
> > > afterthought. ;-)
> >
> > If you did that, I suspect your combat system would end
> > up looking like most peoples crafting systems - something
> > which has been half-heartedly tacked on, and which
> > doesn't really fit with the rest of the game design.
>
> That all depends on the skill of the designer/coder.

A skilled designer wouldn't add an important part of the game as an "afterthought".

I realise that Tyche was being sardonic in the post I replied to (thus the smiley), but my comment still stands; the reason non-combat character classes are rarely implemented, and the reason why crafting systems are usually little more than tacked-on extras, is that the original game design was simply not intended to support them. And if your original design has no provision for combat, then you're going to run into the exact same problem.

If you want a feature to play an important role in the game then you should include it in the design right from the beginning. Even if you don't implement it until later, you should at least keep it in mind when adding other parts of the game. Otherwise you're force to either go back and redo the rest of the design, or tack it on as a half-arsed feature which doesn't really fit with the rest of the game design.

Well said, KaVir. These issues are fundamentals of design. The most crucial aspect of good design is to have a explicit vision.

The point I'm trying to make, and I think Tyche is trying to make, is that designing combat around the world you build, including around non-combat skills/spells, allows for better cohesion between the two groupings.

Designing combat around something means you need to start with that other idea first.. Would you start coding combat without knowing what you will be able to enchant and craft? Will you code in various ways of armor-usage before you know how items will work in terms of being equipped? Would you base combat around the fact that there's nothing in the game to consider yet, leaving combat to start in a single room, hack and slash?..or perhaps waiting until you flush out area abilities nicely, making spells have other consequences to an area? Combat before PK stalking abilities?


I just think that implementing fighting FIRST is a bad idea... you'll just end up revamping it every time you want to change something outside of combat. And of course, if you're just catering to people wanting to fight ASAP, then making mass changes to combat won't go over well.


The difference between boring Muds and revolutionary Muds is the difference between drone killing and dynamic killing. Dynamic combat requires a dynamic world around you. The world around you should be the foundation in which combat is evolved.

What's the purpose of building a house first when you're going to change its foundation a dozen times before the end?

> The point I'm trying to make, and I think Tyche is trying
> to make, is that designing combat around the world you
> build, including around non-combat skills/spells, allows
> for better cohesion between the two groupings.

Not if you "add it in as an afterthought", it won't. As I said in my previous post, "If you want a feature to play an important role in the game then you should include it in the design right from the beginning."

> Designing combat around something means you need to start
> with that other idea first..

But it doesn't mean you should fully design and implement that other idea before moving on to the combat design - the two need to be designed together.

> The difference between boring Muds and revolutionary Muds
> is the difference between drone killing and dynamic killing.
> Dynamic combat requires a dynamic world around you. The
> world around you should be the foundation in which combat
> is evolved.

The combat system needs to be designed with the world in mind, yes - but the same is also true the other way around; you need to design the world and the combat system together. You cannot expect to just tack one onto the other and end up with a cohesive system at the end of it.

> What's the purpose of building a house first when you're
> going to change its foundation a dozen times before the end?

Exactly my point, and precisely why you shouldn't add combat as an afterthought (unless it's only designed to be a minor side feature).

This thread was started for raising an issue of creating non-combat opportunities that still effect the game.

As simple as I can say it:

Code your world first.

Code your world with combat ideas in mind.

Code non-combat skills/spells/abilities around this world.

Design your combat system around that world you're coding.

Code your combat system around that world.


With this, non-combat revolves around combat, revolves around the world, revolving around eachother.

Cohesion.

Start with coding your world first, not catering to a simple hack/slash game.

/*
Dratgard

'Start with coding your world first, not catering to a simple hack/slash game.'
*/

I think the point that others was trying to raise is not about whether everything should be cohesive or not, I think everyone can agree that every system in a game should be cohesive and it is always bad to 'tack things on' to the end. The idea is that rather than just diving into the coding and whatnot, you lay out your ideas, plans and principles on paper or some other media first. Know what your game is going to be before you write your first function or declaration. If you're going to be purely PK or your goal is Hack/Slash, this is still important so you don't end up with the mish-mash amalgamation that plagues so many muds, the desire for sheer numbers of things to kill, areas, skills, classes, etc... outweighing the greater, larger idea of what the game is supposed to be.

Planning ahead, you can then move on to creating the 'template' for your world, making everything fit into a larger prototype (object-oriented?), means that everything and anything can relatively easily be added on at a later time. Skills are skills, regardless of what they affect whether it be a doorknob, wooden log or other player, they all have an affect that has outcomes for either better or worse. Which is not to say that some skills can't be used for both non-combat and for combat focused characters. For example, a warrior and a woodcutter are both experts with an axe, and both require a chopping skill, so the same skill can be used to chop down whatever may be in your way, be it another player or a tree, one skill, multiple functions. This fits back into my larger and seperate topic about 'simulated realism' as I dubbed it so I won't go off on that tangent, but the bottom line remains, don't kill both birds seperately when you can take them down with the same stone. Design all your systems together, to work together, and if done right, they will, and everyone, be their Hack/Slasher or Non-Combatant will hopefully have a pleasant and enjoyable time playing your game.

Vopisk

Post-script: For the record, I have no idea how to use the special little commands to make quotes, so I went with what I do know...

> This thread was started for raising an issue of creating
> non-combat opportunities that still effect the game.

But not at the expense of combat opportunities!

> As simple as I can say it:
>
> Code your world first.

What, before you've even designed it?

> Code your world with combat ideas in mind.

How can you do that if you've not yet designed the combat system?

> Code non-combat skills/spells/abilities around this world.

With no idea how they'll interact with combat skills?

> Design your combat system around that world you're coding.
> Code your combat system around that world.

Then your combat system will be limited by the world. That is one of the main reasons why (for example) ranged combat is so poorly implemented on most muds - it has to be designed around the limitations of the world, and that world was never designed with ranged combat in mind.

> With this, non-combat revolves around combat, revolves
> around the world, revolving around eachother.

No, with your proposal combat is limited by the non-combat features, and both are limited by the world.

> Cohesion.

Cohesion is good. Cohesion is what I've been proposing, but it requires the different parts of the game to be designed together. What you're proposing would result in a set of one-way dependencies, where each feature is restricted by the limitations of those it is based on.

> Start with coding your world first, not catering to a
> simple hack/slash game.

If you code your world first, then the chances are your combat will be little more than a simple hack/slash game.

But if you want the combat system to be an intricate part of the world, then you need to design the two together.

I too am coding a mud. I was trying to get around this issue too when I realized that it's all the same thing. I'm trying to get around it by essentially making everything the same thing. I mean an action is an action whether it's 'say', 'cast', 'kill' or 'dig'. Each activates a function in the program that sets flags and attributes and produces output.

I found out my real problem has been that I'd been limiting myself by setting a static list of possible flags, attributes, stats, etc. If all this stuff is static and you're built around a hack'n'slash mud, adding crafting skills would be horrendous. But making the list of possible stats, attributes, etc dynamic would ease this tremendously.

Basically, I'm talking about making the base code of the mud condusive for making anything in the mud do anything. Then you just have to build a function once you think of that new action/activity. Program 'look' as an afterthought? Sure!