Player Contracts

INTRODUCTION

In writing an essay on the Economic Stages of MMORPGs, I came up with the notion that online games would benefit from providing more ways for players to interact economically. This idea of "player contracts" seemed like a particularly worthwhile idea to explore, so I've developed that idea further here.

Please note that this is a fairly lengthy document. That's not because the concepts are particularly complex, but more because I wanted to give the details a good airing to try to address the most likely objections. If you're able to take the time to read this proposal and give the whole thing fair consideration, I appreciate your effort. Thanks!

WHAT ARE "PLAYER CONTRACTS"?

A player contract is an agreement between players to exchange items of value that is enforced by the game system. This document will describe a design proposal for implementing this concept within Massively Multiplayer Online Games (MMOGs) and detail the reasoning supporting the proposed implementation.

WHY PLAYER CONTRACTS?

I go into the "why" in greater depth in the Economic Stages of MMOGs essay, but in a nutshell: virtually all MMOGs are stuck in an economic Stone Age because they don't offer the necessary in-game systems to support more advanced economic activity. In the absence of an in-game system of laws that establish the level of trust necessary to enable economic cooperation, gameworlds must establish trustable systems in code... but beyond one simple form of such trustable exchange systems -- the Secure Trade Window -- they are not implemented.

The result is that while goods and money can be traded in one-shot deals, that is a significant restriction on the number and kinds of economic activities that could otherwise occur in a gameworld. A more advanced economic system in MMOGs is desirable because it would deepen the playing experience by allowing more competitive and cooperative player interactions. This would greatly expand the range of economic gameplay opportunities available to all players, in the same way that legal systems in the Real World enable economic cooperation that would otherwise suffer from an unacceptably high level of risk. Therefore, identifying and implementing more advanced forms of economic activity in MMOGs is desirable.

Several key in-game systems need to be designed and implemented to permit an advanced online economy. One of these is a system of cheat-resistant player-to-player trade agreements, or "player contracts." Early MMOGs allowed players to exchange goods and money, but these proved to be susceptible to several forms of cheating. The fear of being cheated thus limited economic activity. To counter the most common cheats, the Secure Trade concept was devised. By encoding trading rules that prevent the twin scams of item misidentification and item substitution, a Secure Trade allows players to trust each other when considering whether to exchange goods and money. This increased trust encourages more economic activity than would otherwise have taken place, which is the goal this proposal aims to deliver, so it's worth examining the Secure Trade concept in more detail to see how this is accomplished.

As noted, Secure Trades promote trust by protecting players from the two most common trading scams. First, a Secure Trade Window shows item names and item descriptions separately, using a game rule that allows players to set item names but retains system-generated item description text. Displaying system-defined item descriptions tells each player exactly what is being offered, preventing unscrupulous players from selling items with "fake" names. (For example, the description of an item can't read "+10 Healing Juice" and just be a bottle of water. If it's just water, the description of the item will say so no matter how the item is named.) Second, a Secure Trade prevents the terms of a deal from being modified after one person has agreed to the deal. As soon as one player accepts the deal as offered, the only options are to accept or cancel the deal in its entirety. This restriction prevents a player from replacing a good item with a piece of junk after the other player has agreed to the original deal.

These two features of Secure Trades allow players to trust other players in exchanges because they know they'll get what they think they're getting. It's still possible to make bad deals on the value of the goods exchanged, but at least players can trust that the system itself won't be used to cheat them.

But it's also true that Secure Trades are limited in two important ways. First, they only let players trade goods and money. That's fine as far as it goes, but what if I as a player want to offer a service to another player within the game? How can we trust each other to keep the terms of an informal agreement when there's no system-controlled enforcement of those terms? Second, Secure Trades are one-shot, immediate deals. They don't allow a player to establish an ongoing business relationship with another player by creating deals that happen in the future, or that happen more than once. Again, such agreements can be and are made informally in active MMOGs, but not as many as might be made if players had access to a game-controlled mechanism for enforcing the terms of trade agreements.

Still, the Secure Trade system, while limited, does work. That makes it a good base on which to attempt to build a more advanced trade system in which a single exchange of goods and money is just one type of player-to-player contract within a general contract system. Secure Trades increased economic activity by establishing trustability in simple exchanges; Player Contracts can increase economic activity yet again by expanding the number and types of trustable interactions that can occur. The rest of this document will discuss specific elements of a Player Contracts system for use in MMOGs.

PLAYER CONTRACTS OVERVIEW

This design defines a Player Contract to be a general trade agreement between two players whose terms are enforced by the game. Player A (the "contracting player") agrees to provide goods or money to Player B in exchange for Player B (the "contracted player") agreeing to provide goods, money, or a specific service to Player A. (Exchanges of money for money would not be allowed, of course, unless a MMOG offers several different currencies and wants to allow arbitrage.)

Two modes of player contract are possible in this system: the Personal Player Contract, negotiated iteratively in real time between two players whose characters are within a certain minimum range of each other in the game world, and the Open Player Contract, specified by a contracting player but publicly available for acceptance by any player.

Before the mode of a "live" contract is set (determined by how the contracted party receives the contract offer), it might be useful to generate "draft" contracts.

THE DRAFT PLAYER CONTRACT

Any player would be able to generate a draft Player Contract. A click of the appropriate button would cause the Player Contract Window to be displayed on the player's screen. She would first select the desired contract type from a drop-down list. Once a contract type is chosen, the terms specific to that contract would be displayed and the possible options within each contract term would be selectable. When the values of the initial contract terms are set to the player's satisfaction, she could set the contract aside in her inventory for later use. If she subsequently offers the draft contract to a nearby active player who agrees to the terms, the "live" contract is created at that time as a Personal Player Contract. If instead she offers the draft contract to some form of game-controlled public system for retaining and displaying potential contracts, then once another player agrees to such a contract it becomes an Open Player Contract. If a player who is offered a draft contract rejects it, or if the player who created a draft contract retrieves it unaccepted from a public contract display system, then this contract returns as a draft Player Contract to the inventory of the player who created it.

Note that for technical reasons it might be undesirable to allow players to generate and retain draft contracts. In this case the mode of contract a player generates (Open or Personal) would be determined by the means of generation. A Personal Player Contract would be generated by offering a contract to another player, with all contract terms negotiated in the Player Contract Window at that time. An Open Player Contract would be generated by offering a contract to a "contract terminal," or to a "broker" NPC, or to some other game-controlled public contract provider appropriate to the game milieu. The player offering the contract would be able to set all applicable contract terms in the Player Contract Window until the contract is offered to the public contract provider.

In either case, if the player making the contract offer will be providing actual money or goods as payment, then the full value of the payment (for each time the contract is activated) must be transferred from the contracting player's personal inventory, bank vault, or bank account into the contract's "payoff account" container. This requirement will insure that the contracting player is actually able to make the deal being offered, which will help reduce the number of frivolous contract offers.

PERSONAL PLAYER CONTRACTS

The contracting player of a Personal Player Contract would begin a negotiation by offering a contract to another nearby player. If the other player accepts the offer to negotiate a contract, the Player Contract Window is displayed on both players' screens. The Player Contract Window would initially offer a choice of contract type. When a particular contract type is selected, the contract terms specific to that type of contract are displayed, possibly with some default settings selected. The contracting player would set the initial terms, then the contracted player would then have an opportunity to alter the terms of the contract. The contracting player would then be able to alter the terms again, and so on. This process of iterative negotiation would be allowed to continue until one player cancels the contract offer or both players explicitly agree to all the terms. Note that, as with the Secure Trade Window, once either player has indicated agreement to the terms displayed in a Player Contract Window, the other player may not alter any of the terms -- the only options available at this point are to accept the contract as-is, retract the conditional agreement, or cancel the contract offer entirely.

Among the terms that both players may negotiate are the specification of what will be exchanged and in what quantities, when exchanges will occur, whether either party can cancel the contract without penalty, and (optionally) any penalties for canceling a contract or otherwise failing to meet the terms of the contract. As noted above, the contracting player would initially be required to transfer to the contract the full amount of goods or money being offered for exchange. If the deal is a simple swap of money for goods, the contracted player would then enter at least one unit of some good currently held in his personal inventory into the contract's "provision account," then specify the number of units of this good to transfer each time the contract is activated. (Requiring at least one unit of a good to be put into any contract account is necessary to avoid forcing players to choose from a gargantuan list of all possible goods. Not only would this be a complex data structure to store and display, it might reveal some resource details a little too conveniently.) Optionally, both players could also enter some amount of money into a "penalty account" if there is to be a penalty for failure by either party to adhere to the terms of the contract.

OPEN PLAYER CONTRACTS

Although the contract system was originally envisioned as allowing two players to negotiate contracts together in real time, the system could be extended to allow what I call Open Player Contracts, that is, contracts created by one person and placed in some public location. Other players could browse the list of contract titles from the public contract provider, then examine the details of a specific contract whose title sounds interesting. Note that to prevent two players from taking the same contract, as long as a contract's title is visible to one player it should not be displayed by any other contract provider list. If the player reading the open contract likes all the terms as stated by the offering player, he would agree to them and the contract would go into effect between those two players (with appropriate contract documents provided to both players). If the proposed contract isn't acceptable, the player reviewing the details simply cancels and the contract is restored to public availability. In essence, an Open Player Contract is simply a publicly available contract to which the contracting player has already agreed.

The downside of this approach is that the contracted player wouldn't be able to alter the terms of the contract; his only choices would be to accept all the terms exactly as laid down by the contracting player, or else to reject that contract entirely. But the standard two-way negotiable Personal Player Contract would still be available to players who prefer to haggle over terms. Allowing open contracts would merely expand the scope of contract availability.

ACTIVATING A PLAYER CONTRACT

As soon as both parties agree to a contract, it takes effect. If both players have at least one available slot in the appropriate part of their personal inventory, and if the specific type of contract that was agreed to was not of the "immediate" variety (defined below), then both players receive a contract document as an inventory item. (In Star Wars Galaxies, for example, this could take the form of a file in the character's datapad.) This document lists the terms of the contract in a read-only form.

Once the terms of the contract are met and the contract is "activated," the goods or money in the contract's payoff account are transferred to the contracted player, while the specified amount of any goods or money named in the provision account are transferred from the contracted player's inventory or bank account to the contracting player's inventory or bank account. In the case of an immediate contract (see below for the definition of an "immediate" contract), this transfer occurs as soon as both parties agree to the contract. Any goods offered by the contracting player are transferred from the contract's payoff account to the personal inventory of the contracted player, while any goods offered by the contracted player -- in the amount specified by the contract -- are transferred directly from the contracted player's personal inventory to the personal inventory of the contracting player. (This approximates the current behavior of Secure Trades to remain consistent with existing functionality.) Similarly, money is deducted from the payoff account to the contracted player's bank account, or directly from the contracted player's bank account (in the amount specified by the provision account) into the contracting player's bank account.

More complex contracts would allow for multiple exchanges of goods and money (or services) at specified intervals, and for exchanges that take place at some time in the future from when the contract is agreed to. Money transfers would automatically deduct the amount of money specified in the contract from the offering player's bank account and add it to the other player's bank account. Similarly, if goods are being exchanged the allotted number of specified goods would be taken from the offering player's bank vault and placed in the other player's bank vault. Note that non-immediate exchanges (that is, exchanges set to occur some time after the contract is signed) use player bank vaults rather than personal inventories to minimize problems caused by personal inventories being temporarily full at the moment a future contract is activated. However, a contracting player would still be required to put the full amount of goods or money into the payoff account for the first exchange -- again, this is to give players who are offered contracts the reassurance that the offering player can actually deliver on his promised payoff.

One possible modification of this system would be to require that the contract system automatically replenish the contents of the contracting player's payoff account each time the contract is activated (rather than taking goods or money from the contracting player's bank vault or bank account after the first exchange). This would appear to automatically deduct goods or money from the contracting player, and so might not be desirable. (Automatically crediting goods or money is fine, but automatically deducting goods or money could lead to player complaints if it causes too many contracts to fail due to insufficient goods or funds.) It would, however, provide further assurance to a contracting player that the contracting player is always able to fulfill the agreed terms of a deal each time it is activated.

In all cases, if at any moment of contract activation either player doesn't have enough of the agreed-upon goods or money, or doesn't have enough room to receive the provided goods, or in any way cannot provide or receive the goods or money or service required by the terms of the contract, then that player will have broken the terms of the deal. At this time any items in the payoff and provision accounts are returned to their original owners (if possible), any money in the penalty account is transferred to the bank account of the player who did not fail to be able to give or receive money or goods (or is split between the players if both failed to be able to give or receive the agreed-upon goods or money), the contract documents are deleted from both players' inventories and the contract terminates. Additionally, deleting the contract document will constitute canceling the contract, and may under certain circumstances (see "bilateral contracts" below) cause any penalty money to be transferred to the player who did not cancel the contract.
Now that the basics of the Player Contract system have been described, let's examine the specific features of this system.

PLAYER CONTRACTS FEATURES

A system to allow Player Contracts should implement the following features:

• allows a variety of reliably-identified things to be exchanged
• allows a variety of times when exchanges can occur
• allows players to specify how the contract may be successfully terminated
• allows optional player-selected penalties for breaking a contract
• supplies a way for the system to know when the terms of a contract are met or broken
• automatically applies agreed-upon exchanges or penalties based on contract status

1. VARIETY OF EXCHANGE TYPES

Numerous specific and distinct contract types should be available. These would normally mirror the types of NPC missions the game already offers, with perhaps a few additions, omissions, and modifications.

Examples of possible contract types are:

Exchange	swap goods for goods or goods for money
Tribute	give another player goods or money for an unspecified reason
Transport	move items [or player characters] to a specified location
Delivery	give items to a specified player character or NPC
Recon	go to a particular location
Obtain	take possession of a specified item
Entertain	perform within 20 meters of a specified player character or NPC
Heal	heal or cure a specified player character
Buff	temporarily improve the stats of a specified player character
Craft	create a particular kind of object, possibly with certain stats
Hack	bypass the electronic security of a container or item
Destroy	eliminate a specific lair, destroy a unique item, or kill a creature mob
Guard	defend a specified player character or NPC for a specified time period
Bounty	kill a specified player character or NPC [who must agree to be a target]
Marriage	marry another player character [allows for divorce, too]

(Please note that this is not a definitive list! There are probably plenty of other types of contracts that players might want to engage in. But these, I think, are a good first cut at the most popular contract types.)

Each of these contract types would have optional terms, some of which might be common to most or all types, and some of which would be specific to that contract type. The Exchange contract, for example, is our old friend the Secure Trade, but with additional options for when and how often to make such trades. (Time options are discussed in the next section.)

The Recon contract would simply offer a reward for scouting out a given location. (This sounds easy... but should it be possible send an PvP-enabled player to spy on some location deep within a city of an opposing faction? Could a PvE-only player be sent as a cutout who can't be attacked? The point here is that the terms of any contract type would need to fit the context of the game.)

The Delivery contract, as a final example, would let you pay someone to give a droid containing the plans for a terrible new Imperial weapon to a hermit living somewhere in the desert on Tattooine... you get the idea.

2. VARIETY OF EXCHANGE TIMES

Player exchanges should be allowed to occur in any of the following five ways:

• once immediately (this is the basic Secure Trade)
• once at a set time in the future
• once at some undetermined time in the future
• repeated regularly until a set time
• repeated regularly until manual contract termination

Another way to look at this is to say that contracts should be specifiable in terms of lifespan and frequency. Lifespan options are:

• immediate
• limited
• indefinite

and frequency options are:

• one-time
• recurring

So Contract A might be set up as an immediate+one-time deal -- you and the other player swap goods or services or money once, and that's it. (This is the standard Secure Trade.) Contract B could be a limited+one-time trade, in which both players identify types and amounts of goods or money to be exchanged, but the actual exchange does not occur until the selected time. (This could be useful for selling resources you haven't gathered yet.) Contract C might be made as a limited+recurring deal -- for example, you and the other player swap the agreed-upon goods and money every 24 game hours until five game days have passed, at which time the deal automatically expires. Contract D might be made as an indefinite+recurring deal -- you and the other player exchange the agreed-upon goods/services/money every 12 game hours until the end of time... or until one of you defaults on the contract or manually terminates it.

3. PLAYER-SPECIFIED CONTRACT TERMINATION

Contracts should have two mutually exclusive termination options:

• unilateral
• bilateral

Unilateral simply means "one-sided" -- one player may choose to end the contract without the other player's agreement, and this won't cause the penalty (if any) to be applied. A bilateral contract, on the other hand, would require agreement by both players to terminate a contract without penalty. If Player A and Player B agree to a bilateral contract and Player B terminates the contract without Player A's consent, then any penalty would be applied against Player B as described in the next section.

4. VARIETY OF PENALTIES

There are two types of penalties that could be applied if one player breaks the terms of a contract:

• monetary
• bounty

A monetary penalty is a lump sum of cash given to the player who didn't break the contract. When agreeing to the contract, both players agree to a total amount of cash to be placed in a "penalty account." Half of this amount is deducted from the bank accounts of both players as soon as the contract goes into effect to insure that the penalty can be paid if necessary. (If either player has insufficient funds to cover the amount agreed to, both players get an error message to that effect and the contract is not agreed to.) Once the contract goes into effect, if one player breaks the terms of the contract, all the money in the penalty account is transferred to the other player's bank account and the contract terminates.

Another optional penalty would be to subject the person who prematurely breaks a bilateral contract to a Bounty contract that can be taken by a Bounty Hunter. Both contractees would agree on a bounty amount, half of which would be transferred from each player's bank account into the penalty account when the bilateral contract is agreed to. As soon as one player breaks the contract, the original contract is terminated; a Bounty contract is created and becomes publicly available with the money in the penalty account set as the reward; and the player who broke the original contract receives a "Bounty Flag" (like a TEF, but handled separately from a TEF). The first bounty hunter who kills the flagged player character immediately has his bank account credited with the bounty from the penalty account; the contract-breaking player's clone has the Bounty Flag lifted (so that he's not a permanent target); and the bounty contract terminates. (Note that other forms of dying, such as being killed by a monster or NPC, do not remove the Bounty Flag!)

It would be entirely up to the two players making the deal to decide whether they want to apply a penalty at all. In other words, penalties would be optional -- if neither player wants one, then they shouldn't be forced to have one.

5. AUTOMATIC TERM RESOLUTION

The contract system must be designed so that the game itself recognizes when the terms of a contract have been fulfilled or breached. Leaving it up to players to decide when the terms of a contract have been met would open the contract system to subjectivity, which would effectively doom a contract system. If some MMOG wanted to implement a game feature in which players could be lawyers and judges, and thus offer some means by which to litigate contract disputes, fine; otherwise the game system itself should be established as the ultimate impartial arbiter of contract resolution.

This ability to detect the satisfaction of contract-related conditions is the beating heart of the Player Contracts system. The game absolutely must be able to reliably detect when the terms of contracts have been met or breached. The technical issues involved should be investigated to insure that this is possible. As a starting point I believe such a condition-monitoring system could be implemented as part of a "contract engine"; that is, as a cluster of tightly-integrated code modules which would perform the following tasks:

• add new contracts to the list
• update conditions of specific contracts based on game events
• scan all conditions and possibly update contract status
• apply any terms triggered by "activated" or "failed" contract status
• set recurring "activated" contracts to "open" status
• set "failed" and "activated" contracts to "complete" status
• remove "complete" contracts from the list

There are two possible states for a condition: "false" (when a contract is created), and "true" (when something in the game has happened that is part of the terms of the contract). In addition, conditions themselves are classified as either "positive" or "negative."

Contracts themselves can have four possible states: "open" (when a contract is waiting for conditions to be fulfilled), "activated" (when all positive conditions in a contract become true), "failed" (when any negative condition becomes true), and "complete" (when all positive conditions in a one-time contract become true, or any negative condition becomes true, or a unilateral contract is cancelled).

To be clear about how contract statuses change: if when a contract's conditions are scanned all positive conditions are true, set the contract's status to "activated"; if any negative conditions are true, set the contract's status to "failed." The "activated" status corresponds to successful fulfillment of a contract's terms, while a "failed" status indicates that something has happened to make fulfilling the contract impossible (that is, the terms of the contract have been broken). Certain other conditions (canceling a unilateral contract) will simply set a contract's status to "complete" without forcing either a successful exchange or a penalty application.

To see how this would work, let's consider an example. Suppose a player accepts an indefinite+one-time contract to destroy a creature lair. A Destroy contract (let's say it's also a bilateral contract) is created and maintained in a list of contracts. If the contracted player destroys the specified lair, the game system must recognize this event and update the value of the positive "contracted player has destroyed lair" condition for that particular Destroy contract to "true". Since this is the only positive condition, the contract's status is set to "activated"; the terms for successfully performing the contracted task are activated (that is, the contents of the provision and payoff accounts are swapped); the entire contract's status is changed from "activated" to "complete," and at the proper time the completed contract is deleted from the contract list (and the contract documents in the inventories of both players are deleted as well).

If (using the same example) the lair despawns or ceases to exist for any reason other than because the contracted player destroyed it, then this fact must be signaled to the appropriate condition in the Destroy contract in the contract list -- specifically, the value of the negative "player cannot destroy lair" condition would be set to "true." When this contract's conditions are scanned, the contract's status would be updated to "failed"; when contract statuses are checked any penalty terms specified by that contract would be imposed on the appropriate player; the contract's status would be updated to "complete"; the contract would be deleted from the contract list; and the contract documents would be deleted from the inventories of both contracting players. The same results would follow if any other negative condition were met, such as (since this particular contract was specified as a bilateral contract) if either player destroyed his contract document. Had this been specified as a unilateral contract, destroying a contract document would cancel the contract, which would activate the "contract destroyed" condition causing it to be removed from the contract list, but no penalty would be imposed.

6. AUTOMATIC RESULT APPLICATION

When a contract's status changes to "activated" or "failed," either the payoff or (possibly) penalty -- as agreed to by both players -- is applied immediately by the game system.

When a contract's status is checked and found to be "activated," the results of successfully fulfilling the terms of the contract will be carried out by crediting the agreed-upon payoff to the contracted player. In the case of a financial payoff, the money is taken from the contract's payoff account and credited to the contracted player's bank account. In the case of a payoff in goods, these are moved from the payoff account to the contracted player's inventory or bank vault. If there is insufficient room in the contracted player's inventory or bank vault (depending on which is appropriate for the type of contract activated), or insufficient goods or money available to the contracting player, then the contract's status is set to "failed," and it will proceed through the results of a broken contract (as described in the next paragraph).

When a contract's status is found to be "failed," the identity of the player who caused the failure is checked. Any goods or money in the payoff and provision accounts are returned to their original owners (if possible), then any penalty agreed to in the contract is applied. This could take the form of money or goods placed in the penalty account being credited to the contracting player, or if a bounty was agreed to the contract would revert to an open Assassination contract and placed back into the list of active Bounty Hunter contracts.

CONCLUSION

I don't think the system described here is perfect. I wish there didn't need to be specific contract types; a more general contract system would capture more kinds of economic activity. I'm not 100% sure that a game can detect all possible contract conditions -- I think it can be done, but I don't know for sure. And I do realize that implementing this system would require a lot of time and effort. The detection of contract conditions alone would require that every class of object that can be the target of a contract be made "contract-aware," for example.

But having admitted these things, I'm still optimistic that the new game feature I've described is both doable and worth doing. I think the technology will support it, and I believe that any MMOG would be made a lot more fun by players having more ways to interact economically with each other. This is especially true for Star Wars Galaxies if (as I believe) the Open Player Contract really is the foundational technology for "player missions."

So, based on that optimism, I'm posting this document for you to consider. If you've made it this far, thanks again for your patience! And I look forward to any constructive comments you're willing to offer.

TERMINOLOGY DEFINITIONS

Activation: the event of a contract's required conditions being met (may happen more than once in a recurring contract)
Bilateral: a contract form in which both players must agree to cancel a contract to avoid either being assessed with a penalty
Bounty Flag: an in-game variable associated with a player that is set to "true" if that player may be the target of a "bounty hunter" contract
Contract: an agreement between two players to trade goods, money, or services
Contract Document: an in-game artifact that lists the terms of a contract, a copy of which is held as an inventory item by both parties to the contract
Contracted Player: the player who initiates a contract offer
Contracting Player: the player who receives a contract offer
Credits: a generic term for any form of usable money in an online game
Default: the event of a specific player who is party to a contract causing the conditions of that contract to be impossible to meet
Draft Player Contract: a Player Contract that has been pre-generated by a player but has not been agreed to by another player
Griefer: someone who deliberately takes actions in an online game to spoil the enjoyment of the game for other players
MMOG: Massively Multiplayer Online Game
MMORPG: Massively Multiplayer Online Role-Playing Game
Negotiation: the interactive process by which two players take turns establishing the terms of a potential contract
NPC: Non-Player Character, or an apparently sentient creature controlled by the game computer
Open Player Contract: a Player Contract created by a contracting player that is offered publicly to any one player for up-or-down acceptance
Payoff Account: a container for goods or money to be transferred to the contracted player upon activation of a contract
PC: Player Character, or the in-game avatar controlled by a real person
Penalty Account: a container for money to be transferred to the player who does not default on a contract, or to a bounty hunter on successfully terminating a player who has defaulted on a contract
Personal Player Contract: a Player Contract created by a contracting player that is offered privately to one nearby player for negotiation
Provision Account: a container for goods or money to be transferred to the contracting player upon activation of a contract
PvE: Player versus Environment, or competitive gameplay directed against computer-controlled NPCs, creatures and objects
PvP: Player versus Player, or competitive gameplay directed against other players -- this is considered voluntary competitive gameplay, unlike griefing (q.v.)
Player Contract: a game-enforced agreement between two players to trade goods, money, or services one or more times immediately or in the future
Player Contract Window: a user interface for making a game-enforced agreement between two players to trade goods, money, or services one or more times immediately or in the future
Secure Trade: a game-enforced agreement between two players to trade goods and/or money once immediately
Secure Trade Window: a user interface for making a game-enforced agreement between two players to trade goods and/or money once immediately
TEF: Temporary Enemy Flag, an in-game variable associated with a player that is temporarily set to "true" to indicate that a player is exposed to PvP play
Unilateral: a contract form in which either player may cancel the contract without penalty