[MUD-Dev] "flat" power treadmill [was: Casual Crowd vs.Time Rich Crowd]

HRose hrose at tiscali.it
Mon Sep 6 01:40:33 CEST 2004


Raph Koster wrote:

> I think we can agree that designing a game that discourages
> players from playing regularly is probably a bad idea (at least in
> terms of mass acceptance--some games, like turn based games, PBEM,
> etc, have some flex here). Designing a game which allows players
> not to HAVE to play regularly, however, seems desirable.

I agree here. I was attacking the idea because there are games going
in this direction. For example Eve-Online has an advancement system
(aside the money) that is time-based and really just requires you to
log in from time to time, start train a skill and log off.

So a more interesting point is surely about *how* we give depth to a
game without requiring the player to play as much as they are able
to. This is an inner problem for every power treadmill that has the
result of producing gaps between the players. It's an interesting
design problem for one of the core issues about mmorpgs and the
"mass market".

But the context of the discussion was different. The context was
that, from the money perspective, it's better to have the players in
the game as little as possible to spare on the bandwidth costs. In
this case the players and the gameplay aren't anymore the reason of
the design and it's where the situation becomes "dangerous". Because
a possible result with this strategy isn't good and won't be
successful.

>>    I have many design ideas on how to solve the problem about
>>    "Casual Crowd vs.Time Rich Crowd" and they are along the lines
>>    of creating different structures inside the game where
>>    different players have different roles and goals. Where casual
>>    players have a specific role and goal and where time rich
>>    crowds have another. And the *key* is about giving them
>>    different roles but making they play *together* with the same
>>    general goal.

> The difficulty here is that is the roles have contributions to the
> goal inversely proportionate to the time investment required, that
> people will start to cross the roles in search of maximum
> return. The time-rich players will take on the casual roles
> because they offer greater reward for time invested. And if the
> casual roles do NOT offer greater reward for time invested, then
> they will not feel rewarding to the casual players either, who
> will compare themselves to the time-rich players and cry foul.

> The difficulty would be sharing a given metric across both
> roles--and if there is a shared goal, there will most certainly be
> some form of shared metric. I'd tend to approach this in terms of
> orthognal but equally valid goals, ideally with interesting
> intersections.

I find hard to keep reasoning on an abstract level. While writing I
was thinking to a particular PvP model where the players have access
to different ranks and roles based on a treadmill. These ranks and
roles define how you play in the same battle but allow each player
to still group together and play in the same situation. What isn't
considered is the strict "power difference". An higher rank doesn't
gain more powerful skills for himself (so that he could be able to
kill more easily a lower rank in a 1vs1 battle). Instead it just
gains access to a different role and specific gameplay.

The point is that a casual player can join the battle even if still
at the bottom of the treadmill. This won't mean that he'll be
uneffective or forced in an unfun role. The gameplay can still be
designed to be fun for everyone but different for various
players. As it happens when you have different classes in a group: a
different role for each player but within the same situation.

In my more specific idea a greater rank actually IS more
powerful. But the power works inside a battle system where we can
build a group of ten players and only *one* of those ten can be
designed as a General and so with a specific set of powers. In this
case you can go through a treadmill and become a general yourself
but:

  1- You'll never reach a point where EVERYONE MUST be a
  general. Because there will be only 1 each 10 players. Designed by
  them in a specific situation.

  2- Whoever doesn't have the time to "apply" for that position will
  keep enjoing the game in that precise moment and will still have
  an advancement system to pursue but not where he is *forced* to
  go.

This is similar to the point above: "Designing a game which allows
players not to HAVE to play regularly" but still rewards you when
you do.

A possibility without an obligation.

The idea just came out from observing the actual organization of
mmorpgs. In raids there are always leaders. These leaders have
obviously an high time investment into the game but their characters
are still powerful as any other player. What I did with my idea is
to institutionalize what already was happening adding gameplay depth
to the system.

I'd love to read some opinions about this because it's part of the
ground of my "dream mmorpg" and I want to know how solid or possible
is what I planned.

  P.S.  Just to explain better from a different perspective. Think
  to a traditional mmorpg where you can choose various
  classes/races. The system is simply built so that you have only
  "x" classes/races unblocked as you open an account. But if you max
  out one, gain "x" numbers of special points (treadmill based on
  the endgame, after you maxed out your power), you are able to
  "unblock" a new race or class that can bel cool but still not more
  powerful or effective than what you played till that moment. This
  means that in the game there's a reward but this reward isn't
  REQUIRED.

  My battle system for PvP goes even beyond this. In fact you will
  be able to "unblock" ranks and roles in PvP. But you don't
  automatically gain everything. Instead in each specific situation
  you can be "choosed" to be a general or remain a normal player.

-HRose / Abalieno
_______________________________________________
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