[MUD-Dev] Attractive Grouping (Was: Focus vs. Scope)

[cruise]

John Buehler wrote:
> Cruise writes:

>> I like the concept - I'd be worried about the havoc griefers
>> could cause, but certainly a very interesting idea.

> Perhaps I'm blinded by enthusiasm for my own ideas, but the grief
> potential isn't clear to me.  What griefing can players engage in?

Depends how the system is implemented for specifics, but anything
which requires players working together to acheive a goal will be
sabotaged - most open raids have to put up with small groups trying
to screw everyone else over.

>> The only difficulty is how to dish out rewards...it can't be
>> based on damage done, because that screws over support
>> classes. Measuring general utility or assistance provided is
>> probably intractable, or at least going to be perceived as unfair
>> more often than not.

> I believe that rewards should be granted by group consent.  How
> exactly to do this I don't know, but I do believe that something
> in the spirit of voting for players during the course of or
> immediately after a combat engagement is the way to go.  The
> voting may automatically cause rewards to flow to those
> individuals, or it may simply be that those individuals are voted
> as trusted individuals who can then decide who gets what.  It may
> be related to a 'friends' system with the assumption that I almost
> always vote for my friends.

> This is a slightly more dynamic version of what happens in large
> group attacks in other games.  Normally, only trusted people are
> permitted to join in on large group attacks, and the rules are
> clearly set out.  Specific people will collect rewards, lotteries
> will assign them to group members, etc.

> There may be other issues to be addressed, such as who is actually
> claiming to have been part of the battles.  If someone claims to
> be part of the battle, an appropriate icon hovers over their head.
> If players see someone with the icon and who is completely
> inactive during the fight, they may vote to have them excluded
> from the group rewards.  Players seem to be pretty good at
> self-policing things like that.

For every fight? I guess it depends what counts as one "fight" - but
for the impromptu grouping suggested above, it may be for a single
matter-of-minutes combat. Voting for rewards everytime would get a
little wearisome...  And while it works for occasional, high-profile
raids, where there's someone trusted in charge, I'm not convinced it
can scale all the way down to front-line combat.

>> Maybe a more flexible version of EQ2's combat locking? The first
>> player to a mob locks it, but other players can be invited to the
>> fight at any point - it would end up similar to grouping but on
>> more of a per-fight basis. Suddenly discover that your current
>> fight is harder than you expected? Yell for help, and any nearby
>> players can respond and join in for a share of the reward (and
>> perhaps penalty if the original player dies? Just trying to
>> balance the various abuse possibilities).

> I think that you're right back to individual rewards being the
> motivation to play, at which point groups are an annoyance.  Focus
> the design on group goals with appropriate entertainment for
> individuals and you're on the right path.

Heh. Maybe I'm more cynical than you, but I just can't see a game
with no personal rewards being popular. I'd love to be proved wrong,
and I agree it's a much better usage of the multiplayer framework.

>> Either of these systems would make actual /communication/ and
>> socialising an inherent part of playing the game, rather than
>> something which is just done in downtime.

> That would be an interesting hybrid.  It would still present some
> difficulties.  Lowbies would have to travel with highbies, else
> just getting to the highbie areas would be impossible.  The same
> with getting out of the highbie area, depending on the impact of a
> character death.  There would be issues with who gets what from
> the rewards, given that items would surely be commensurate with
> the higher level powers of the highbie characters.

If you don't want power tied to success, then avoiding an overflow
of stat-boosting equipment is probably a good idea. I still dream of
an RPG where success depends on skill, not equipment.

> In short, character power levels partition content.  Because
> content is usually partitioned geographically to keep more
> powerful opponents away from less powerful player characters, it
> results in geographic partitioning of players.  Net result: player
> partitioning according to character power levels.

There seems little reason to force players apart like that...most
MUD's I've played have really tough opponents (like the shopkeepers,
town guards, etc.) mixed in with the starting town's newbie
fodder. I've found this helps socialisation a lot, as there are
often experienced players around with the newer players.

> Make achievement roughly orthogonal to the basic activity of the
> characters and the problem is avoided.  Instead of fighters
> becoming better fighters, they are granted esteem by NPCs.  If
> NPCs are sufficiently interesting vending machines, then that
> esteem (usually referred to as 'faction') can translate into
> interesting vending actions.  What I call 'favors'.  A faction and
> favors system permits players to be rewarded for their actions,
> but without power accrual, and in a variety of ways.

<snip>

> The idea is to move orthogonal to the single track of character
> power accrual.  Let the game be more multidimensional, and let the
> achievements impact the multidimensionality of the game instead of
> the linear track that we're used to seeing.

I think one of the big changes for MMG's will be the splitting up of
"XP" into different types of experience and accomplishment. So
combat, crafting, team-leadership etc. all get their own
metrics. And as you say, faction opinions can be another measure of
success.

--
[ cruise / casual-tempest.net / transference.org ]
   "quantam sufficit"
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://kanga.nu/lists/listinfo/mud-dev