[MUD-Dev2] [DESIGN] Rewards

Sean Howard squidi at squidi.net
Wed Apr 18 12:49:10 CEST 2007


"cruise" <cruise at casual-tempest.net> wrote:

> Mike's original question still stands: how do we create situations that
> players find intrinsically rewarding, rather than having to bribe
> players with extrinsic rewards?

First, I'm glad you made the distinction between reward and rewarding.
Thanks for that :)

You bribe a player to get him to do something - probably something he
wouldn't otherwise do were he not lead around by the carrot. It's a form
of manipulation. You are saying to the player, I want you to play THIS WAY
and ONLY THIS WAY.

That has been the game design philosophy from almost the beginning, but I
think that sandbox games have really proven their worth as the antithesis
of this. With something like GTA3, you are given broad goals and a variety
of interacting behaviors and environments in which to accomplish these
goals. If your goal is to kill NPC-X, there is really no limit to how you
can accomplish that.

However, you can declare more immediate rulesets. For instance, in GTA3,
you might have a race where you can only use a particular kind of car and
if you miss a waypoint, you fail the challenge. This is okay in small
doses because you really are trying to deliver a particular experience to
the player. A designed experience.

That's where you use the bribes. For instance, if you create this giant
world, you want to give players incentives to explore it. But you can do
this different ways. The first way is to simply reward them for engaging
in the act itself. For instance, in WoW, you get small exp bonuses for
discovering a new area on the map.

The second way is to make the effect of exploration something worth
finding. If you removed all the enemies in WoW, the player would still
find it quite rewarding to just wander around and see all the different
zones and sub-zones. There's a lot of appealing variety there to
experience (compared to, say, SWG with miles of generic looking empty
wilderness). But after a while, one castle will look like another. Even
with a different floor plan, they are functionally the same. And this is
the problem of every mmorpg out there. The same old crap in different
clothes is still the same old crap.

So, to create a rewarding experience for the player without over reliance
on manipulating them into behaving like you want, you create a more
systematic world. A complex system which changes and modifies itself based
the ebb and flow of its pieces. You make every building functionally
different just by nature of where it is located, what inhabits it, and
what functions it performs.

I remember an example from Ultima Online where the population of the
different animals could be changed by players. Hunt too many rabbits, I
think it went, and the wolves would come into town to look for food. A
really cool idea, but unfortunately, it breaks the fundamental needs of
the player for security. The idea that they may not be able to find the
enemies they need, or that the actions of someone else could affect their
safety and enjoyment of the game.

That's how every system in the game needs to work, all without breaking
the player's need for security and peace of mind. If you make a crafting
system, it can't just be "collect 4 of these and push a button". It's got
to be systematically related. "Collect any 4 of these two dozen objects,
and whichever ones you use will make an impact on the quality and function
of the item you are trying to make". But it's got to affect function, not
just quality. Because the same old crap with slightly different numbers is
still the same old crap.

Anyway, you create a playground that a player can define his own role in,
and interact with at his own pace and play style, and there will be more
than enough intrinsic rewards from simply exploring this system,
understanding it, mastering it, exploiting it, or challenging one another
within it. You won't have to bribe the player to play your game, though if
you want to deliver a particular sub-experience, you will still have to.

-- 
Sean Howard



More information about the mud-dev2-archive mailing list