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.