The Prototype

Another dynamic boundary object that seems to work effectively in videogame development is the prototype. The prototype is a playable version of the game that is developed at the pre-production phase. The prototype will be updated and refined

128

iteratively as the game progresses, and it is interchangeably referred to as the "build",

"vertical slice" or "playable". Although the term "build" is used prevalently within the industry, in this thesis, I choose the term prototype to refer to this updated version of the game during the project. This is because the term prototype seems to be intelligible to a wider audience.

The developer and publisher use the prototype as a point of reference and discussions both within the studio and across the companies. This is regarded as the most effective way to communicate and create better understanding between different disciplines. Brian – a developer executive and founder of a very successful studio – delineates how in their studio they have replaced the "time and resource consuming" game design documents with the prototype to create a better understanding of the vision and the game between different disciplines. He states:

For our projects we actually create a prototype really quickly and focus on updating them iteratively as we go on. Some people certainly in the past quite often would write a lot of things down in a bulky bible, but we've decided to skip the documentation, but talk about what we want to produce and then just create a build (prototype) really quickly. That goes pretty well because it gives us a talking point between teams, and it actually gives us something to play, and then see if there is either potential for fun or actually if there's fun in there at all (Brian – developer executive).

The prototype shows the gameplay and features of the game, and it also displays the dependencies of different disciplines. In addition, the prototype allows all the stakeholders, including programmers, artists, designers and the publisher, to see and test how their ideas can all work together. A developer producer and creative director called Dylan highlights how not having a playable version of the game until late in the development created misalignments between different teams; hence, a detriment to their project:

On that project we were constantly trying to catch up with where the art and design had gone to, with the technical side of it. So I would say doing the build (prototype) and having something playable is a great thing to have, something that people

129

would look at and say yeah it works; it’s fun. But this was something we didn’t do on Star Soldier. Looking back on it, maybe we should have done a build (prototype) using our existing engines. But now I’ve learnt that when we do a project, the first thing we do is get something playable going and make sure it’s fun cause if it’s not fun there’s no point in making it (Dylan – developer producer and creative director).

Apart from building a common point of understanding between publishers and developers, the prototype also helps the developer plan the development process more realistically. The prototype provides an overview of the development and the resources required to finish it, such as staff, technology and time. Therefore these requirements can be easily detected by the developer and communicated to the publisher. Marcus, a developer lead artist, elaborates:

Key to keeping a project on time and budget is to know before you start (a) exactly what it is you're making and (b) that it's actually something fun. The only reliable way I know of, to do this, is to prototype things at the start, iterate them as you go along, and then when you're happy with the results, enter full development. I've seen projects come together without prototypes and it's pretty galling to only reach the stage where a game is properly playable late in development and to realise that it's not actually much fun. Obviously that then requires extra work to turn it around, which will often add to the time/budget (Marcus – developer lead artist).

Keeping the project on time and budget is one of the main objectives of any publisher investing in a project. This is also important for a development studio, because sometimes the costs of running a studio for one extra month can be so high that the developer may find it difficult to finance. There can be a breakdown in the publisher-developer relationship if the project runs late and requires extra budget. This might result in the termination of the project and sometimes the demise of the development studio. Therefore, using a prototype which is gradually upgraded and updated can prevent these problems and create a better understanding of the development process for both the publisher and developer.

130

The prototype is sometimes created at pre-production stage, as a proof of concept, gameplay and assets for the publisher or other investors, to raise funds. The prototype is also used throughout the development process to show the investors/publishers or other stakeholders how much the project has progressed. The updated and playable version of the game seems to be the best document to be presented to the publisher for each milestone, through which the publisher can assess and track the game’s progress. Paul, who is a publisher producer, emphasises the importance of the prototype (build/playable) in winning the trust of the publishers to invest:

The playable (prototype) is like seeing five minutes gameplay that represents of what the final game will be like. So by seeing a vertical slice, you can de-risk that massive chunk of money that you must spend because then you know what the game is going to be like. The analogy might be like making a show home, for a property developer. When the developer can’t afford to do that, it is a sort of like rolling the dice for the publisher (Paul – publisher producer).

Another publisher producer confirms that he wouldn’t approve any milestones, unless the developer presents an upgraded and progressed version of the prototype:

I would always ask for builds (prototypes). For me the proof is always in the build (prototype), I’m not interested in things that are done in people’s PCs, I’m not interested to see 50 assets, like 50 cars, made on PCs. I would ask to see those 50 assets in the game, so the idea of hiding stuff becomes very difficult for them. Since all the milestones are quite based on builds (prototypes) that I can play and I can see, not documents, it makes it harder for them to hide stuff away (Matt – publisher producer).

Here, the publisher producer believes that the prototype can provide more transparency on the development for the publisher, through which they can track the development progress much better and hold the developer accountable. In the quote below, Ken, an experienced developer producer, also suggests that the prototype maintains clarity. However, he complains that this transparency might not be as beneficial for the developer, which is why sometimes they prefer to not show all the changes to the publisher. Ken thinks submitting

131

the prototypes to the publisher might create some conflicts. This is because the publisher might disagree with the diversions from the original vision and game specifications that were documented and agreed upon in the contract and game design documents. In these circumstances, the producer himself intervenes to explain the prototype and negotiate the changes they have made to the game. Ken states:

In my experience, the publisher would often like to have builds (prototypes), but we’ve always been slightly cynical about that and it comes from the fact that if you are not there to talk them through things, especially when you’ve introduced a new feature, for example if you want to try something out that it’s not budgeted for, then you get all these questions: why are you doing that? Why aren’t you doing what we’ve asked you to do? They start asking endless questions; most of the time you just prefer not showing it to them. The best way of showing them the build (prototype) is standing next to them and say, look this feature here, don’t worry about that, forget that, but if you are not there to say it, they may think you have focused on something that is broken (Ken – developer executive producer).

The interview data showed that publishers and developers used dynamic boundary objects such as iterative planning methods, meetings and prototype at the later stages of production to facilitate their collaboration and knowledge integration. These boundary objects were utilised both within the development studio and between the studio and the publisher. The participants highlighted the unpredictable and complicated nature of videogame development, stating that detailed planning and implementing structures were only useful at the outset of the project to create stability and security for both parties. However, dependencies and unpredictability of the project necessitated the use of boundary objects that could be easily updated and upgraded. That was why the participants found dynamic boundary objects useful for the development process. The participants highlighted that through discussions and conversations they facilitated the use of dynamic boundary objects and created a better understanding of their dependencies, vision and the directions of the project. This refers to the role of brokers in mobilising the effective use of dynamic boundary objects through their mediating and negotiating abilities. Brokers or producers (as they are called in the videogames industry) are responsible for mediating and negotiating between the publisher and the developer. Brokers/producers are regarded as

132

key to the development success and the publisher-developer relationship, and they are also central in mobilising dynamic boundary objects. Therefore, I have allocated the penultimate section of this chapter to elaborate on their role in the videogame development.