[MUD-Dev] Preventing recipe decomposition (why?)
Derek Licciardi
kressilac at insightBB.com
Thu Jul 25 22:18:01 CEST 2002
From: Sean Kelly
> From: "John Buehler" <johnbue at msn.com>
>> So, (to finally get to the point ;), what if you had a recipe
>> based system (crafting, spellcasting, etc) with, say, 8 different
>> actions that could be combined in sequences up to, say, 10
>> actions long, giving you 8^10 possible combinations, and then
>> every time a new player-character was generated, the server
>> randomized which of those possible combinations mapped to actual
>> game recipes?
> While I grant that such randomization would largely inhibit
> web-based recipe perpetuation, I have to ask what the real
> motivation is behind this aim, and if this approach really
> produces a desirable result.
[snip]
> Anecdotes aside, rather than ask how to make a skill system
> uncrackable, why not ask why you'd want to do such a thing in the
> first place.
I think I'd have to agree here. There is value in being able to
share knowledge. Isn't the idea to stop spoiler sites based from
the single player game? I remember a night where I stayed up into
the late hours of the morning looking at an Everlore forum that
contained about 20-30 people and 20 pages of text trying to decipher
a quest. Trying to work through a problem is not always a single
person issue. I've seen the same happen with players trying to
figure out a recipe, though most of the time the problem seemed to
be a content bug in the recipe and not what they were doing.
Players inevitably band together to solve a problem that they
struggle with, be it a quest or a recipe and this form of community
development can be a good thing. I'd go as far as to argue that it
is undesirable to have crafting systems that didn't promote
information sharing because community is what binds an MMORPG player
to your game.
[static item stat rant on]
It also seems to me that the days of static stats on an item are
quickly fading. Everything on the item needs to be dynamic and
based upon the character's skills in a semi-predictable manner. Not
all leather armor is exactly AC 2. It seems our game systems are as
much to blame for this perceived problem as the player's nasty habit
of decomposing our hard written recipes. I understand that there
are balance issues with making the core attributes of items vary but
we have highly sophisticated data analysis tools in the world today
and there is nothing stopping us from using those decision support
tools to balance a significantly more flexible and intuitively
complex crafting system. Too many of these crafting systems are
binary results producing.(ie you make the exact same item or fail)
The key doesn't seem to me, to be adding randomness for the sake of
confusing the player. If you add a game play element, it seems to
me that there should be a better reason than thwarting your players
because as a small team of developers we are no match for the
collective minds of our hundred thousand head player bases.
Add depth to the crafting system and force your players to
specialize because they can't learn it all. Make the depth of your
crafting system expand over time so that it is impossible to learn
everything about every skill then make the actual outcomes dependant
upon the character's skills and not some binary formula. Add layers
to the system forcing dependencies. Allow specialization to pay
dividends with even the easiest of items. A master blacksmith can
make horseshoes of higher quality than an apprentice and when the
master blacksmith makes them they are worth more to someone than the
apprentice made items. All too often your skill level dictates the
items you make and sell because of the game system. Granted, I
probably can't become a master making horseshoes, but if I am a
master blacksmith and choose to make my living making horseshoes it
should be viable and I should have an edge over the newbie.
[rant off]
Just my two cents. Ok two and a half cents.
Derek
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list