[MUD-Dev] Simpson's "In-Game Economics of UO"
Paul Schwanz - Enterprise Services
Paul.Schwanz at east.sun.com
Fri Apr 28 15:24:25 CEST 2000
Mike Sellers said:
> At the same time I think it's a good point that players *do* have this crazy
> expectation that they should be able to do something that's fun. Watching
> your business go down the tubes because you invested in breastplate-making
> like everyone else doesn't sound like much fun. If nothing else, every
> failure state (like making too many of some commodity) needs to have a
> potential out, so the player doesn't feel like they've wasted their time.
>
While I understand your point, I think that strictly limiting the game so that
_everything_ must be fun might end up taking as much from the game as it gives.
It's no fun to have your character killed, so should we make this impossible?
If we do this, we take away the fun of having your character's life challenged,
but overcoming the challenge. Thrill seekers like doing dangerous things
precisely because it _is_ possible to be killed. Having negative consequences
for failure may seem like a downer, but not having them makes success
meaningless. In my opionion, a game in which it is impossible not to succeed is
not much better than a game in which it is impossible not to fail. But you are
right that success and failure needs to be temporary.
Additionally, I think you are right that the player should not feel like they've
wasted their time. But I don't think that the answer is to take away from the
game an economic system in which there is the possibility of failure. Rather,
the trick would be to design the game so that the _character_ has wasted time,
but the _player_ has not. I may be wrong, but I think that the player becomes
frustrated because from his perspective, he's used up his _own_ game/recreation
time (that he's *paid* for) as a player to do some often very repetetive and
boring activity. He feels that he has _personally_ sacrificed and expects to
see something come of it. I think that if you lessen the personal sacrifice
required, you will automatically lessen the expectation. I'm becoming more
convinced that how a game handles _time_ is key to the success of its economic
engine. Here are some of the possibilities that I've heard regarding the time
issue.
1) Give each character a certain number of time units. When the time units are
gone, the character suffers permanent death. The character can use these time
units to perform time intesive tasks such as research, travel, skilling,
creating items, etc. The task will be accomplished immediately, so the player
is not penalized time-wise, but the character is. --Proposed by silky at webtoys,
a regular contributor to X-Roads and better half to Lum the Mad.
2) Have an offline scheduler to simulate characters performing certain tasks
while the player is offline. --Proposed by Delusion at X-Roads. for details,
see:
http://lum.xrgaming.net/rdot.html
3) Although I've never played it, I understand that Dark Ages has a system
where some type of "labor points" are accumulated while offline and can then be
pooled together to accomplish item creation, etc. This seems similar to 2), but
of a more simplistic (and perhaps limiting, since it doesn't address traveling
issues) nature.
4) Actually have the characters remain in the game as scripted characters when
the gamer has logged off. Or perhaps give the gamer the choice to have the
character remain in game or not.
I'm sure all of these have their strengths and weaknesses, but, as I said
before, I think that this issue needs to be addressed by one or more of these
(Does anyone know of other possible solutions?) in order to bring sane-ness to
economy and other game systems.
--Phinehas
-----------------------------------------------------------------
"All things are permissible,
but not all things are expedient."
-----------------------------------------------------------------
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list