Q&A: Chris Barney on developing your own pattern language

Whether you're a new designer or a seasoned veteran, game design patterns are a crucial addition to your repertoire... but they may seem impossible to learn or master. That's why game design instructor Chris Barney is here, to guide designers through creating their own pattern language in this virtual GDC Masterclass.

Chris Barney spoke with GDC about his virtual Masterclass, Creating and Designing with Your Own Pattern Language, taking place on Friday, June 17 from 9:00am to 5:00pm BST (4:00am to 12:00pm ET).

This Masterclass will introduce the idea of game design patterns and a Pattern Language. It will walk attendees through the process of creating their first pattern. Attendees will form small groups and create additional patterns, working together to connect their patterns into a larger Pattern Language and test it out in a group design exercise.

Below is an edited, condensed version of our interview.

GDC: Tell us a bit about your course and what attendees can expect to gain from the Masterclass.

Chris Barney, game design instructor: This course will introduce the concept of game design patterns, and pattern languages of course. But the real value is in the guided exploration of the process of creating your first patterns. Initially with a small group than on your own, and then working with your group to combine your patterns into a simple Pattern Language that you will use to solve a practical design problem. Going through this process will prepare you to create any patterns you need to help you with your designs going forward!

GDC: What are some of the most common design problems that developing your own game design pattern can solve, and how does your Masterclass address these?

Chris: This is a good question because it doesn't have a single answer! Design patterns can and should be created to solve specific design problems faced by a designer. So I could try to pick a few of the most common design problems faced by designers, but the real power and beauty of creating your own pattern language is that you will do it in order to address the specific problem you face.

Designers taking the course should come in thinking of a design challenge they face. It's okay if they don't, as one of our first steps will be to work with a small group to pick a design problem to focus on for our first pattern.

That all might sound like I am dodging the question, but I'm not! Let me give an example of a hypothetical design problem and the kinds of patterns that developers might discover during the class:

Let's say that your company has developed a simple prototype of a core game mechanic that they are excited about and they want you to propose a more detailed design around that mechanic. You need to understand the mechanic, and how other aspects of the design are going to interact with it. In more traditional design you might guess at some other mechanics, systems, settings, narrative structures, etc. that you think would work with the core mechanic you have been given. Then you would build some prototypes of a game that used those elements. You would playtest them, evaluate the results and iterate until you were satisfied with the design. Or, if your time was limited you might just make your guesses and proceed hopping for the best. Of course, if you are an experienced designer, your guesses aren't blind ones, but the best of us know that we are very often not on the mark in our early designs! In the course, we will be practicing a process for replacing the guesswork with analysis and a defined way of extracting actionable design heuristics from competitive analysis and our existing design knowledge.

For example, if the core mechanic you were given was, "The ability to steal combat mechanics from any enemy in the game." You might begin by looking for patterns related to stealing abilities from enemies. You would also look for patterns relating to any specific combat abilities you might want to consider giving to enemies in the game. You would look for patterns about having enemies and players share abilities, and about having abilities relate to each other to give advantages and disadvantages. The list goes on, but for each of these topics, you would look for example games, describe how they relate to the element you are looking for patterns about, and then take that collection of descriptive analysis and identify the patterns. From there you take the patterns and articulate them using a pattern template and interconnect the patterns to form a design language. If all that sounds complicated, well it is. But! The course will take designers through it step by step and years of teaching these techniques in the classroom gives me absolute confidence that by the end of the class designers will be ready to try it on their own.

GDC: What are the benefits of building your own game design pattern for a unique problem instead of adopting someone else’s?

Chris: As the above example shows, design problems are very specific! It's unlikely that the design problem that you face will match the example I gave. Thus the patterns that you need are unlikely to be the patterns that I or anyone else has created already! Some patterns that exist may be very useful to you, but the specifics of your design problem will require other patterns that only you will have the context to extract frm your design experience and existing game designs.

Beyond the fact that you will "need" to create your own patterns in order to solve your idiosyncratic design problems, there are other benefits to the process. Formally articulating your design knowledge into the pattern format forces you to clearly document your design thinking. That is useful when communicating your designs to your team! Instead of saying to a developer, "Do this," you can say, "I need you to help solve this design problem, this pattern describes the kind of solution we need, because of that I am thinking of this implementation that I need you to help implement."

Additionally, I have found that having a pattern language that I am using on an ongoing project helps when bringing on new developers well into the project. Instead of handing them a design doc that they just have to accept, I can have them first read the patterns and then look at the design. That enables them to understand and adopt the team's design reasoning rather than blindly trying to implement the design.

GDC: What’s something interesting that you enjoy or do that most people might not know about you?

Chris: I love adventure sports, when I can get out from behind my screen you can find me rock climbing, scuba diving, or doing endurance obstacle course races.

Be sure to head to GDC Masterclass for more information on Chris's Creating and Designing with Your Own Pattern Language course, which runs June 17. Please note this course is happening virtually, not in person.

GDC returns to San Francisco in March 2023, and the call for submissions opens this summer! For more information, be sure to visit our website.

Subscribe to the GDC newsletter and get regular updates via Facebook, Twitter, LinkedIn, or RSS.

Game Developer and GDC are sibling organizations under Informa Tech.