Player Contracts +

At this point I'd like to try to address the most obvious objections to implementing the Secure Contracts system described.

This isn't a truly general contract system.

The big question, of course, is whether the list of contract types implemented is broad enough to cover not only the kinds of cooperative economic behavior players currently engage in, but also the kinds of economic activities they might want to engage in but haven't even thought of yet. In other words, this system is more general than a simple Exchange Contract system... but is it general enough?

Honestly, I'm not sure that it is. The beauty of the real-world contract system is that you can write a contract to cover almost any kind of economic transaction you can imagine; the system itself doesn't impose any limits on you. That's why the contract is such a powerful economic innovation -- it makes possible enormous opportunities for economic creativity. (There are some limits on this creativity; for example, a contract to do something illegal is not legally binding. But these aren't limits imposed by the contract system itself.)

A hard-coded system of contract types, by contrast, circumscribes what you can do according to what the programmers were able to encode. And that places extreme limits on how far economic activity can be expanded -- the full creative potential of human beings can't be harnessed because there are too many novel behaviors that a hard-coded contract system just doesn't cover.

But as I said, I just can't think of a contract system that is both general AND guaranteed. If it's not guaranteed by the system, then you need a legal system with courts and lawyers and judges (oh, my!). If it's not general, then you fail to protect significant amounts of economic activity.

So I designed this system as a middle ground. It can't be as effective as a true general contract system; it has to be limited so the game can control contract resolution. That means there'll be some kinds of economic activity not supported by contracts, which means a failure to capture all the economic activity possible. This in turn raises the question of whether the contract system described here is sufficient to create the "order of magnitude" increases in economic activity that will constitute a true new stage of productivity in MMOGs.

It’s a fair question, to which the only answer I can give is "maybe not... but getting close is still worth trying."

If unilateral contracts allow one-sided termination, what's to prevent griefing?

The most obvious result of allowing unilateral termination without penalty as an option when setting terms is that it permits "no-fault" contracts. The (apparent) downside of allowing no-fault contracts is that by reducing the pain of penalties for defaulting we risk weakening the trust in contractual agreements that this whole system is intended to promote. To this objection I would respond in two ways.

First, it's not clear that making penalties optional really does "weaken" contracts. Yes, if penalties are optional then players will sometimes make that choice, which means that there will be deals broken when one player would rather maintain them. But for every player who complains, there'll be another player who will defend this system because he benefits from it. Additionally, low-cost, no-hassle contracts are a proper tool between two individuals who already trust each other. Why should PA members, for example, be treated (by a system that insists on a penalty) as though they were strangers? Allowing "no-fault" contracts as an option actually promotes trust and cooperation by offering streamlined contracts as a choice once trust has been established.

Second, unless you force a minimum penalty (which becomes a cost of making contracts, limiting their use) even the strong penalty could be bypassed by simply specifying a monetary-only penalty of 2 credits... so why insist on making players go through the motions? Being forced to do unnecessary paperwork adds no trust to the system.

Overall, I'd say the option to provide a penalty should be there, but it shouldn't be forced on players. No-fault contracts should be available.

Won't "Assassination" contracts allow griefing?

The Assassinate contract, in particular, would have to have some very secure conditions placed on it -- one condition might be that no player character can be the target of any Assassination contracts for more than one week out of any month. I think there'd probably also have to be factional limits -- only overt characters could be targets, for example. The potential for griefage without these limits is pretty obvious.

Can the game really enforce all the terms of player contracts reliably?

Enforcement of contracts is a critical element to contracts working and being used -- if the terms and penalties of contracts can't be reliably enforced, the system won't be trusted and therefore won't be used.

So how do we achieve this? A secondary system of law enforcement could possibly be developed that can not only be used to resolve contractual disputes but might provide other gameplay opportunities as well. (Although I can already hear the cries of "We don't want to play Star Wars: The People's Court!"....)

But for now, I'm thinking it's also possible to achieve reliable enforcement through the game system itself.

Consider the Guard contract. Let's say you and I sign a contract with the following terms:

I agree to prevent you from being killed.
You agree to pay me 10,000 credits, which you put into a payment account.
This is a one-time contract with a period of five game days.
Each of us puts up 4000 credits as a bond into a penalty account.
We agree that this is a bilateral contract.

Following the rules of general contracts and specific terms of this contract, if you get killed for any reason within the specified time period, all the money in the penalty account (8000 credits) is immediately transferred to your bank account by the game itself. If I delete the contract, again, all the money in the penalty account is transferred to your bank account. If you delete the contract, I get all the penalty money. If you make it through the specified time period without getting killed, then at the moment the time period is up the game transfers all the money specified in the payment account from your bank account to mine, and the game transfers back to each of us the original amount of penalty money we put up.

Logging out forever won't help you. (If you never come back, you can't play.) For that matter, if you default, I get the penalty money whether you're online or not, so running to another planet won't help you, either. If you make the deal, you're stuck with the consequences because the game enforces the results.

So I can't see any technical reason why this couldn't work. And I think the other types of contracts would work similarly.

But what about possible social reasons why this wouldn't work? Any obvious opportunities for grief play?

I suppose it's technically possible for someone to agree to a contract and then break the contract... but why? What would a griefer get out of this, since the only thing that could happen -- beyond the terms to which both parties agreed -- would be to make the other player richer by giving him the penalty money? No new money is being created by contracts (they only transfer money), so there's no opportunity for two players to collude to create new wealth that they can split between them.

As for "rich griefers," who theoretically might break contracts simply to be annoying, just how many of these folks are there? Aren't the terms "rich" and "griefer" usually (not always, but usually) mutually exclusive? Most griefers are too childish to have enough patience to be crafters or to run enough missions to make money; they just want to duel you... and you don't get rich that way. (It's not like medieval jousts, where the winner got to keep the loser's horse and weapons... although allowing player-looting as a totally optional feature might make PvP a bit more interesting, wouldn't you say? Maybe I should add "Duel" as a possible contract type to my list....)

One possibility in this particular case might be if I guard you for some amount of time right up to the limit... and just before the time expires, you break the contract. I get the penalty money, but you got virtually all of my time that you were (apparently) willing to pay even more money for. So, Mr. Smartypants Flatfingers, what about that, huh?

Well, I'd respond by saying that there are two ways my contract system allows players to prevent this kind of griefage. First, players -- because this contract system lets them specify penalty amounts -- can always make the total penalty value equal to (or greater than, if they like) the payment amount. That way breaking a contract will always be more painful than honoring it. Second, players can minimize their exposure on timed agreements by using shorter periods. In this case, instead of writing the deal as a one-time payment after three days, it could have been written as a recurring contract with a one-day period -- that is, every 24 hours in which the contract remains in force, X credits are transferred from the guarded player's account to the guarding player's account. (If the guarded player doesn't have the cash, the deal ends and the penalty money goes to the guarding player.) The advantage of this option is to minimize the exposure of the player who's investing his time in the deal by minimizing the period required for successfully fulfilling the deal's terms.

Finally, I note that a game system that "enforces" contracts (by insuring payments and applying penalties) is actually better than what we have in the real world! In the real world you can always litigate; no such option exists in existing MMORPGs. (Though I suppose one of the "Ace Attorney" games might get turned into an MMORPG some day, we're not there yet.) The game system is judge and jury -- if you can't do the time, you'd better not do the crime because no CSR will compensate you for a contract you voluntarily signed. If anything, this should actually induce more trust in a player contract system than in real world contracts! (And people certainly do trust computers to be perfectly fair -- you may have heard the story of an infamous program called ELIZA....)

So I think the system as I've currently described it is sufficiently mighty to address the most obvious forms of griefology, but if I'm still missing something I'm definitely listening.

At any rate, let me conclude by saying that I agree that "law enforcement" of contracts is critical; that's why I've described it as a non-negotiable feature of a contract system and discussed it at length. I think it's doable through a system of game-monitored conditions and outcomes, which if properly implemented (I know; big "if") would inspire sufficient trust to allow a vast amount of new economic activity.

Player Contracts +

Having laid out the details of a player contracts system, let's now consider some of the practical issues of implementing such a thing in a MMORPG.

First and most important is to respond to the "degree of difficulty" question. This actually comes in two forms: one related to scope, and one based on technical considerations.

In terms of scope, I recognize that what I've proposed isn't an overnight coding job. I think I've managed to keep the design relatively simple (given real-world considerations such as preventing griefing and exploitation, not to mention a natural desire to add lots of "wouldn't it be cool" bells and whistles), but there's no question that a player contract system that works well will need time to get it right. I hope I didn't come across as naive about that. I understand that the majority of the time necessary to implement a contract system as I've proposed it would likely be spent not so much in coding as in testing. Making sure it works and is fun is important, but so is making sure the system isn't buggy or exploitable or griefable.

Second is the question of technical difficulty, particularly concerning what I called the single most important technical issue: reliable detection by the game itself of contract fulfillment conditions. Here I think I can provide some cause for optimism by pointing out that a number of my design features were taken directly from how NPC missions work in current MMORPGs. To a significant extent, a player contract system would piggyback on the existing functionality of an NPC quest or mission system.

Consider: when you take an NPC mission, the game has to:

• store that your character has taken a mission
• create any waypoints related to the mission
• create a mission details data item in your character's datapad/notebook
• store the mission's initial success condition status
• monitor the player's in-game actions related to the mission
• set the success condition to "true" if a mission-related in-game event occurs
• modify waypoints and reset mission conditions for multistep missions
• credit your chararcter if the mission success condition is set to "true"
• delete the waypoint and mission details data items when the mission is completed
• delete the stored mission if you cancel the mission

There are a few other actions a mission system takes, but those are most of the important actions. The point is, all this is existing functionality in current MMORPGs. I'm inclined to think that my more general contract system has a good chance of being possible technically because it reuses this existing NPC mission technology -- I don't think I've proposed any core system element that isn't already working in existing MMORPGs.

The only significant new considerations I see are:

• new UI (Player Contract Window) to be designed/implemented
• many more types of game-detectable success/failure conditions
• an order of magnitude more contracts (missions) and conditions to monitor

These aren't trivial issues, but at the same time I can't see any technical reason that prevents them from being possible to implement. The only really tricky one is the scaling question -- how well will the game run if it has to keep track of possibly 10-100 times more contract information? Without knowing more about how a particular game is actually implemented (C with some C++ core code? strong C++ objects everywhere? procedural subroutine communication, or strongly object-oriented message passing?) I can't answer this one, but my gut tells me that a "contract engine" designed in an adequately efficient way will address this potential gotcha.

Now, to some specific points that have been raised:

Azton-Cobalt wrote:
I could imagine 2 players agreeing to trade thousands of credits for units of a specified resource; only to have it shift minutes after the contract was agreed upon. The system would have to be smart enough to contact both parties else 1 player could spend hours searching and another waiting for something that just will not happen.

Agreed. There are two things for me to say here: first, each contract type should have a broad array of game-detectable options, as this will be necessary to insure that players can tailor contracts to acceptability. For example, a Destroy contract to destroy a creature lair might need to be able to detect:

• lair destroyed
• lair destroyed by contracted player
• lair destroyed by another player
• lair despawned for unknown reason

When a Destroy contract type is selected from the Player Contract Window, these potential situations could be reflected in the terms of the contract, possibly by radio buttons if well-defined, or by a dynamically-built drop-down menu if dependent on other game conditions. The parties to the contract could then choose which condition they wanted to have treated as the "success" condition, and which conditions constituted "failure" conditions; any conditions not explicitly identified could be treated as what we might call "acceptable" conditions: the contract ends, but no penalty is assessed.

Other types of contracts would need to be similarly studied to identify the right set of conditions to monitor, and to determine whether the game can efficiently monitor them (both individually and in the aggregate).

Azton-Cobalt wrote:
some players might actually enjoy stiffing others on contracts and running from the [bounty hunters], rarely logging on, or even re-rolling characters as a form of griefing. There would have to be some sort of reputation count in place where if a player defaulted on a contract, did not pay his way out, and was not brought to justice, that others would be informed of this before they signed new contracts with the player.

There's been some talk whenever the subject of "deals with other players" comes up of wanting a way to know whether the other potential party to the deal is a bad risk. The usual model for how to do this is the "eBay rating" model, in which buyers are given a rating by sellers and vice-versa. The problem with something like this in a MMOG is that some gamers would abuse the system. Because they don't stick around, they feel free to lie; but those lies would typically be retained by a simple rating system.

So without tweaking, the eBay model wouldn't necessarily be a good idea for keeping track of players who can't be trusted to honor contracts... but who says we have to use the eBay model? Perhaps all that's needed is a simple "number of contracts broken" counter, or possibly a percentage ratio of "contracts broken" to "contracts signed" if we wanted to get fancy. This number would be absolutely objective since it would be maintained exclusively by the game system itself.

The only negative I can imagine is that tagging every user of contracts with this information would cause some players to not use contracts, due to a concern that they would inadvertently break some contracts and be unfairly branded as a "contract-breaker." This is a perception issue and thus hard to counter. One possibility would be to allow "aging" of contract resolution data -- in other words, the contract counter only retains the most recent 1-6 months of contract resolution results, so that if you have a run of bad luck your "broken contract" number or percentage will eventually recover. I'm not too enthusiastic about that option, but it would be possible if enough players found it acceptable.

Another option would be to allow players to explicitly specify which contract conditions should be treated as "no-fault" failure conditions. That is, the Player Contract Window would list every possible failure condition relevant to a particular contract type, then the parties to that contract would be able to negotiate whether each failure condition should be "Required" or "Acceptable."

If any required failure condition becomes true, the contract is terminated and any penalty provisions are applied. If any acceptable failure condition becomes true, the contract is terminated but no penalty is assessed. (And of course if all required success conditions become true, the payoffs of the contract are activated.)

As long as the list of possible conditions relevant to a contract type is sufficiently extensive and detailed to allow players to feel that they can craft contracts to be fair to both parties if something goes wrong, then the value of having a "broken contracts" counter (for identifying the bad risks) should outweigh the perceived cost.

Azton-Cobalt wrote:
A player would a single unit of a wanted resource into the interface, and type in a reward per unit number. The player could then dump a few thousand credits in the machine to activate the contract. Others could come along, read the contract, decide to accept, and would be paid for each unit of the correct resource they dropped onto the interface.

I have to admit that I have some reservations about this one. Specifically, I'm not sure it's wise to allow many-to-one contracts.

Imagine writing a valuable contract ("I'll give you 10 cr/unit for any Class 3 radioactive") and then plunking it down onto a contract terminal. If there are known limits to what resources one player can collect, a contracting player can write a contract he can afford to fill (i.e., he's got enough money to pay for whatever one person can bring). But if you open this up to a theoretically limitless number of players (or a guild-backed player), there's no telling how much money the contracting player might be on the hook for! If he posted such a contract and logged out, he could return to find that he now owned millions of units of class 3 radioactives, but was utterly broke. Not good.

Unless the contract was written so that the contracting player couldn't be considered to have "broken" the contract if he didn't offer any money to someone who brought in some amount of the desired resource, the contracting player could wind up with a bad reputation for having left an unfulfillable contract out there. At a minimum, there'd be a lot of unhappy players when this "Really Open" contract got pulled after just a few minutes (once the contracting player had all the Class 3 radioactive units he wanted).

Better, I think, to limit contracts to two parties. The second party might only be defined once the open contract is accepted, but I think "predictability of response" is a sufficiently powerful justification for holding the number of parties to a contract to two.

Note: One of the possible enhancements to contracts I'm still mulling over is related to another of the economic advancements I identified in my "Economic Stages in MMORPGs" essay; namely, the corporation.

My idea for implementing player corporations was to allow a generalized hierarchical organization. That is, you'd be able to create a structure that links players in superior/inferior relationships, possibly even allow the creator of such structures to name the various levels and groupings. This would allow the creation not only of corporations, but of crafting guilds, entertainer unions, paramilitary units, and so on.

If this is done, then it occured to me that it would be useful to allow the identification of the player at the top of such an organization to create and agree to contracts on behalf of that organization. This would give organizations more effectiveness as it would dramatically increase the "purchasing power" of the head of that organization as its representative. (It also models the real-world treatment of corporations as "corporate" entities nearly on a par with actual human beings before the law in some specific areas, which could eventually have some interesting gameplay potential.)

But, as I say, I'm still thinking about this one.

Azton-Cobalt wrote:
A more complex system might allow the setup of 2 connected contracts to facilitate the delivery, obtain, and transport exchange types you mentioned.

I like this idea a lot.

"Chaining" contracts could have some wildly interesting results. Heck, an entire business specialization has sprung up in the real world to handle "supply chain management." Playing SWG shouldn't be like having a real job (that's what playing The Sims is for :-), but creating systems that allow more economic interactions (both low-level and high-level) is exactly what I'm hoping to accomplish with this "player contracts" proposal.

Even more interesting, how about contracts that don't merely chain to one other contract, but that actually can monitor the results of multiple other contracts as conditions, and kick off multiple other contracts when activated or terminated? If contracts could be bought and sold, a group of such contracts that filter upward into a single master contract could be considered a business in and of themselves -- you could actually sell an entire business by selling the master contract!

(OK, I'm getting a little blue-sky here. But this kind of possibility does exist once you get the basic elements of a contract system working and start considering enhancements.

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