Contracts

A contract is a standard object that translates and facilitates understanding and work between two different but dependent organisations. The publisher-developer collaboration starts with a written contract that is intended to increase mutual understanding and build trust between the two. This contract is composed at the outset of the collaboration and incorporates game specifications and features within the game design documents, as well as an elaborate project plan. Publishers demand a detailed and structured contract because they can hold the developer accountable for the timely and quality delivery of the product;

hence their usefulness at the start of the project. A publisher executive highlights that

"contracts are essential – we make an assessment and devise a contract to secure a quality delivery" (Simon – publisher executive). Matt – an experienced publisher producer – talks about the role the contract plays in creating perceptions of trust and stability for the publishers:

We try to come to this belief that the developer can really deliver a product and using the contract we get the developer to commit to the contractual milestonesand game specifications (Matt – publisher producer).

The developer also explains that the contract makes them trust each other. He says "we stick to the spirit of the contract ˙ we know what that is and we don’t dispute it. There are absolute lines in the contract and they are given. We trust them [the publisher], we work with them and we respect them and their contract" (Francis – developer director).

118

However, the interview data reveal that this traditional and detailed contract at the later stages of project seems to be not only impractical, but is actually a hindrance to the cross-boundary videogame development. Adrian, a highly experienced developer/studio head complains that:

The contracts are often not fit for purpose really. You will never end up having a game that you designed in the contract. This will never happen; it's impossible with software. But we all sign the same contracts every year, exactly the same framework. I challenge you to find a single development contract that actually represents the game (Adrian – studio head).

The interview data also show that contracts are generally not referred to or used during the development process, unless serious problems arise. Ken explains why they tend not to discuss contracts with publishers:

We never go to the contract, because first of all, that's not what we want to be doing. We want to make games not be sitting in court. Second, our companies are much smaller than publishers, there's no way we can win. So we try not to get to that position (Ken – developer executive producer).

Developers are not the only ones who talk about the ineffectiveness of contracts in this relationship. Here Jing – a publisher producer who currently owns his development studio – states that contracts are only taken seriously when the relationship is formed, but later they are avoided. He states:

The contracts are there to be and they might only be used when things go wrong between partners. It's always written in the contract that it's going to work along those timelines, but it never does. It's blank trust and it's one that's biased in the beginning and it's not later. It's a grey area that is difficult to navigate and people often don’t go there (Jing – publisher producer).

Publisher executives also admit that a contract is not an efficient device to manage the publisher-developer relationship. Here, a publisher senior executive delineates:

119

You can put stuff in a contract, but you can't manage people with contracts. You can't manage vision; you can't manage your game with a contract. Contracts, largely, set out terms and conditions, but using contracts and waving bits of paper to get what you want is not normal course of business (Laurence – publisher executive).

Some developers in the study perceive the detailed contract as a medium for the publisher to exert control and monitor the developer. Ben – an experienced developer who has worked on very successful game titles – explains that the publisher pushes for a detailed contract in order to make sure the developer delivers the game with the quality and timeline they want. However, he believes the publisher’s expectation for detailed planning in the contract is "unrealistic" and "overly ambitious":

On the publisher side I think there has always been a suspicion about the relationship and they want the contract to be something which they could use to drive the whole thing through, so they want to see ambitious scheduling (Ben – developer executive).

The developer views the contract as "unrealistic and overly ambitious" because they believe that there is incompatibility between the game development process and the nature of the contract. Due to the iterative and creative nature of game development, the developer emphasises that they definitely have to change the features/specifications that were agreed upon in the contract later on in the production. As a result, contracts are not suitable for a creative development process, and they only lead to disagreement and dissension between parties. A developer executive complains:

Publishers’ lawyers want a contract with clear milestone definitions, they want everything defined, designed and mapped out from the first day all the way up to the end. This is not a great way to make a creative product; you can’t granulate or procreate a creative product (Todd – developer executive).

120

Here, a developer creative director also reinforces how the contract will create more clashes between the parties in the publisher-developer relationship:

There's a definite conflict between the need to define a game as delivering a certain amount of content and features in a contract, and the process of actually developing the game with those specifications. The problem is that when you start making a game, you might have planned a certain set of features and content for it, but as you develop that game, you may need to cut some of them, either because they don't quite work in gameplay terms, or simply because sometimes, in order to stay on time and on budget you need to cut things. Obviously, from a publisher's point of view, this is not what they originally agreed to pay for – even if the end result might be a better game, hence all sorts of problems arise (Dylan – developer creative director).

The contract seems to provide a resource for the publisher in their disputes with the developer. If the developer diverts from the contractual milestones, the publisher can legally withdraw from paying and they can also cancel the project. A publisher executive confirms that they "devise a contract to secure a quality delivery and penalise late delivery”

(Simon – publisher executive). That is the reason why the developer sometimes avoids committing to a detailed contract so that they have more flexibility to implement the changes that might be needed in the game. The point here is that given the complexity of dependencies between the partners, detailed contracts can be detrimental. The head of a development studio emphasises that the developer prefers to share less information with the publisher about the development, especially at the beginning of the relationship in order to stop more misunderstandings in the future. He explains:

There are some grey areas in the contract that can’t be measured properly, these are some milestone criteria that are mainly subjective themes, and they are not black and white. The contract says this feature should be completed 70% but it’s not measurable. Our contract with the publisher has lots of details such as staff plan, which determines how many people should be in each group. We never exactly liked those details because these could work against us. This is very complicated due to crossover within the team. There is always some information

121

that you don’t want to share, as a developer, I’d better be careful because that information might be used against me (Nigel – developer studio head).

The publishers in the study also confirm that contracts create clashes between the parties.

A publisher executive says “the contract spells trouble, I have to wave contracts when I have a massive problem” (Laurence – publisher executive). In other words, he expresses his disapproval of exploiting the contract as a threat to resolve the disagreements in the relationship, while confirming that the developer can be very difficult in sharing some information and committing to the contract. Another publisher executive states:

They [the developer] sometimes wouldn’t give you design documents, wouldn’t give you schedules or dates. They just wouldn’t commit to the contract or contractual milestones. Getting details from them is like you have to get blood out of stone (Allan – publisher executive).

The interview data reveal that design documents, project planning documents and contracts are widely used in the publisher-developer relationship because they create perceptions of trust and stability between the partners, thus enabling them to form a relationship regardless of their differences and dependencies. Although design documents, project planning documents and contracts are not static in nature, they are static in use because they are not regularly updated and upgraded due to the costs and resources that are required to do this. Therefore, the study suggest that these static boundary objects are not a useful medium/object at later stages of videogame development. The participants emphasised that these can also create more clashes and disagreements between the parties.

The next section presents the dynamic objects that were found to be useful for the iterative and unpredictable process of the videogame development.