Some interesting objections came up to the Player Contracts concept that deserve a response.
BoberFett wrote:One of the features I mentioned in my original Player Contracts design document was that each contract type would have terms that were specific to it. It's these terms that will allow players to specify what will and what won't satisfy them, so the terms available for any contract type have to be ones that let players verify that they're really getting what they want.
I like the idea, I've given the contract system some thought myself. The biggest hurdle to overcome is not the punishment system (in my eyes anyway) but how the system decides whether or not the terms have been met. I'll just use your ideas.
If I am contracted to make somebody a weapon, I can give them a weapon back with any stats I want. They hand me Krayt tissue and I give them back a 150 max damage scout, as far as the sytem is concerned I fulfilled my end of the bargain. The buyer on the other hand will want to report me to a CSR for arbitration.
- Exchange (swap goods for goods or goods for money)
In this Exchange example, the terms would have to allow the potential buyer to specify the values of the features of the item being requested. In the case of a weapon, I'd want to be able to specific minimum and maximum damage values, wound values, range values, encumbrance values -- basically any numeric feature of the item being requested.
When contracts allow sufficiently specific terms (as my proposal recommends), contract resolution can work because players will have the power to get what they really want.
Note that this is even more likely to work well for one-time, immediate Exchange contracts which, as I noted, are basically our current Secure Trade. In this kind of contract, you could actually /examine the object to see if it's what you really want. We can't do any better than this currently, so it's hard to see how doing it as a contract is any worse!
BoberFett wrote:The thing to realize here is that the functionality to accomplish Transport missions already exists: it's the code that "knows" when you've come within a certain distance of a specific waypoint.
How does the system decide when the trip is complete? If somebody wants me to fly them from Mos Eisley to Endor, what happens if I drop off a second passenger at Moenia on the way? Does it wait for me to continue on to Endor? Does it consider me in breach even if I do eventually get them to Endor?
- Transport (move items [or player characters] to a specified location)
The system would know the trip was complete when you landed at the designated spaceport and your passenger exited your ship. Since Transport contracts could be specified as simply as "take me to X spaceport," or could include a "by such-and-such time" clause, as long as you get your passengers where they want to go -- as specified in the contract that each ones signs with you -- then there's no problem.
If you accept a contract to take someone somewhere by a specific time, and you don't make it in time, that's not a flaw in the system -- that's you having made a bad business decision.
BoberFett wrote:1. Remember that it's not necessary to have a penalty for breach of contract. In that case, it wouldn't matter if either party died before the requested healing was completed.
What if while in the middle of healing, the party who is being healed is attacked and killed. Is the other party who agreed to do the healing in breach?
- Heal (heal wounds or cure diseases of a specified living target)
2. Since a one-shot heal is pretty trivial, most healing contracts would probably be on a recurring basis -- either for a set number of heals, or for a set number of pool points healed, or for healing any number of points for a certain amount of time. (Curing diseases would work the same way.) In this case, either character dying wouldn't have anything to do with breaching the contract. Cancelling one's character would, however; in this case the character who was deleted would be the one considered in breach.
3. If despite all this either party died in the middle of a one-shot heal with penalty, then we have to look at why the contract couldn't be fulfilled. If the healer tries to fulfill his end but can't (because the recipient is dead), then that's not his fault -- the dead character should get penalized (in addition to dying, which seems harsh, but then he didn't have to ask for a penalty for breaking the contract). If on the other hand the healer has the capability to complete the agreed healing but doesn't, then in that case it would be the healer who has broken the contract and should be penalized.
The point in all this is to further emphasize how important it is for the contract system to be detailed enough that players can specify the terms they really want in any contract type. If that's done, and if the code that monitors game events works properly (a big "if," I freely admit), then contracts could work.
BoberFett wrote:1. Objects have semi-unique serial numbers. (Exact duplicates can have the same serial number.) This provides a secure way of identifying specific objects that the game system can use to ensure the secure transfer of items.
How do you determine which object is the one you want? By name? By serial number? Couldn't somebody pull a bait and switch?
- Obtain (take possession of a specified item)
2. Objects have properties. If you're offered an item, you have the ability to examine it, and the contract system has the ability to test numeric properties against contract terms. If the item offered is not equal to or better than what you specified you wanted, you don't have to accept it... and the contract system doesn't have to, either.
BoberFett wrote:I don't pretend that any contract system would be perfect. Even if every property of an object was a specifiable term of a contract, there'd still be features that players would want added.
These are just off the top of my head. The systems required to handle the exceptions possible in all of these scenarios would end up dwarfing the combat system. It's taken them how long to get around to a combat balance? I wouldn't expect a contract system like you're discussing for a loooong time.
But I do think that a contract system that was designed so that most (if not all) object properties were available as player-specifiable contract terms would handle most of the cases in which exceptions could occur.
Trivial to design and code? No. This would be a significant effort -- not as much as for the Space Expansion, but several months of labor by two or three developers at least. And then it would have to be exhaustively playtested to squeeze out the bugs. But I also think the result would be worth this investment. Just imagine the possibilities for player interaction if we could offer each other missions....
BoberFett wrote:Understood, and no offense taken. I happen to come to a different conclusion, but your points about the difficulty of getting something like this right are well-founded.
I agree a system like this would be loads of fun and add a lot of immersion and community building to the game. I just don't see it as feasible. There's a reason contract law is a massive industry consisting of an army of attorneys, and not is not run by a computer program. The human element to contracts is far too unpredictable.
I would only suggest that a game-run contract system actually has an important advantage over a RL contract system: freedom of action in the game world is much more constrained.
In RL you can write a contract to do anything (legal). Trying to write rules to reflect this apparently infinite breadth of human action is both the source of economic productivity and legal wrangling.
In a computer game, however, you have to spell out specific contract types and terms. This means you don't get all the economic advantages in a game because you're excluding economic activity that's not allowed by your contract types. But it also means that you don't get all the questions of interpretation of RL contracts. And when interpretation isn't a factor, you don't need judges or lawyers.
By constraining contracts to numerically-verifiable terms, you create a system that a perfectly impartial adjudicator (the computer) can successfully resolve.
That's why I remain optimistic about a computer game with contracts. You're absolutely right that it won't be easy to implement well, but "hard" doesn't necessarily imply "practically impossible." Given a good design, and a careful implementation of a contract resolution engine, I think this could work.
No comments:
Post a Comment