Friday, 28 August 2015

Game Design: The Design Process and the Product

Recently I've been drawn into a discussion about the design process, that's of personal interest to me because eventually I would like to put out some sort of product, and that's of general interest because I have seen it done very very badly in places where I would prefer that it be done well. However, what I would like to concentrate on here is the relation between the design process and the finished product. I've read articles where examples have been raised about putatively excellent production processes resulting in unsuccessful products. I've also been constantly bombarded with notion like "Perfect is the enemy of Good" and "It looked good on paper!" which I occasionally still like to rail against, despite having acknowledged long ago that it's better to exploit these examples of idiocy rather than to attempt to cure them.

What makes these things the same? Well, in each case there's a disconnect between what people think about something, and what it really is. Imagine a design process where everything comes in on time, under budget, and according to spec, and the product fails to turn a profit. Likewise imagine a design where the project over-runs its allotted time-line, comes in over-budget, and fails to meet specification, but it's good enough to turn a colossal profit. Finally, imagine that you read a set of instructions, and those instructions fail utterly when you attempt to implement the procedure they purported to describe. In each case, the producer has failed to understand how design, and hence production, relates to the finished product.

One of the principles of good technical writing is to put the user-experience first. Even when technical writers are carefully isolated from the end-user by business analysts, UI analysts, and everyone else, the primary concern is that the user be able to find and use the information presented to accomplish whatever task for which they could conceivably need that information. In other words, the product has to succeed. Which is interesting from the perspective of profit or loss, because technical writing, and indeed user documentation in general, is usually thought of as a cost rather than a benefit. But if this use-documentation is to succeed, it must help the user, and where it helps the user (rather than hindering them) we can see savings in other areas. If a Help file is easy to navigate and contains both helpful information, and presents it in a clear and helpful fashion according to the work users want to accomplish rather than about the product they're using to accomplish that work, it will save time (and therefore money) that users spend on the phone with technical support, help them benefit from the product it supports (and motivate further sales), and so on. Indeed, you can measure the effectiveness of user-documentation by how many calls your call centre resolves by looking up the answer in their own copy of the manual. If they're doing that a lot, then you have bad user-oriented documentation, because the end-user is not calling into the support centre because they found the manual easy to use.

Working backwards, it is the case that good technical writing, rather like planning, is not merely a good document or plan; as the wise philosopher Mike Tyson once said: "Everyone has a plan until they're punched in the face." Good documents, and plans, are the result of a production process that is teleological or goal-oriented in nature. A good design process will throw away 99% work it has done to reach the 1% that accomplishes the goal of that design process. If you won't go over budget, or over time, or off-spec to accomplish the goal of that design process, then that design process is bad.

Which brings me to the point that hand-waving away suggestions for following best-practices in technical writing, project management, design and so on in favour of stupidly using bad design practices until they somehow meet the desired goal is the kind of stupid that dooms projects, wastes time, and muddies the waters for people trying to make good. There's nothing worse for someone trying to pick up where a failed production left off than the poisoned well of ideas that's left behind after failure. It's said that 'success breeds success' and that we want to use 'best of breed' practices, but evolution does not work like that, and following only in the footsteps of what has 'worked' before is how we get to people disregarding good working practices that would result in excellent products if only they were employed appropriately rather than fetishized.

Take, as an example, a schedule. Schedules are good. Well documented schedules using Gantt-charts and so on are good too. Production schedules which sacrifice the purpose for which they are intended, which is to ensure a good product need to be amended, are bad. Which is pretty much what separates the best practices from the worst, and that is an explicitly acknowledging that the practice is instrumental to achieving a goal, rather than an end in itself.  The other part of all best practices is that these practices, like good technical writing, aid oneself in conducting gap analysis and learning lessons to apply to the next iteration of the production. Structuring ones project using particular best practices means that, if/when they fail, you can go back and see why they failed so that you can avoid it in the next iteration.

So when I suggest using a particular practice in design (and other project work) the idea is not to concentrate on applying that practice purely to the exclusion of all else, or to sacrifice the goal of the project on the altar of bureaucracy. The idea is to take a tool out of a toolbox and to try it out, and to test the tool as much as apply it. Technical writing, like other design disciplines, is a toolbox with an array of tools that can be used well if they are used to accomplish a goal, rather than used to be used.

Being able to learn from mistakes is important, particularly if you want to build on the experiences of others, and save yourself a lot of time and whatever else might be a cost to you. The worst mistake to avoid is disregarding the experiences of others, particularly where they disagree with your own, because that disagreement indicates a lack of knowledge; what knowledge do you lack that you cannot at least understand their perspective, if not agree with their argument? Perhaps more interestingly, what knowledge do you lack that you think that you do understand their argument, and merely find it to be unsound?

I've used an iterative design process for Titanomachia because I want it to succeed, and I have some pretty tight constraints to do with all three axis of time, budget and specification. I've also tried to apply technical writing best practices in each iteration, because in documenting each design I've created a knowledge base of what has moved me forward to reach my goal, and what has side-tracked, distracted, or failed me. Writing down the rules I've created so that other people can understand the latest game I've playing is a fantastic way of generalizing beyond not only my limited experience, but beyond the limited experiences of my play-testers, and has helped me avoid poisoning that wonderful well of play-testers with builds that worked well enough when I design-played them, but contained flaws that were obscured to me, and that testers would have seen in seconds.

Which brings me to my last point, about bias. Being as close to a project as a designer is difficult because you have an idea of what the project should be like when you complete it, and that can get confused with what the project actually looks like at any given stage. Writing it down in cold, objective technical-style writing can help to distance oneself from the project, just as a good prose writer might leave themselves some time between writing and editing their work. Sometimes the goal, or what we might imagine to be our goal, can distract us from how the project is actually going in relation to our stated goal. It's especially important when things seem to be going well, with play-testers and peers on side with the current build, and no particular reason not to let your guard down.

When people like Stephen King say "Kill your darlings" they don't just mean favourite characters, or personal indulgences, but also those parts of your work that you are personally invested in, and that seem like the important 'big ideas' that form the successful foundation of your work. In game design terms, the question of such a feature should not be: "Does everyone like it?" but "What benefit does this give to players?" If it doesn't benefit players to include such a feature in the game, despite however interesting or unique or appealing it may otherwise seem. I've done this several times with the turn sequence of Titanomachia because most (and soon perhaps all) of my iterations of Titanomachia so far have required players to game the rules rather than play the game. The benefit of a good turn sequence should be that gaming the rules involves playing the game, and while I believe that I have accomplished that with my latest turn sequence it may not be the case once I've completed the build.

After all, if I'm going to learn from what works, and learn from what doesn't work, I'm going to have to know how to evaluate my understanding of these things, and as in all best practices for projects a reflexive epistemological stance is something I'll hold to until I figure out if it interferes with me producing a great game. Of course, we won't know if it's great until we see a fanatical group of die-hard haters grow up to hate the game itself, and me personally for creating it!

No comments:

Post a Comment

Looking forward to hearing from you!