25 Oct, 2009, Antron wrote in the 1st comment:
Votes: 0
I am wondering about others perspectives.
As a coder, a builder, and a player:

What do you like about SMAUG versus other codebases?


What styles of MUD best suits SMAUG, in your opinion?


Have you seen SMAUG (or some custom derivative thereof) used in a surprising or unusual way?


What are some of the limitations of MUDs running on SMAUG?


What pitfalls do SMAUG MUDs often fall in to? (in terms of either coding, building, or playing)
25 Oct, 2009, Tonitrus wrote in the 2nd comment:
Votes: 0
Antron said:
I am wondering about others perspectives.
As a coder, a builder, and a player:

What do you like about SMAUG versus other codebases?

Smaug has a lot of features that I haven't seen implemented in other codebases. Whenever I end up on ROM or so on, I find a bunch of things missing. shove/drag come to mind. Smaugspells are great, but could be fleshed out more.

Antron said:
What styles of MUD best suits SMAUG, in your opinion?

You could probably get away with doing any mud that has classes and levels on Smaug. I was even able to hack together multiclassing pretty quickly, although I never bothered to finalize it. If you're going to go with stock Smaug, it strongly favors "Achiever" types, who won't necessarily mind the rote if it will lead to eventual "advancement". I was also able to write up a skill prerequisite system fairly quickly with the hope of doing away with levels, but I never got around to removing levels, and it would probably be a pain.

Antron said:
Have you seen SMAUG (or some custom derivative thereof) used in a surprising or unusual way?

Unfortunately, no. Just about every Smaug mud I've been on has been rather stock.

Antron said:
What are some of the limitations of MUDs running on SMAUG?

The damn stupid diku license, for one thing.

Not limited to Smaug, but I'm not a fan of repops either, since it means I can't really affect the world in any way.

Antron said:
What pitfalls do SMAUG MUDs often fall in to? (in terms of either coding, building, or playing)

As far as I'm concerned, "stock smaug" (where avatars are walking around with 100+dr) is hopelessly broken. Any system where you have to heal 400hp (800hp deadly) a round is hopelessly screwed. With damage that high, death is often a matter of really stupid situations, where a few bars of lag get you one-rounded (or two-rounded, if you're lucky), which is probably why Smaug pkers tend to be pretty pissy. There also aren't enough skills, and they don't have enough variety, and they don't tend to be balanced. The idea of "alpha skills" is a dumb idea anyway, it just encourages people to spam the same skill over and over. grasp;grasp;grasp;grasp;grasp;grasp;grasp;grasp;grasp;feed;feed;feed (repeat as necessary)

I'm not sure if this is a common Smaug theme, but I've noticed a certain tendency to segregate PK, MK, and RP. I think any attempt to distinguish these things is hopelessly wrong-headed, and (for the record) have no interest of playing any mud that does.

And this isn't limited to Smaug, but any system where the administration has to create content for a player-base is ultimately going to stagnate as the player-base grows.

As for other things I don't like:
Having to change 30 source files every time I make a coding change
There being 50 levels, when really only one of them (level 50) matters
Level rote/grind
Quaff spam
Death spam
The entire deity system
Corpse retrieval
The alignment system (mass murdering hobgoblins is a good act?)
The way room-linkings don't have to (and often don't) make any sense
Seeing people drink 4-8 potions a round while dual-wielding and casting spells
Getting 1 rounded (or 2 rounded) and 1 (or 2) rounding other people
Having to fight countless boring mobs to get equipment to do what I actually want to do (which is kill the crap out of other players)
26 Oct, 2009, Dean wrote in the 3rd comment:
Votes: 0
Tonitrus said:
And this isn't limited to Smaug, but any system where the administration has to create content for a player-base is ultimately going to stagnate as the player-base grows.


Perhaps you could clarify what you mean by this? I've encountered plenty of MUDs that rely solely on staff creating content and haven't stagnated at all.
26 Oct, 2009, quixadhal wrote in the 4th comment:
Votes: 0
Tonitrus said:
And this isn't limited to Smaug, but any system where the administration has to create content for a player-base is ultimately going to stagnate as the player-base grows.


That depends on the kind of content, and the kind of player base. In a typical MMO kill-everything-that-moves-until-max-level grind, this is probably true. The player base will solve all the puzzles and post them to web pages, map the entire world with shortcuts on how to travel most efficiently as you level through the content, and eventually finish everything. New players will use those guides to zip through everything in a few days, and also sit at the top.

If that's the kind of game you're building (and the kind of players you're attracting), you would need a huge content development team to continue attracting new players.

If you're doing something else, where the focus is on PvP, or GM-run events, or one-time achievements that don't just respawn… that's another story. It's also another story if you have a diverse enough class/skill/etc system so that going from the bottom to the top is very different from one character to the next. And, of course, you could have different story lines based on starting race, alignment, etc… which might lead you to totally different sets of content.

I'm not convinced that having the players create content is going to work well either. Some groups of players will make really wonderful things. Others will see what they can get away with… "Look, I made MegaSmurf! He's worth a billion XP and dies when you throw a smurf berry at him. Here's a wand of smurf berries I also made!"
26 Oct, 2009, KaVir wrote in the 5th comment:
Votes: 0
quixadhal said:
I'm not convinced that having the players create content is going to work well either. Some groups of players will make really wonderful things. Others will see what they can get away with… "Look, I made MegaSmurf! He's worth a billion XP and dies when you throw a smurf berry at him. Here's a wand of smurf berries I also made!"

Yeah, it's a major problem that even the big commercial games are having serious trouble with. I find the idea compelling, and am thinking of having another go at it (my last attempt wasn't so successful) but there are a lot of pitfalls that need to be avoide....
26 Oct, 2009, Confuto wrote in the 6th comment:
Votes: 0
quixadhal said:
If you're doing something else, where the focus is on PvP, or GM-run events, or one-time achievements that don't just respawn… that's another story. It's also another story if you have a diverse enough class/skill/etc system so that going from the bottom to the top is very different from one character to the next. And, of course, you could have different story lines based on starting race, alignment, etc… which might lead you to totally different sets of content.

Wouldn't that require just as much content to be built as a hack-n-slash MUD, if not more? If you have three story lines that means three times as much content. If the focus is on one-time events and achievements, well, that's even more work. I don't particularly agree that a lack of new content necessarily results in stagnation, but it often results in a high turnover in the playerbase. You make a good point with regards to replayability, though, and I think that's something that often overlooked.
26 Oct, 2009, quixadhal wrote in the 7th comment:
Votes: 0
It depends. The mindset of games which are oriented around GM-guided activities, or puzzles is very different than the hack-and-slash mindset most of our Diku-based games uses. If there isn't a "max-level" goal to chase after, you spend more time exploring and interacting with everything, rather than mashing the kill buttons.

It's one of the distinctions between a "good" DM and a "bad" DM, when playing pen-and-paper games. The good DM will often lead you through a whole evening of entertainment with only a couple of fights taking place, but lots of interaction. The bad DM will lead you from one encounter to the next, with only brief descriptions of time passing.

The problem with automated games like this is that content is typically coupled to levels and experience gain directly. When I played D&D, the DM gave us some small amount of experience based on what we killed, but MOST of it came from our thinking our way out of situations, and doing things to help the group survive. That's backwards for most MUDs, as you usually get most of your XP from kills and some extra amount of automated quests (if available). Because of that, content is trivialized into farming areas and quest walkthroughs.

Any way you look at it, your admins WILL have to generate a lot of content. The question is, is it content that will keep the players entertained, or content they'll never see because they run around with "brief" on, looking for stuff to kill?
26 Oct, 2009, KaVir wrote in the 8th comment:
Votes: 0
quixadhal said:
Any way you look at it, your admins WILL have to generate a lot of content. The question is, is it content that will keep the players entertained, or content they'll never see because they run around with "brief" on, looking for stuff to kill?

"Stuff to kill" is also content that can be entertaining - and if your players switch on brief mode and spend their time killing things, the chances are it's because they find that activity more entertaining than the alternatives.

My problem with admin-run storylines and such is that they're not reusable. I like this sort of content the least, because the admin can spend months or even years producing the content, but it's being thrown away as fast as it's being created. At the end of it, you've nothing to show for all your effort.

Instead I prefer content that is permanently added to the game. New areas, instanced quests, that sort of thing - the players will go through it faster than you can create it, but each new player can work their way through the "backlog" that accumulates over time. The longer the mud runs, the more content there is for players to go through before they run out of things to do.

There's also repeatable and/or generated content, such as autoquests and the like. That can be okay in moderation, perhaps as a supplement to other content, but if overused it can make the game pretty boring and repetitive.

Finally you have player toys - things they can ticker with, such as crafting systems, customisable housing, clans, etc. This type of content is a really good investment of admin time, as (if done well) it can keep the players entertained far longer relative to the amount of time invested into it. Toys alone aren't usually enough to keep the players happy though.
26 Oct, 2009, Tonitrus wrote in the 9th comment:
Votes: 0
Kavir said:
but there are a lot of pitfalls to be avoided

I didn't read that whole thread (the link you posted), I pretty much only read your initial post. I looked at these issues when I was writing up a system for this, and I came up with some solutions. The first is non-ideal, but solves the "Some players will write stupid or inappropriate descriptions" problem in an inefficient/annoying manner. Namely, the object/room/mob/whatever is created with a generic description, which a player can then edit as a sort of prototype description that only he and the administration can see. These prototypes are stored in a big list, and then the administration rubber-stamps the non-stupid ones. I also was thinking about rewarding the well-written ones, and since I'd likely end up rubber-stamping them (if I ever get around to making a mud), probably take action against people who persist in making retarded ones (a nodesc flag would probably solve it nicely).

My actual player-creation system solves the other two issues.

"Some players will make their content really easy."
"Players make super items as treasure."

I don't want to go into a lot of detail because I've spent massive amounts of time working on designs such as this, but the gist of it is that areas have "scores" and that anything that pops in an area that wasn't there before reduces the score. These scores replenish over time, by multiplication against a small number (0.1 or something) so that when they hit zero, they are dead and stay dead. Since pops "cost" the area, as they get low, stuff stops popping, and pops cost a proportional amount to the worth of what was popped. Players can claim/fight over these dead areas and may dump their own resources into beefing up the area's score. They may also "pay" to adjust the areas. And things like "defending against invaders" (players or mobs) also increase the area score. Since players now represent the area, things they do to protect their own area makes their area stronger.

As a consequence, if they make a super-powered area, it costs a lot for them to get it up and running, and it costs the area more to replenish their super-powered nonsense. If they make an easy area with slight rewards, it costs the area more often, but doesn't cost it as much, meaning it may replenish. If they make an easy area with huge rewards, it costs them often, plus the resources aren't adequately defended.

Basically, I'd link what they put into the area 1:1 with what they get out. If they run an area well, it will generate extra resources that they can cash out without having to resort to abusing their own area.
27 Oct, 2009, KaVir wrote in the 10th comment:
Votes: 0
Tonitrus said:
Kavir said:
but there are a lot of pitfalls to be avoided

I didn't read that whole thread (the link you posted), I pretty much only read your initial post. I looked at these issues when I was writing up a system for this, and I came up with some solutions. The first is non-ideal, but solves the "Some players will write stupid or inappropriate descriptions" problem in an inefficient/annoying manner. Namely, the object/room/mob/whatever is created with a generic description, which a player can then edit as a sort of prototype description that only he and the administration can see. These prototypes are stored in a big list, and then the administration rubber-stamps the non-stupid ones.

That's the same approach I use for clan names (and similar to the suggestion made by shasarak in his reply), but you'll note in my link that my main goal for player generated content was "a solution that requires minimal administrative effort once it's been set up". Having to wade through piles of player-generated content, providing feedback on what needs to be done before it can be authorised, is likely to be a very time-consuming (and uninspiring) job. It's also going to irritate the players who are stuck in the backlog of work. This solution is fine for clan names, but it's not very scalable.

Tonitrus said:
My actual player-creation system solves the other two issues.

"Some players will make their content really easy."
"Players make super items as treasure."

I don't want to go into a lot of detail because I've spent massive amounts of time working on designs such as this, but the gist of it is that areas have "scores" and that anything that pops in an area that wasn't there before reduces the score. These scores replenish over time, by multiplication against a small number (0.1 or something) so that when they hit zero, they are dead and stay dead. Since pops "cost" the area, as they get low, stuff stops popping, and pops cost a proportional amount to the worth of what was popped. Players can claim/fight over these dead areas and may dump their own resources into beefing up the area's score. They may also "pay" to adjust the areas. And things like "defending against invaders" (players or mobs) also increase the area score. Since players now represent the area, things they do to protect their own area makes their area stronger.

So it's almost like a farming game? You seed your fields (populate your area), then prevent mice and birds (other players) from eating your crops (killing your mobs) before they're ready to harvest?

This doesn't deal with the second problem though - "Players make super items as treasure". Even if the area only produces one UberSword per year, players will still want one for themselves. In fact they're unlikely to bother creating equipment they don't personally want, as it'll just make their area more appealing to attackers.
27 Oct, 2009, Runter wrote in the 11th comment:
Votes: 0
KaVir said:
This doesn't deal with the second problem though - "Players make super items as treasure". Even if the area only produces one UberSword per year, players will still want one for themselves. In fact they're unlikely to bother creating equipment they don't personally want, as it'll just make their area more appealing to attackers.


Not really addressing your original concern but I thought I would add an idea I've been throwing around to the mix with player generated items in specific.

I wanted to make a fairly intricate system where every item in the game has a recipe that may cross disciplines. The idea is that all materials to create any item are accounted for in a way that forces even builders to be aware and responsable for the quality of the item based on the materials that go into it. The system could potentially be extended to players.

A quick example might be "a wool cape of cold resistance" whereas the recipe the builder had to generate was:
Material: wool[3]x1
— [3] Tailor recipe wool cloth
[2] Spin wool to wool cloth
— [5] Tailor recipe wool cape
[2] sew wool cloth to wool cape
— [7] Enchanting recipe
[5] apply spell: cold resistance to wool cape
— [12]

A crude example but it can incorporate multiple skill sets to create the recipe. Those points shouldn't be arbitrarily assigned since they plug directly into an ilevel function which can be tweaked and balanced. Specifically I'm calculating the value of trade skills based on A) Base chance of failure and B) time required to preform. Total could further be modified by how many different trade skills of what levels it took to generate an item. (Ideally it could take multiple people to finish complex items.) The end value is essentially an item level.

After stats are assigned by said builder the system gives them a target ilevel. Their instructions to build the item must then add up to the target ilevel or more. They can tweak the stats on the item to actually lower the ilevel requirement. But until the stats are in compliance the item is a no-go. Requires no administration oversight. The builder may feel some of it is not balanced correctly, but that's probably not his job anyways. (Which I feel is a big mistake giving your content designers access to in the first place.)

Probably not exactly on topic, but it's something that I want feedback on anyways. :)
27 Oct, 2009, Scandum wrote in the 12th comment:
Votes: 0
Confuto said:
quixadhal said:
If you're doing something else, where the focus is on PvP, or GM-run events, or one-time achievements that don't just respawn… that's another story. It's also another story if you have a diverse enough class/skill/etc system so that going from the bottom to the top is very different from one character to the next. And, of course, you could have different story lines based on starting race, alignment, etc… which might lead you to totally different sets of content.

Wouldn't that require just as much content to be built as a hack-n-slash MUD, if not more?

Yes, and it wouldn't stop the problem of walkthroughs being posted online.

One way to deal with this is to randomize parts of the quests, that is, when finding the sad girl who looks for her doll, instead of the monster under her bed having it, it would be in various locations. Especially with one time quests this makes it difficult for altruistic people to make decent walkthroughs, which becomes increasingly difficult if a quest has two or three parts that are randomized. With games like WoW you'll likely still have coordinated efforts to make a complete walkthrough, but on a small MUD you'll get the satisfaction of people complaining that "the quest is broken" when their walkthrough fails them.
27 Oct, 2009, KaVir wrote in the 13th comment:
Votes: 0
Runter said:
After stats are assigned by said builder the system gives them a target ilevel. Their instructions to build the item must then add up to the target ilevel or more. They can tweak the stats on the item to actually lower the ilevel requirement. But until the stats are in compliance the item is a no-go. Requires no administration oversight. The builder may feel some of it is not balanced correctly, but that's probably not his job anyways. (Which I feel is a big mistake giving your content designers access to in the first place.)

That's along the same sort of lines as my propo.... I think it could work pretty well, although it would be difficult to balance the bonuses in advance. Arguably that's a separate problem, but it's still related to this issue.

It might be interesting to try a popularity-based equipment restriction system though. The more people who use a particular item, the larger the percentage of their magical item quota it uses up. If you've got a really big range of items (or the items are non-static) you could do a similar thing except with bonuses instead of items. That way, the items would tend to balance themselves (unless people start creating a lot of alts).


Scandum said:
Yes, and it wouldn't stop the problem of walkthroughs being posted online.

One way to deal with this is to randomize parts of the quests, that is, when finding the sad girl who looks for her doll, instead of the monster under her bed having it, it would be in various locations.

I would take it a step further, and add a little fuzzy logic throughout. The child might be a girl or a boy, the item they've lost could be one of a selection of toys or pets, and even the house itself could have its rooms arranged in various different layouts.

People will create walkthroughs anyway, but if the details are vague enough it starts to feel like less of a walkingthrough. Instead of "kill the monster under the bed, recover the toy, and give it to the girl" you end up with "find the creature somewhere in the house or garden, kill, bribe or negotiate with it depending on what sort of creature it is, recover the item it's taken, and return it to the boy or girl it was stolen from". The player would probably get more information just from reading the in-game quest details…
27 Oct, 2009, David Haley wrote in the 14th comment:
Votes: 0
KaVir said:
I would take it a step further, and add a little fuzzy logic throughout. The child might be a girl or a boy, the item they've lost could be one of a selection of toys or pets, and even the house itself could have its rooms arranged in various different layouts.

Do you really mean fuzzy logic, or just randomizing more pieces of the quest setup than the location of the girl's doll?
27 Oct, 2009, KaVir wrote in the 15th comment:
Votes: 0
David Haley said:
KaVir said:
I would take it a step further, and add a little fuzzy logic throughout. The child might be a girl or a boy, the item they've lost could be one of a selection of toys or pets, and even the house itself could have its rooms arranged in various different layouts.

Do you really mean fuzzy logic, or just randomizing more pieces of the quest setup than the location of the girl's doll?

I mean using values ranges for the quest attributes, with some values being considered 'better' (and thus more likely to be picked) than others, so as to provide variation to each quest without the quests being completely random.
27 Oct, 2009, Tonitrus wrote in the 16th comment:
Votes: 0
KaVir said:
Having to wade through piles of player-generated content, providing feedback on what needs to be done before it can be authorised, is likely to be a very time-consuming (and uninspiring) job. It's also going to irritate the players who are stuck in the backlog of work. This solution is fine for clan names, but it's not very scalable.

I don't like this solution much either. For room descs, which I don't really believe in anyway (static roomdescs, I mean), I came up with an idea of being able to background an item in a room. I.e., instead of a particular item being dropped "on the floor", you could set it in the background, possibly posing it, and it'd show up in the description. People could make alterable room descriptions this way. I don't believe in "named" items anyway, so generating short and long descriptions automatically is fine for me, but I can't think of any way to have item descriptions without auto-generating them, which is non-ideal.

KaVir said:
So it's almost like a farming game? You seed your fields (populate your area), then prevent mice and birds (other players) from eating your crops (killing your mobs) before they're ready to harvest?

While I cringe at the term, yes.

KaVir said:
This doesn't deal with the second problem though - "Players make super items as treasure". Even if the area only produces one UberSword per year, players will still want one for themselves. In fact they're unlikely to bother creating equipment they don't personally want, as it'll just make their area more appealing to attackers.

I omitted a detail. Players can create items anyway, without going through an area to do so. The price of items scales up (exponentially) based on the power of the item. I detest linear progression. If they want to make an UberItem for themselves, that's fine, they don't need an area to do it, and it will cost them a ridiculous amount. If they want to auto-generate UberItems for people who raid their areas, that's also fine, but will be vastly more expensive, and will result in their area being depleted/dying. The idea in doing areas in this way is to make players have a vested interest in the "success" of an area, since other players can attack them for conquest or any other purpose as well. As for players creating their own personal UberItems, that's awesome. Gives people incentive to kill/loot them.

Strong areas will tend to provide incentive for attackers, since they'll have powerful/useful items, tough mobs (presumably with lots of gold), but are hard to fight through. Weak areas may not have much in the way of rewards, but can be conquered easier, and every area will have *something* in the way of rewards, even if it's just the gold that mobs drop or material they drop for crafting purposes.
27 Oct, 2009, Scandum wrote in the 17th comment:
Votes: 0
KaVir said:
People will create walkthroughs anyway, but if the details are vague enough it starts to feel like less of a walkingthrough. Instead of "kill the monster under the bed, recover the toy, and give it to the girl" you end up with "find the creature somewhere in the house or garden, kill, bribe or negotiate with it depending on what sort of creature it is, recover the item it's taken, and return it to the boy or girl it was stolen from". The player would probably get more information just from reading the in-game quest details…

Additionally, some game elements are naturally walkthrough resistant, like finding NPCs that wander around a large area.
28 Oct, 2009, quixadhal wrote in the 18th comment:
Votes: 0
Scandum said:
Additionally, some game elements are naturally walkthrough resistant, like finding NPCs that wander around a large area.


That reminds me of a feature of my old MUD. We added the ranger class to the standard warrior/mage/cleric/thief mix, and since it was all new, we tried to make it fit nicely with woodland/outdoors/hunter type lore. So, the trainers (you had to visit your trainers to gain levels and skills) were themselves rangers, and rather than standing around town like all the other trainers, we had them wander in areas appropriate to their level and theme. This also introduced the newbie ranger to the "track" skill, since without it, it was a bit difficult to find the single wandering ranger in the sea of wolf-infested grasslands.

The players loved it when they were newbies, and utterly loathed it after about the third time they needed to go train. :)
28 Oct, 2009, David Haley wrote in the 19th comment:
Votes: 0
I'm not sure that being walk-through resistant due to being randomly positioned in a large area is a good feature, though – I think Quix's example shows how it can be interesting once or twice but then wear off very quickly.
28 Oct, 2009, Scandum wrote in the 20th comment:
Votes: 0
We're talking about one time quests, or at least, I was.
Random Picks
0.0/22