5 Tips for Teaching Game Design to Non-Gamers

Post previously posted on my personal blog @ tjmatthews.net

-----------------------------

I recently engaged in a project which involved getting a team of students from non-gaming academic backgrounds to explore creating a pro-social game design concept which would then be expanded into a game design document. We had a week together in which to discuss game design and explore the topics which underlined the core focus of the game, and, I'm proud to say, the group transitioned from being those who didn't know their emergent gameplay from their experience-driven gameplay, to a band of amateur designers twisting core concepts and themes to create game ideas that demonstrated pro-social themes in not only aesthetics and narrative, but also in gameplay and interface.

This week of guiding game design education has given me insight into a few key differences between teaching design to (excuse the outdated terminology) gamers and to non-gamers. By this distinction I mean the difference between those who sit down and dedicate hours at a time to video gaming, and those who played Angry Birds once two months ago. It's a loose, vague, segregation, but I think you understand the general idea.

On to the advice; it's worth keeping in mind here that I didn't have a particularly large budget of time nor money during these sessions, so this is all advice for teaching that can be done using simple computing equipment, no consoles or expensive equipment necessary.

1) Let them play!

This one feels so obvious that I shall list it first and get it out of the way. Without even interacting with play, asking a group to understand the core principles of play would be fruitless. 

Get the group to dedicate a portion of time to just playing and exploring a single game title between them. Ideally, the title should be something that's deep enough to be explored for a solid period of time, but without any tricky usability or playability barriers like unfamiliar controls or extreme difficulty. Casual games like Crossy Road or Alphabears would be appropriate here, whereas Dark Souls or Metal Gear Solid V probably would not.

I saw the best time to set this task of exploration is after an introduction to many of the core components of game design, which will allow the group to connect components in their head to components on the screen. Once that first connection and recognition of design is made, it appears easier to recognise the same components in other games, even without direct interaction or play.

2) Reference other media

Whilst your audience may not be well versed in gaming examples, they should, at the least, have some grasp on other popular medias, whether that media be film, television, music, literature, or something in between. If it's possible for someone to recognise the difference in thematic design between Full Metal Jacket and Happy Feet, then promote that same critiquing contrast for the difference between Call of Duty and Flappy Bird. Adapt conversations that compare rhythm and bass between musical genres to conversations that compare pacing and difficulty curves in player learning.

Another advantage of utilizing the universality of popular medias is the confidence building of a group otherwise lost in unfamiliar examples and terms. In all likelihood they are able to critically review non-gaming media without much conscious effort, and when they realise this they will understand that applying the same cognitive evaluation to video games, an unfamiliar medium, is not out of their reach.

3) Design in reverse

For my specific workshops, I was asking the group to create a game concept of their own, and, whilst your individual goals might be different, ultimately there should be some documentation of design. If you've created a game before, writing a design on paper is considerably easier. If you've played video games before, writing a design on paper is at least somewhat easier. If you've done neither, then writing a design down on paper is not an intuitive process.

To combat this, I explained best practises for writing down game design documentation (in this case, a simple god document for sharing internally within the production team), and then tasked the group with using a specific game example as a catalyst to write their own design document for it.

Despite unfamiliarity with the game, I found that everyone was able to accurately deconstruct the example without much need for followup explanations. It also helped to show gameplay videos as well as allow first hand experience, as first-time players are not likely to get to explore all of the systems inherent in the game within their short play session.

With this deconstruction example in place, the group was essentially able to reverse engineer their thought process in order to construct a design document from scratch. Not only did having a pre-made example mean that there weren't any small components missed out from the final document, but also that even when considering the design in the first place they were able to have a more holistic view of how each component merges and intersects with one another. It got them to see the relationship between what is on the page and what appears in the final game, and that was very beneficial for their breakdowns.

4) Separate them from 'the player'

One of the first issues that I noticed when getting the group to consider their own game concepts was that they couldn't conceive of any more of a creative way of motivating their players than simply 'telling them' how to have fun. That is, pure mechanical exposure, no hiding of gameplay behind narrative, or aesthetic, or fantasy. They (rightfully) saw games as a series of systems, and thus (wrongly) assumed that the best idea was to expose all of these systems to the player.

Obviously this limits the complexity of any game you can design, and it also begins the design process by overloading the player with more information than they want! Furthermore, when you consider that we were designing prosocial games, and design motivations for prosocial games are only effective when not transparent [1], this is clearly an issue.

I made sure to sit them down and get them to think of themselves as distinctly separate from the player, much in the same way a film-goer does not have the same information or motivation as a film director. They need to understand that their motivations for designing a game may, and most likely will, be different from the players' motivations for playing.

5) Ask questions

Game design isn't a set of rules to follow, it is a discourse! With that, means that even the  most inexperienced game player may come forward with a novel, interesting idea, so it's in your best interests to listen and, more importantly, poke around for more information.

Non-gamers aren't likely to have their imaginations limited by a set of familiar design tropes. They will probably come up with concepts not feasible for a game title, but within each concept is a unique idea worth picking apart and trying to morph into something actually playable.

Therefore it's crucial that you ask as much as you tell. Ask if they understand your explanations. Ask them to repeat back information in their own words. Ask them how their ideas work. Ask them why their ideas work. Ask them to link their ideas to game design concepts you've shared. Ask them to explain their audience. Ask them to explain how to adapt an idea for a different audience. Ask them what considerations they've made. Ask them what they might have forgotten. Ask. Ask. Ask.

-----------------------------

I hope this advice has proved useful to anyone considering introducing pure novices to the field of game design. For more resources, including the specific workshop materials I used during my game design sessions, check out my website @ tjmatthews.net.

REFERENCES:

[1] - http://cyberpsychology.eu/view.php?cisloclanku=2015091601