Maximum creativity: Open and Closed Mode

[In this reprinted #altdevblogaday opinion piece, Climax Games technical designer Claire Blackshaw looks at Closed and Open Modes in the context of game development, and discusses the benefits of Open Mode.] A video recently cycled through my friends' social circles which I wanted to share: John Cleese talks about Creativity and Open and Closed thinking modes. The TL;DR of John Cleese's talk Closed Mode Purposeful, highly productive, but not creative. Good for getting things done. Default mode at work. Open Mode Playful, curious, fun, humorous, relaxed, contemplative without goals. I had a lot of takeaways from that, but my biggest takeaway was what could I do to be more open and enable openness around me. In the past I've drawn mostly from my dramatic background and improv lessons, always saying yes. See Lisa Brown's brilliant article on that topic. Humor and time are key to being in the Open Mode. Also goals, hierarchy and authority are not conducive to the Open Mode. An interesting thought for those of you who read the Valve Employee Handbook floating around the net at the moment. The key thought this lead me to is simple… You can't play by proxy Too often I espouse the brilliance of the programming designer. The real magic is simple, you cannot play by proxy. A designer who can't play (and change) with gameplay is like a chef who gets someone else to taste the food and describe it. An artist who cannot change the appearance of something in-game without someone else is like painting on canvas by instructing a monkey holding a paintbrush. A programmer who cannot go outside the spec is like a dancer in a straight jacket. You need to hold the ball in your hand and feel it bounce. Always ensure your source control, build server and other tools do not stop someone's experimentation. The Open Mode is unachievable in crunch time A common example of the Open Mode in game development: someone has just implemented a system, which due to an amusing bug is glitching out or not behaving in the designed fashion. In a crunch time, i.e. closed environment, a bug is filed, profanities are hurled and the bug is squashed. In an open mode and a lighter environment, possibly earlier in the project, the group plays with the bug and says something like, "Isn't that interesting…" Now to be clear, most times nothing immediately comes from that comment, though at times a brilliant idea or mechanic emerges. Often these moments lend themselves to interesting gameplay moments. For a prime example of a game development project by Open Mode-style thinking, look at Minecraft. Many gameplay features started as bugs or unintended behaviors, which in a traditional environment would have been eradicated but the players enjoyed it and Notch left it in. In order to achieve things, we need to be in a Closed Mode. Though it's easy to get stuck in that mode and with tunnel vision run down our path missing all the brilliant opportunities that are being thrown up during game development. Playful tools When designing or creating a tool or pipeline, think about how your tools enable playfulness, experiment and toy around with your tools. A willingness to create without fear. Observe how playful we are with pens, for many of us our primary tool. Two developers, one creating a scene in notepad with fragile .xml, the other drawing a blueprint in Photoshop. The drawing-based solution is more fluid and open to play. The developer can draw a "humorous shape" and see it in-game without fuss. Leading to greater comfort and competence, discovering creative uses of the tools. Nothing can frustrate and break playfulness more than a deep pipeline or frustrating tools. A buggy or frustrating tool ensures you're in the Closed Mode. As in the Closed Mode, we are less likely to make mistakes and can follow rigid guidelines. While being creative, nothing is wrong We live in a digital world of hacks and cheats, we care for results not method. The thing which appears on screen is a beautiful lie. So if your engine is refresh-sensitive and those silly European televisions are giving you trouble, well, just turn up the earth's gravity*. Remember the product is the experience, not the game. Too often a professional artist, designer, programmer or otherwise will dismiss or stamp on a comment because it's patently silly. They insist on saying it's too complex or saying it's daft. Now please, respect the professional skill for which the individual was hired. Though at no point should someone be crushed or demotivated by the HAMMER of authority. Jam, jive and jiggle Encourage people to take time out to play in fixed time periods to jam, jive and jiggle. I write this after having just finished a weekend of Ludum Dare fun. The result of the Jam is less important than the time to play. The time to ponder and play with an idea. If you have a sprint structure, try to take some time out after a sprint or a whole sprint, WITHOUT GOALS! Just play. See what comes from it. People need to feel free to play with ideas, in order to have great ideas. * A real humorous example of an engine hack seen in the wild. [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.]