Sponsored By

Opinion: Is 'Fun' Really What We Mean?

In this reprinted <a href="http://altdevblogaday.com/">#altdevblogaday</a>-opinion piece, HB Studios executive producer Pete Garcin talks about the dangers of using broad terms like "fun," and the value of using precise language to communicate your vision

Pete Garcin, Blogger

September 12, 2011

4 Min Read
Game Developer logo in a gray background | Game Developer

[In this reprinted #altdevblogaday-opinion piece, HB Studios executive producer Pete Garcin talks about the dangers of using broad terms like "fun", and the value of using precise language to communicate your vision.] Fun is probably one of the most (over) used words in game design discourse. It's also a broad, non-specific, subjective term that actually doesn't actually tell us anything meaningful about a game experience. I'm not here to pick on "fun" specifically, but rather to talk about how non-specific language, and overly broad terms actually prevent us from effectively communicating design visions, and from building a shared vision of a game on a team. Generic words like "fun" or "nice" offer no meaningful information to the reader, and no concrete direction or detail for those who need to act on the contents of a document. Developing a shared vision for a game is difficult – and every ambiguous word is an opportunity for there to be misinterpretation and uncertainty about direction. Broad is Bad One of the biggest dangers in using broad terms like "fun" is that they leave far too much room for interpretation. "Fun" is a pretty wide-ranging concept, and even for a single person there are a wide range of experiences that might be classified as fun. Let's say you're talking about the controls for a game and you describe them as needing to be "fun". What is it you mean? What does fun represent? Are fun controls accessible? Easy to learn? Obvious? Or are they challenging? Require mastery? Have depth and subtlety? To different players, and in different contexts, all of the above descriptors might be broadly described as "fun" controls – but without using more descriptive terms, you cannot get at the intended vision for the controls. And so what you get back might be wildly different than what you asked for. Instead, design documentation calls for specificity – for the vision for the controls to be laid out in precise detail, rather than broad sweeping terms. As we'll see shortly, precise detail does not mean exhaustive tomes of text, but instead, tightly honed, meaningful phrases. Who Is The Judge Of "Fun"? Subjectivity is the other major downfall of overly broad and imprecise language. Let's say you managed to get controls that were more-or-less what you were after, but that something isn't quite right. If at the outset you used terms that were subjective, like "fun", it is difficult to refer back to those and use them as an evaluation metric. You're stuck with: "Well, what I actually meant was…" – which isn't a very effective way to give feedback. Using precise, non-ambiguous terms to describe features and requests helps minimize the amount of subjectivity present – and as a result, makes discussion about what things need to be, and whether they are at that point easier. Be Precise So much design and communication surrounding creative development is sprawling and unfocused. It dances around the core of what it is trying to communicate and fails to convey concepts effectively. It's not because the visions being communicated are so nebulous that they can't be put into words – but more a failure of discipline, to recognize that writing and communication is often an act of reduction: of paring things back to their bare minimum, rather than adding more. When asked to clarify something, the first instinct is often to write more to "expand" on a thought. Often the right thing to do is to reduce, and distill what is already there to something more concise. In audio, subtractive EQ is the process of removing certain frequencies to accentuate others: you gain clarity and focus by removing information from the signal. When writing about features, design, or even technical specifications – clarity, precision, and brevity can be powerful tools to helping be more effective communicators, to help build a shared vision (by effectively communicating the vision inside your head to another person!) – and to help reduce ambiguity about expectations and outcomes. Documentation needs to stand on its own – when someone refers back to it and its author is not around to clarify, having clear, effectively written documents become critical. If we move away from using overly broad, subjective filler words like "fun", and take the time to focus and craft our phrases to be precisely what we mean – we'll actually go a long way towards actually being able to realize the visions that we're trying to communicate. [This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like