Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Get the latest Education e-news
  • Lessons Learned From Teaching Game Design

    - Lars Kalthoff

  • Rule 3 - Reduce assignments to their core

    The primary goal of teaching is to bring about effective learning, that much should go without saying. But it's not that obvious what it even means to learn something. For me, it comes down to two aspects: having a realization and remembering it. It's possible to have an epiphany and forget about it within a few hours. In that case, there was no learning because the information never made it into long-term memory. It's also possible to store something in memory that hasn't been accompanied by a realization. This is often the case with information that doesn't have any meaning for the person remembering it. For example, we don't "learn" our passwords, we just remember them.

    If learning is about realizations and memory, it's easy to see how those two elements relate to course development. It's our job as a teacher to design the realizations. We decide which ideas to teach, consider how they fit into students' existing knowledge structures, and explain them clearly and simply. But how do we make sure that our students remember these realizations? It seems like our memory isn't under our direct control. We remember silly advertising slogans and forget the names of people we work with every day. So what is it that we remember?

    As the cognitive scientist Daniel Willingham puts it, "memory is the residue of thought." It doesn't matter what the teacher wants the students to remember or what the students try to remember because it might be tested. Whatever they thought about during a session is what's going to end up in memory.

    For teachers, this means that we have to consider carefully what students are going to think about in every part of our course. Consequentially, we have to get rid of any challenges that aren't related to the material at hand. Assignments pose a real danger to this approach because they frequently come with hidden tasks that distract from their original purpose.

    Imagine an assignment where you ask students to model the economy of World of Warcraft in Machinations (a tool to visualize and simulate resource flows) and present their findings to the class. This assignment comes with four hidden subtasks: figure out what World of Warcraft is, analyze its systems regarding the exchange of resources, learn how to use Machinations, and design a presentation. Your students could be thinking about World of Warcraft, its economy, Machinations, or PowerPoint, and whatever they thought about most is what they're going to remember. If the goal was to deepen students' understanding of game economies, this assignment failed miserably.

    One problem of game development programs is their reliance on digital assignments that often require students to familiarize themselves with specific software. This can become an issue, especially for game designers because they use tools as means to an end. A 3D artist might use Blender to learn 3D modeling in Blender. A designer might use Blender to create models which are then used to practice level design or set dressing. However, it's questionable whether the designer learned more about modeling or level design in the process. The same issue arises with assignments that require students to build digital prototypes to apply a certain design concept in practice. Is the student thinking about the game design concept or are they dealing with Unity's input system, prefabs, and null pointer exceptions instead?

    Reducing an assignment to its core means taking into account all the underlying steps that make up the exercise and getting rid of any tasks that divert the students' thoughts away from the subject matter of the assignment.  

    My three-hour session on player guidance included a practical group assignment in which students sketched out a level for a digital game and then applied guiding techniques to lead the player towards the goal of the level. The exercise was described in the following way:

    The purpose of this assignment was to get students to think about elements of player guidance in the early stages of level design and make them consider which guiding techniques are appropriate in a given context. There were three things I did to reduce this assignment to its core:

    First, I decided to focus on the planning phase of level design. The assignment could've been about creating a small level blockout in a game engine. However, this would mean that students spend most of their time figuring out how to make level blockouts in Unreal or Unity, setting up a basic character controller, and playtesting the level. The chance that they'd remember anything about player guidance is fairly low. By asking for a level sketch instead of a playable blockout, hidden tasks are minimized and player guidance becomes the focus of the assignment.

    Second, students were free to choose which software to use for the level design sketches. The idea was that the students would go with the tools they're most familiar with already. In doing so, they're reducing the time in which they're thinking about software instead of game design to a minimum. Also, it was up to the students to decide what kind of game would be the base for their level design. If I had specified the game type (e.g. "design a level for a Metroidvania game"), the students who are less familiar with that genre would've been required to do some research before they could attend to player guidance.

    Third, I broke down the assignment into three consecutive steps: sketch out a level layout, define critical paths, optional paths, and the golden path, and add elements of player guidance along the golden path. This step-by-step instruction helped students organize their approach to the exercise, but it also forced me to consider all the subtasks that make up the assignment and ensured that there were no unknown hidden tasks that the students would have to engage in.

    There's a second layer to reducing an assignment to its core that is different from removing unnecessary obstacles: a well-designed exercise reflects the nature of the discipline you're teaching-its core so to say.

    For me, game design-and design in general-comes down to this: creative problem-solving within a set of constraints. There's a problem to solve or a question to answer (e.g. "How do we make sure players don't get lost in this massive open world?"), you generate ideas to figure out a solution (e.g. "There could be travelers that provide you with directions"), and those ideas are tested against certain restrictions (e.g. "We don't have enough time to model additional characters"). Game design assignments that approximate this process exemplify the core of the discipline itself.

    The instructions you've seen before only constitute one half of the player guidance assignment. The more interesting part was that every group received a level theme and a guidance constraint for their level layout. The level themes roughly defined what kind of place their level should resemble (e.g. a temple).

    The guidance constraints were conditions that had to be considered when deciding which guiding techniques might be implemented (e.g. you don't want players to notice the guiding elements).

    Let's say our group received "abandoned factory" as the level theme along with the following constraint: "The art director reminded you of the minimalistic approach to this project. Use as few different elements as possible."

    We now have a problem to solve: how can we guide the player effectively without using a lot of different elements? Essentially, this problem poses a question about the nature of various guiding techniques. Which guiding elements have the strongest impact on their own? That's the question we have to answer.

    The level themes serve two different functions. On the one hand, they help the students overcome the digital blank page. It's difficult to get started with the creative process when you're free to do whatever you want. Knowing that you have to create an abandoned factory triggers associations with your mental representation of a factory and gives you a foundation for your level layout.

    On the other hand, the level theme is a restriction imposed from the outside. You can't change the fact that your final level has to resemble an abandoned factory. When you generate ideas to solve the problem introduced by the guidance constraint, you have to check whether it makes sense in the context of a factory environment. For example, a landmark is a guiding element that has a strong impact just by itself. However, factories are known for their uniformity. Is it reasonable to integrate recognizable structures into an environment like this? Another problem for the students to solve.

    Ultimately, reducing an assignment to its core breaks down into two aspects: eliminating any challenges that distract from the purpose of the assignment and designing our exercises to resemble the nature of what we're trying to teach. If students remember what they think about, it's our job to control what these things are.


comments powered by Disqus