Re: Mechanisms to combat multiple-entry by a player

From: bcd@pvv.ntnu.no (Bent C Dalager)

Date: Tue, 10 Jun 2003 16:35:42 +0000

In article <3EE6016B.BE755D35@spam.me>, Stephen Baillie  <dont@spam.me> wrote:
>Only if the GM has set up the starting conditions in a particularly
>stupid way.  If the objective is to make multi-playing pointless, then
>sure, they can restart - and move their new mercs three turns out from
>the starting city, and have them disappear again.  Let players do that -
>they may be trying to do a better job, or correct some mistake they made
>last time, but if they're after power that way, then all that will
>happen is that they'll get real sick of the terrain around the starting city!

For the mercs to be beneficial to players, then there must be
something profitable they can do within the first three turns.
Presumably, this involves gaining the player his proper assets. It
would be natural, then, for the multiplayers to run many merc-squads
in order to pile up on these merc-obtained assets. You're basically
just delaying the "new setup freebies" by three turns.

>> I have found it rather a recurring theme in PBMs. BSE certainly had
>> this problem. Entire fleet battles were fought with starter ships at
>> times.
>
>It really is a design issue.  If it's a recurring theme in your
>experience, maybe this just shows that there are a lot of bad designs
>out there?

It certainly is a design issue. I still haven't seen a game that
managed to avoid it though, except by accepting multiplayers.

>> 1) Contact other players in order to obtain starting equipment,
>> loans, missions, whatever.
>
>I like that idea, but it has a problem with its starting condition - who
>loans the first player stuff?  If the game itself makes loans to new
>positions, this seems fairly similar to my mercenary suggestion.

Bootstrapping the system is a different matter of course. One
practical way of doing it would be to let the beta testers start the
proper game with a range of assets. If you ever find yourself low on
high-resource players, you could introduce some special event or other
to help you inject wealth into the game. A competition of some sort
perhaps.

You probably can't do an automated loan system that would be useful to
starting players because it would be difficult to not walk into the
multiplay trap with such a system.

>That idea does raise another set of design questions though.  WHY would
>players give such loans to new positions?  If the players involved are
>roleplayers, then I can see this happening, but it might not work so
>well in wargames...  You need some kind of mechanic that encourages
>players to work together, but doesn't encourage just starting a second
>position to gain the same advantage.

In a PBM, the main value of other players will often be simply that
they are other players. There's a number of ways in which this can be
valuable.

1) Someone to communicate with so you can share ideas, plan more
effectively, etc.

2) They help extend your capacity to do stuff. Depending on how much
planning the game takes for each player, the extra man-hours supplied
by an extra player on your team could be very beneficial. They could
also bring in skills you don't possess (perhaps logistics completely
escape you).

3) They can help you deal with out-of-game stuff such as player-player
diplomacy, running the alliance web site, whatever.

4) The social aspect.

>The sort of things that work this way seem to be where you have certain
>game rewards that are not transferrable from one player to another -
>characters in a party based game, skills in a single character game -
>and that there is a limit to how many of these a position can have.
>They can get new ones only by dropping old ones (and presumably they
>would drop less useful ones for better ones as the game progresses).
>I've seen some attempts at this, and I suspect that these rewards need
>to be earned in-game to make them worthwhile (some games, like Atlantis,
>let you change your faction point allocation any time, where FPs are the
>key limiting resource, but it generally takes a while to transform your
>faction into a new shape).

I think this is exactly what causes multiplaying and so should be
eliminated in favour of a system in which any one player isn't limited
in any other way than how much stuff and how clever stuff he's capable
of ordering done.

As an example, if any one player isn't allowed to run more than one
position max and for this position he has to choose whether it is to
be a fighter, mage or cleric then you're basically _asking_ for
multiplayers to run at least three positions.

>> 2) Play any one of a number of information-based minigames aimed at
>> generating small amounts of money and that requires a lot of player
>> attention in order to succeed in. Anyone already inside the game can
>> play these games for profit if they wish, but the payback is
>> sufficiently small that most established players will have more
>> profitable ways to spend their time.
>
>Cute.  I guess the mercs idea is similar, but the minigame is actually
>the main game played with a time limit (and on a smaller scale)!

The tricky bit, though, is to make the minigame non-automatable. If
the player is capable of writing a bot that can play the minigame for
him and earn a net profit, you've lost. I don't know yet how to
eliminate this loophole.

Cheers
	Bent D
--
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs

References

Mechanisms to combat multiple-entry by a player
wavey@parcelfarce.linux.theplanet.co.uk
Sun, 08 Jun 2003 10:01:26 +0000
Re: Mechanisms to combat multiple-entry by a player
Stephen Baillie <dont@spam.me>
Tue, 10 Jun 2003 13:34:39 +0000
Re: Mechanisms to combat multiple-entry by a player
bcd@pvv.ntnu.no (Bent C Dalager)
Tue, 10 Jun 2003 14:12:16 +0000
Re: Mechanisms to combat multiple-entry by a player
Stephen Baillie <dont@spam.me>
Tue, 10 Jun 2003 16:04:10 +0000

Referenced By

Mechanisms to combat multiple-entry by a player
wavey@parcelfarce.linux.theplanet.co.uk
Sun, 08 Jun 2003 10:01:26 +0000
Re: Mechanisms to combat multiple-entry by a player
Stephen Baillie <dont@spam.me>
Tue, 10 Jun 2003 13:34:39 +0000
Re: Mechanisms to combat multiple-entry by a player
bcd@pvv.ntnu.no (Bent C Dalager)
Tue, 10 Jun 2003 14:12:16 +0000
Re: Mechanisms to combat multiple-entry by a player
Stephen Baillie <dont@spam.me>
Tue, 10 Jun 2003 16:04:10 +0000