[MUD-Dev] Crafting/Creation systems

[John Buehler]

Damion Schubert writes:
> From John Buehler:

>> I have an aversion to long hours of boredom punctuated by moments
>> of entertainment.  My most fundamental tenet to crafting is that
>> the boring part has to be entertaining.  If it can't be done,
>> then don't have players do that part.  Have NPCs do it and have
>> the players manage them.  I could easily imagine that harvesting
>> could be made entertaining, at least for a while, but it's not by
>> hearing the same chopping and cutting sounds and seeing the same
>> animation on the exact same tree graphic over and over again.
>> Every activity in a game that a player is invited to engage in
>> must be more entertaining than current combat systems.  And that
>> includes combat and forestry.

> Um, why?  I don't think at all that the fun of crafting comes from
> the complexity of the interface of crafting.  The fun of crafting
> is more externally-driven.

I'm sure that's the case for you and for many who get into crafting.
The current player base is strongly achievement-oriented.  I'm not
as achievement-oriented, so I represent those who are more
interested in the crafting process itself.  I'm also interested in
the achievement side of things, but not as much as you are.

> Overall, the one thing I'd stress is that one should recognize the
> difference between making crafting more fun, and simply making its
> interface more cumbersome.

Oh sure.  I agree with this.  Note that I consider the interfaces in
EverQuest and Asheron's Call to be quite cumbersome and, at the same
time, not very entertaining.  I think that Dark Age of Camelot
really helped me to distill the importance of making the crafting
operation itself entertaining.  Camelot didn't make the crafting
process annoying and painful, so the pain was removed.  But what was
left was just the creation of zillions of items in order to advance
the character's skill.  It reminded me that crafting really is a lot
of fun and can be entertaining in and of itself.  To be able to
create things and then sell them, have a positive impact on the game
world at large, etc, is gravy beyond that.

>> If you end up with recipe-based crafting, those recipes will be
>> published and all players will know how to make the stuff.  So
>> that cannot be the discriminator to separate serious crafters
>> from those who just want the end-result.

> If recipes are limited by knowledge only, this is true.  Consider,
> for example, the possibility that these recipes are physical
> objects (didn't EQ have a 'words of power' concept similar to
> this?)  Using real-world knowledge to create rarity is always a
> bad plan (although its worth noting that this sharing of knowledge
> is a fun and interesting design pattern in its own right and
> should not be discounted).

As described, I was fairly sure that Ron was emphasizing
entertaining the players by having them experiment with components,
producing player-known recipes.  I favor what you're talking about,
which is character-known recipes.  While the player may know the
ingredients through their character's knowledge, the character
cannot assemble the recipe without the in-game knowledge of the
character-known recipe.  Indeed, even knowing the ingredients may
not be transferrable.  If my character knows that powdered eye of
crocodile is an ingredient, I can tell you.  But if you have no way
of figuring out what powdered eye of crocodile is through your
character's perceptions, then you can't even go find the
ingredients.

I don't place particular emphasis on the exchange of knowledge
because I figure that it is simply the entertainment of games
predicated on player-knowledge.  It moves the entertainment out of
the game and onto the web.  While not necessarily a bad, thing, I
like to think that a game that causes players to visit *it* instead
of the web is a good game.

>> It's funny that you say this because I've presented this exact
>> comparison in defense of how unentertaining crafting systems are.
>> Designers do not 'get it'.

> We get it.  It's just a lot easier to talk about some of these
> things in abstract conceptual terms of 'what it should be like',
> and much harder to actually create a system that is fulfilling on
> that level.  And given it's hard enough to make ONE core game
> system (combat), other systems end up getting less time and
> resources than designers would prefer.

As Matt Mihaly has taken exception to, I often speak of these ideals
as something that should be embraced by the designers of the games,
yet I haven't built them into a game and published it.  I appreciate
the effort that goes into making software, being a long-time
software engineer myself.  I'd simply like to see more statements of
ideals by the active designers so that we can all know what the
ideals really are in your eyes.  If the problem with developing the
ideals is the difficulty of producing multiple core systems, then
that is a problem to be addressed.  Everyone in the industry may
have an unspoken understanding of the ideals and the challenges, but
those of us on the outside can't read your minds, only your posts.
What I read generally points to status quo, which is why I talk
about ideals so often.  It may simply be that ideals aren't
discussed because they are your stock-in-trade.  Just as I don't
hand out my source code as a software engineer, you don't hand out
your design ideas.  So I guess I'll continue to espouse my design
ideas into the vacuum.

If resources for multiple core systems is really the problem, then
maybe we should start talking about component design and development
again.  Yet another ideal to be discussed.

JB

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev