Business And Economy Archive

So now that we have this nice shiny new Business and Economy forum, I can't resist the opportunity to dust off the one thing I most want to see implemented in SWG: Player Contracts.

I originally described this idea inPlayer Contracts: A Design Document, but as that proved to be a little too much reading for most folks, I created a reduced version called Player Contracts: The Short Version. This message is a slightly modified take on that "short" discussion designed toreconsider the proposal in the light of a year of SWG gameplay.I encourage anyone interested in dramatically improving the SWG economy to follow the links above, then come back here and join the updateddiscussion.

---

The Secure Trade system that allows players to swap goods for money is nice, but it's limited.The system of vendors is also useful, but it doesn't allow players to set upbusiness deals with each other.I'd like to see a more powerful version of Secure Tradesthat allows playersto create contracts with eachothertoestablish different kinds of business relationships.

Not only would this be fun in and ofitself, it would open the door to something that SWG players have wantedsince SWG launched:player missions.

Here's how Ithink we can get there.

0. OVERVIEW

A Player Contract is an agreement between two players whose terms are enforced by the game to trade items of value.

Let's assume in what follows that we have a Player A and a Player B.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.

In other words, Player A creates a contract, and Player B accepts the contract.

A Player Contract system will allow Player A to write a contract document that specifies a number of options:

• the contract type
  
• what things are to be exchanged
  
• when exchanges can occur
  
• how the contract may be successfully terminated
  
• optional penalties for breaking a contract

The game system itself has to be able to do two things:

• recognize when the terms of a contract are met or broken
  
• automatically apply contract terms based on contract status

The important thing to recognize about this is that we won't need player lawyers or CSRs tosettle contract disputes because the game codeitself, acting as a completely impartial judge, will handle all contract resolutions automatically. We know this is possible because the game code already detects when NPC missions have been satisfied -- we just have to extend this ability to players.

What follows are the details that describe how to achieve these goals.

1. CONTRACT TYPES

A good contract system goes well beyond merely trading goods. It enables a service economy to flourish because it allows players to perform useful tasks for each other. Not only does this help spread money around, it's just fun.

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)
  
• Recon (go to a particular location)
  
• Obtain (take possession of a specified item)
  
• Entertain (dance or play music for a specified player character)
  
• Heal (heal wounds or cure diseases of a specified living target)
  
• Buff (temporarily improve the stats of a specified target)
  
• Craft (create a particular kind of object, possibly with certain stats)
  
• Slice (slice an object)
  
• Destroy (eliminate a specific lair or mob, or destroy a unique item)
  
• Guard (defend a specified player character)
  
• Bounty (kill a specified player character [who must agree to be a target])
  
• Marriage (marry another player character [note that this allows divorce, too!])

These are just a few contract types thatoccurred to me-- I'm sure there are more.

2. CONTRACT PERIODS

Contracts become truly useful when they're not restricted to being one-shot, immediate deals. Players should be able to specify the periods in which a contract is to be active according to lifespan and frequency. Lifespan options are:

• immediate (trade happens as soon as both parties agree)
  
• limited (trade happens at a specific future time)
  
• indefinite (trade may happen at an unknown future time)

and frequency options are:

• one-time (trade happens once, then the contract ends)
  
• recurring (trades can happen repeatedly until the contract ends)

3. PLAYER-SPECIFIED CONTRACT TERMINATION

Contracts should have two mutually exclusive termination options:

• unilateral (either player can cancel the contract without penalty)
  
• bilateral (both players must agree to cancel to avoid imposing a penalty)

Players won't use a contract system if the other player can just cancel deals, so the bilateral option has to exist to allow for penalties (see next section) against simply breaking an agreed-on contract. But we don't want to force players who trust each other to have to make every contract bilateral (and indefinite-duration contracts should not be bilateral), so there also needs to be an option to allow a contract to be unilateral.

4. VARIETY OF PENALTIES

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

• monetary (a cash payment to the other player)
  
• bounty (a "deathmark" collectable by the first BH who DBs the target)

For a monetary penalty, both players agree on an amount of money to be paid to whoever doesn't break the contract and each puts up half that amount when they accept the contract. If Player A breaks the contract, all the penalty money is immediately transferred into Player B's bank account, and vice versa.

A bounty works the same way, except that the penalty money is used to pay a bounty hunter to go after whoever broke the contract.

5. CONTRACT CREATION

The key to understanding how Player Contracts work is recognizing that there are three "accounts" in a contract. Each account is a container that can hold money or goods.

• Payoff Account (what Player B gets when the contract is activated)
  
• Provision Account (what Player A gets when the contract is activated)
  
• Penalty Account (what one player gets if the other player breaks the contract)

The first thing Player A does when he creates a contract is to choose the contract type from the available options. Depending on the contract type, this may set some other fields, and will at a minimum determine the specific fields Player A needs to fill in for the rest of the contract.

Player A's next task is to enter the desired values into the three contract accounts. He is required to put the actual payoff into the Payoff Account -- if goods, they're taken from his bank vault (or personal inventory in some cases); if money, it's taken from his bank account. Either way the actual items are taken from him and placed into the contract's Payoff Account container. This insures that the contract is for real. (It also specifies what will be taken from his bank account every additional time the contract is activated if it's not just a one-time deal.)

Player A then specifies in the Provision Account what he wants to receive. It could be a certain type and number of goods; it could be money (assuming he's not offering money as a payoff -- simply swapping money for money would be pointless); or it could be a particular kind of service. If it's a service, then Player A will just fill in the details (if any), since the specific type of service will be set when Player A chooses the contract type.

Next, Player A will specify whether the contract is to be unilateral or multilateral -- in other words, whether it will be OK for either player to break the contract, or whether both players have to agree to terminate the contract in order to avoid getting stuck with a penalty. Allowing this choice enables players to either have a penalty (if they want insurance that the other player will honor the contract) or not (if they fully trust the other player, say, if they're both members of the same PA).

Finally, the penalty type is set -- either as a cash payout, or as a bounty. In either case Player A moves half of the specified amount from his bank account into the Penalty Account.

6. CONTRACT NEGOTIATION

At this point the initial contract (which I call a "draft contract") has been created. Now it's time to negotiate the details with Player B.

After Player A creates a contract he has two choices. The first is to put the contract up on a Contract Terminal (creating an "Open Contract"). Once it's on a terminal the terms can't be altered by anyone; if a wandering Player B reads the terms and likes them, he can accept the contract and it goes into force immediately, or else he can simply choose not to take that contract.

Player A's other option is to offer a contract directly to a player character I call this a "Personal Contract." It's just like the Open Contract except that it's directly offered to one person (another player character), and the terms can be negotiated in real time by both players.

Player A offers the contract to Player B just like a trade request. Player B looks at the terms and changes whatever he wants, then Player A can change the terms, then Player B can change them again, and so on. This negotiation process can continue indefinitely; it ends when one of two things happens:

• either player cancels the negotiation (ending the contract offer)
  
• both players accept the contract as negotiated

Like the Secure Trade, once either player clicks on the "Accept" button no further negotiation is permitted; at that point all the other player can do is cancel or accept.

7. CONTRACT RESOLUTION

Once both players have accepted a contract, it goes into effect, and both players get a contract document in their datapad.

If there's an immediate exchange specified, it happens immediately, and if the contract was a one-time deal, it ends. (Notice that this implies that a Secure Trade is just a particular type of Player Contract.)

If the deal is for later trade (either of goods or for a later provision of some service), then the game itself has to watch for this event to happen. As soon as Player B fulfills the contract's provisioning terms (either supplying money or goods into the Provision Account, or performing the required service), the contract is "activated." This means that the items in the Provision account are transferred to Player A, and the items in the Payoff Account (if any) are transferred to Player B. In a recurring deal, after the first trade any goods are taken from the providing player's bank vault -- to keep the deal going, you just keep putting the required number of those goods into your bank vault. (Note: It might be better to require that goods to be transferred are actually moved into the Payoff or Provision Account box in the contract document, rather than being taken from a player's bank vault, but either approach should work.)

If this was a one-time deal, then the contract ends. If it's a recurring deal, then it can be activated again when Player B fulfills his side of the contract terms.

8. CONTRACT TERMINATION

A contract can end in a number of ways, but all terminations are of two types: successful or unsuccessful. Successfully terminated contracts just end; unsuccessfully terminated contracts trigger the agreed-upon penalty (if any).

A contract terminates successfully when all the terms of the contract are met, including the terms for how the contract is to end. Assuming all goods and money transferred successfully, then if the contract was a one-time deal or if the timer expired on a limited or recurring deal, the contract ends successfully. Also, if the contract is a unilateral contract, then as soon as either player cancels the contract it ends successfully.

A contract terminates unsuccessfully when anything happens in the game that prevents it from being terminated successfully. The most common ways in which a contract terminates unsuccessfully are:

1. The service can no longer be provided. For example, if someone other than Player B destroys the object to be destroyed in a Destroy contract, then that contract is broken because there's no longer any way for Player B to successfully complete it.

2. The goods can't be transferred either from or to a player. If you don't have enough of the agreed-on goods in the Provision or Payoff accounts when a transfer is scheduled, or you don't have the agreed number of credits in the Payoff account or your bank account, then you've broken the contract. Similarly, if you don't have enough room in your bank vault to receive goods to be transferred to you, then you've broken the contract.

3. Either player cancels a bilateral contract. By definition a bilateral contract requires both players to agree to cancel it; if either player cancels a bilateral contract, then he's broken the terms of the deal. (Note that canceling a contract can happen either by clicking on the "Cancel" button on the contract document or by manually destroying the contract document in your datapad.)

Regardless of how a contract ends, once it ends the contract document is deleted from the datapads of both players. It's also important to note that any goods or money in the Payoff and Provision accounts return to their owners when a contract is terminated (so there's no way to cheat the system). Also, if a contract is terminated successfully, the money that each player put into the Penalty Account is returned (since the contract wasn't broken, no penalty is enforced).

9. CONCLUSION

This message doesn't cover all possible situations, and doesn't try to address all the potential objections -- it's just a synopsis of the idea.

If you thought this idea has some merit but you aren't sure about some of the details, then I encourage you to take a look at the fulldesign document thread. If you'rereally a masochist, or if you're one of those folks who enjoys looking at things (including SWG) from a Systems point of view, then you might enjoy reading the more general thread in which I firstintroduced theidea of Player Contracts: Advanced Economic Systems in Online Games.

As always, constructive discussion is welcome.

--Flatfingers

Think this is a very good idea, helps encourage interaction by protecting people from bad apples.

Would like to add the ability to lease unused lots for a period of time. Always thought that would be interesting market and a good way for new players to make money.

Only put enough thought into it to realize some way needs to be worked out on how to deal with items and structure on a lot that the leasee might refuse to give up at the end of a lease. One week grace period at double the rate, items and structures get transferred to lot owner if not retrieved?

Also would need to be able to lease a lot from player A, put a structure on it and transfer that lot to a lease using a lot from player B. Otherwise it would be too easy lease lots and grief people by making them move once they get all settled in.

Leasing lots... interesting! I hadn't thought of that one, but it's a common enough business deal to probably warrant implementing as a contract type.

As you say, though, it could be a little tricky. The "problem" is figuring out what to do with stuff still on the lot (or in things on the lot) when the contract's timer expires. It's tempting to say "oh, everything Player B owns that's on Player A's lot just gets put into Player B's current bank vault." But what if Player B's bank vault is full? If she put a harvester on Player A's lot, and that harvester had thousands of units of some resource in its hopper, but there's only one free slot left in Player B's bank vault, which item gets put there -- the harvester or the resources?

Personally, I think we could overcome such problems. I imagine a system message generated on all timed contracts that gets sent one day before the contract expires to the effect of: "Your ____ contract with _____ will expire in one day. Please make sure that you have room in your bank vault for all items that you want returned to you. Any items that will not fit into your bank vault will be deleted, and no refunds will be provided." Then, when the contract expires, if we really wanted to be nice we might check and, if there's not enough room for everything, send another message: "Contract ____ with _____ has expired, but you do not have enough room in your inventory for all items to be returned to you. If you have not made room within one hour, the remaining items will be deleted, and no refund will be possible."

This approachwould mean that all Player Bs will have to do a little work to make sure they have enough room for the things they wanted returned to them when a contract expires. But someone who's playing SWG enough to sign up for business deals like this is probably going to be around to get these kinds of messages in time to do something about them.

What do you think? Is this reasonable and sufficient?

And what about the larger concept of Player Contracts in general? Yes, it would be a significant development project. I think the benefits of massivelyexpanded player-to-player opportunities make the cost of this development worthwhile (and then some) -- does anyone disagree?

--Flatfingers