08 Sep, 2008, KaVir wrote in the 21st comment:
Votes: 0
DavidHaley said:
Ah, yes, and this has done a great deal of harm to interesting races and classes. It is almost inevitable that, if everybody is to be able to play solo equally well, all classes end up converging to being very similar, just with different names put on the various actions. The differences become superficial only, in that one person casts a spell that does X damage, whereas the other uses an attack skill that does the same X damage.


The above comment reminds me of some feedback I once received in response to a design proposal: http://www.topmudsites.com/forums/advanc... (see posts #4, #5, #6 and #8).

I also made a post about the same topic on TMC, but I can't find it any more. I think I worked out that if you wanted every skill to be functionally unique at the fundamental level, you'd end up with about 9 total skills (and a few of those could argubly be combined as well).

However I think it's perfectly possible to make each class feel very different while still giving them sufficient overlap of the fundamental abilities that they can be played solo. A good example of this IMO is the White Wolf World of Darkness system, where vampires, werewolves, mages, changelings, etc, are very distinct from each other, but (because they're designed to be played in groups of one supernatural type) also each cover all of the fundamental abilities. White Wolf doesn't refer to them as character classes, but from a game design perspective that's pretty much exactly what they are.


DavidHaley said:
Personally I don't think it makes much sense, in an IC and not OOC understanding, to have relatively dangerous dungeons right next to a town. There are some circumstances where you could explain it, but most of the time it's very hard to explain why this otherwise peaceful town exists right next to a rather dangerous place. Especially as the town grows in size, you would think that guard patrols would clear out most dangerous things – or the town itself would be cleared out by the dangerous things in question.


In most muds, the dungeons are an unlimited source of monsters and treasure, and I think that's the part that really needs to be explained - was it created in the past by a mad wizard? It is some sort of enchanted location from a bygone era? It is the result of a powerful curse or planar convergence?

Once you've established that the dungeon has a neverending supply of monsters and loot, you no longer need to explain why it's still there, only why the town was built beside it. And that's not really a big stretch, in my opinion - with greedy adventurers heading into the dungeon for treasure (and returning rich and tired) it would make sense for some forward-thinking innkeeper to set up an establishment near the entrance. He'd likely need guards to deal with the occasional monster that wandered out, and permanently stationed guards would want to bring their families (thus needing housing). With families living in the area, there would be demand for food and clothing. Carpenters and stonemasons would be required to build up and maintain defences, alchemists and blacksmiths would would find plenty of customers among the guards and adventurers, and so on.

It would be a bit like a gold rush town, but unlike gold mines the dungeons wouldn't dry up, so the town would just continue to grow. Shutting down the dungeon (even if it were possible) would destroy the town's livelyhood, and the would-be hero who thought he was "saving" the town by finally sealing up the dungeon would be unlikely to receive the sort of appreciation he might have expected. In fact, that gives me an interesting idea for a tabletop adventure…
08 Sep, 2008, Kayle wrote in the 22nd comment:
Votes: 0
Firstly, Glad to see you around again KaVir.

I agree that classes can share skills and still play differently, in D&D 3rd Edition there's one skill set shared across all classes, and supplemented by class abilities like "turn undead" or the ability to cast spells, or a barbarian rage. They all have their advantages and disadvantages but can all be played solo for the most part. Granted it defeats the purpose of D&D to play solo, but still. :P

As for MUD Dungeons always being an infinite source of monsters, in most places it's never really explained. None of the MUDs that I've played have ever really taken the care to explain why the monsters show back up when you kill them aside from 'It's called repop, it happens every 15 minutes or so', and when I get told this I can't help but laugh and think, 'Hmm. Most Dungeon Masters would have a fit if you thought about things like that while playing at the tabletop.' I've considered adding a flag to certain key monsters in areas and dungeons that make them not respawn for an extended period of time, and maybe one that stops them from respawning while anyone is in the area. So that for instance, you raid a Hobgoblin encampment, and you kill the leaders lieutenants, they should stay dead, but at the same time, the "trash" (or unimportant) mobs should be able to respawn normally.
08 Sep, 2008, David Haley wrote in the 23rd comment:
Votes: 0
I find it more acceptable to not explain repop than to explain why a village exists next to a really dangerous dungeon, let alone try to explain it by having the NPCs "understand" repop and building a whole industry around it. I suppose it's just personal preference, though. For me, repop is an unfortunate necessity of a multiplayer world. I think it's possible to not have repop like that, but it gets really complicated really quick to have a "living" world that never repops.

One could imagine there being several goblin dens, and if you clear it out, it's empty until a new band of goblins moves in. How you handle that is an interesting question – are there roving bands looking for nice caves to hang out in? do you have randomized repops to simulate a band finding the cave? – but it would make the world feel less artificial due to the repops. I dislike repops, I'm just not sure how practical it would be to get rid of them.

Not having a reset when people are in the area, or at least within some proximity of the reset, is generally a good idea IMO. It's bizarre to be clearing out a dungeon and discover that the entrance is filled with baddies after you cleaned out the deeper ends. Of course, this opens potential for abuse: if I don't want people to raid the dungeon all I have to do is hang out there.
08 Sep, 2008, Fizban wrote in the 24th comment:
Votes: 0
Kayle said:
I've considered adding a flag to certain key monsters in areas and dungeons that make them not respawn for an extended period of time, and maybe one that stops them from respawning while anyone is in the area. So that for instance, you raid a Hobgoblin encampment, and you kill the leaders lieutenants, they should stay dead, but at the same time, the "trash" (or unimportant) mobs should be able to respawn normally.


Perhaps even save a value to the player when they kill the mob? ie. The mob resets, but purges itself when a player that has already killed it before attempts to enter the room (assuming no other PC's are already in the room)?

This is of course slightly easier to implement in some codebases than others, but in Circle for instance it'd be as simple as:

Name: 'Flag Player When I Die'
Trigger Intended Assignment: Mobiles
Trigger Type: Death , Numeric Arg: 100, Arg list:
Commands:
set has_killed_ogreking 1
remote has_killed_ogreking %self.fighting.id%


That would flag the player the mob was targetting, though if you wanted it to target every player in the room it could just as easily be:

Name: 'Flag Player When I Die'
Trigger Intended Assignment: Mobiles
Trigger Type: Death , Numeric Arg: 100, Arg list:
Commands:
set has_killed_ogreking 1
set people %self.people%
while %people%
if %people.is_pc%
remote has_killed_ogreking %people.id%
end
set people %people.next_in_room%
done
08 Sep, 2008, Hades_Kane wrote in the 25th comment:
Votes: 0
Almost everyone of our dungeon type of areas have "random encounters" in the vein of Final Fantasy.

Final Fantasy never bothered to explain it, so why should we? :p


But in that same line of thinking, how do you explain on most MUDs that you kill 'Trofiel, the Wanderer' or any number of citizens and don't get hunted down for murder, and 15 minutes later (or 15 hours in game time) he's wandering around again but doesn't seem to mind you at all.

I don't think the genre or game system really lends itself well toward being realistic or having explainable elements like that.
08 Sep, 2008, David Haley wrote in the 26th comment:
Votes: 0
Right – I think that some battles are more easily fought than others, and trying to explain repops or the kind of scenario you described is not one of the easier battles.

One quick idea I had to somewhat alleviate the problem is to have a "unique" mob for that kind of quest, but with a randomly generated name on every respawn. You'd still have the problem of that pesky brigand chief that always comes back, but at least it'd be a different "person" every time.
08 Sep, 2008, The_Fury wrote in the 27th comment:
Votes: 0
Quote
You'd still have the problem of that pesky brigand chief that always comes back, but at least it'd be a different "person" every time.


Substitute chief for captain or some army type rank, make the monsters global in scope and they can be resupplied from their own lands. Orcs are pretty good for this, they have a developed social order and command structure, they take over whatever natural landforms they can find, and once you wipe them out of one dungeon, they can be resupplied from the main orc camp. Or from their lands far far away.
09 Sep, 2008, KaVir wrote in the 28th comment:
Votes: 0
Kayle said:
I agree that classes can share skills and still play differently, in D&D 3rd Edition there's one skill set shared across all classes, and supplemented by class abilities like "turn undead" or the ability to cast spells, or a barbarian rage.


Well I was really talking more about fundamental skills - for example the barbarian rage is really just a buff, while turn undead is a debuff. Equally the warrior's attack, the mage's fireball and the thief's backstab are all just ways to inflict damage.

If I recall correctly, in older versions of D&D the thief was the only class capable of disarming traps, while the cleric was the only class capable of healing and the mage was the only class capable of teleporting - those would be better examples of classes with unique fundamental skills.

Of course magic items changed that, and later versions of D&D resulted in a certain amount of crossover, but in my opinion it was a definite improvement. Sure, D&D is designed for a group of characters - but at least you're no longer required to have a representative of each core class simply to be able to play properly.

I managed to find the post I mentioned previously (I'll quote it as well, for people who don't belong to TMC's social network): http://social.mudconnect.com/lobby/forum...

Quote
Well if you're classifying skills into broad categories like "damage, bonuses, minuses", you're going to end up no more than a handful of different skills. For example, the following eight skill types should cover almost everything:

Heal: cure, repair, etc.
Harm: kick, fireball, damage armour, break weapon, etc.
Buff: bless, sanct, enchant weapon, etc.
Curse: blind, weakness, poison, disease, etc.
Create: mount, portal, armour, etc.
Destroy: creature, weapon, etc.
Transport: summon, teleport, steal, disarm, etc.
Reveal: info about mobs, locations, etc.

Technically you could even merge Heal/Harm into 'Health' and Buff/Curse into 'Modifier'. You could probably even merge those two together as well…

But just because two skills do damage doesn't mean they have to be identical. Perhaps fireball inflicts heat damage on multiple opponents and their equipment at long range and can only be dodged, while a kick inflicts crushing damage on a single opponent at short range with a chance of also knocking them over. The end result might be the same - the opponent takes damage - but the two skills would have very different tactical uses.
09 Sep, 2008, Hades_Kane wrote in the 29th comment:
Votes: 0
This is the type of discussion that I personally really like to see.

It isn't too technical as far as implementation, coding, or language goes, but I think that it can definitely help everyone perhaps think outside of the box a bit.

I know I enjoy being able to see others' approach to things like this… especially since my current project is coding a TON of skills :p
11 Sep, 2008, The_Fury wrote in the 30th comment:
Votes: 0
Hades_Kane said:
This is the type of discussion that I personally really like to see.

It isn't too technical as far as implementation, coding, or language goes, but I think that it can definitely help everyone perhaps think outside of the box a bit.

I know I enjoy being able to see others' approach to things like this… especially since my current project is coding a TON of skills :p


Yeah i do also, no one pushing dogma one way or the other, just people throwing thoughts and ideas onto the table and shuffling them about.
20.0/30