How to Get Rid of Players

• rudeness/obstreperousness
• capriciousness
• favouritism
• lateness/laziness
• blatent lying
• irritating advertisements

But this is not usually enough!

• People expect it (from other players) anyway.
• People get it (from their ISP) anyway.

Something more specific to the needs of online games is required.

Critical Mass that's all players are

• Therefore, get below that level!
• The more people you can annoy, the more will leave.
• Target large groups of players.
• Target individuals with lots of friends.

Two main ways to increase size of critical mass needed:

• Spread players too thinly so they never meet each other.
• Cram players together so they can only meet each other.

Corollary:

• gag them
• spam them.

Charging Methodsthat really frighten

• Don't make spurious, unjustifiable charges.
• Make spurious, justifiable charges instead.

Charge for everything you can think of:

• sign-on fee, sign-off fee, per hour, flat fee per month, per character, per email, ...

Have at least 6 pricing policies, all tailored to the needs of non-existent people and with no way to compare them.

• Vary prices and charging mechanisms often.

Make signing on a challenge in itself.

Players as Game Designers

• They're free.
• They know what they want.
• They're keen.

You don't say:

• They're clueless.
• They don't know what everyone else wants.
• They have copyright on what they design.

Player designs make a game unattractive to all but that player.

• Inconsistent, incomplete, context free, arbitrary, unoriginal.
• Tell the designing player this, and you lose them too!

Tenets of Crash Design

Delay all stages in the bug-fixing process.

For optimum results, crashes should:

• occur at the point where character loss is most likely
• occur towards the end of highly publicised special events
• be occasionally proceeded by ominous lag, so when this happens naturally they automatically fear the worst
• require players to reboot their PC, modem or BIOS
• Never be explained. Don't even blame the hardware.

Client Software making your game hackable

Challenge hackers! Say your system is foolproof. Mock them.

Your client should:

• store critical information on disc ("in binary" for security)
• make game-critical decisions itself
• make no attempt to encrypt transmissions
• use a simple protocol, the specifications of which are proudly displayed on your web site
• be written in some painfully slow language
• be impossible to install at the first attempt.

Fomenting Discontent the easy way

Give it a fixed lifespan.

• If you only know about shelf life, use that experience.

Reward players automatically for harming others.

Make gameplay suddenly become very difficult at an arbitrary level.

Make your game shallow.

• Expose this with a huge and expensive but banal manual.

Make your user interface picky and petty.

• If it's intuitive, rewrite it.

Everything should be visually unattractive, or clash horribly.

20% of the help files should be missing or out of date/incorrect.

Game Management an undue expense

• Except the real cheats.
• The more public, the better.

Don't train your game managers.

• No training is even better than bad training: it delivers unbeatable inconsistency.
• Hey, no-one can sue you for giving bad advice!
• Prefer people you are forced to employ by law.
• Sack anyone who turns out to be good at it.

Beware! There could be plenty more players where the ones you scare off came from!

• Make sure they tell their friends not to play, too.
• Angry players can stay away forever.

Conclusion

Some of what I've described may seem rather unbelievable, but it's all grounded in reality.

• Developers really do make these errors.
• Time and time again...
• Worse, sometimes they know it's a mistake, but the publishers who financed them insist they make it anyway.

The best way to lose players is not to have them in the first place.

• The danger is, that no-one else gets them after you've finished with them, either.