This year at GDC I had an amazing 100% streak of seeing all good talks! I credit this to finally being able to intuit a talk’s quality based on how the description in the scheduler is worded (Of course, I have no data on the talks I skipped to back up that they weren’t good. Maybe all talks were just good this year!)
For context, when I go to a talk at a conference, I am looking for practical takeaways. I want to see how designers solved hard problems and learn something that I could feasibly start applying to my work right away. This is not to say that I dislike inspirational talks, I just try and reserve GDC for practical learning. Here were my favorite talks:
- The Gamer’s Brain, Part 2: UX of Onboarding and Player Engagement
- Engines of Play: How Player Motivation Changes Over Time
- Idle Chatter: What We Can Learn from Self-Playing Games
- TL;DR Statistics for Game Devs: the math you need to win arguments
- Rules of the Game: Five More Techniques from Quite Inventive Designers
And now in great detail…
Celia Hodent is a PhD in cognitive psychology and the Director of UX at Epic, and this was a follow-up and deeper dive to a User Experience talk from last year (which I hadn’t seen, but had no trouble keeping along this time). She reviewed how the human brain learns and the encoding and storage of memory, and then went into the meat of the talk about onboarding, the process of capturing your audience’s attention within the first minutes of play.
Though retention and long-term engagement are certainly important, she did a deep dive specifically into user experience of the first stages of play in a game. The talk went into great detail about the elements of onboarding: Discovery (removing barriers to capture your audience’s attention), Learning (efficiently teaching how to play the game), and Immersion (engaging and motivating the player to continue to play. In each she discussed limitations in how the brain works and what psychological principles come into play in each phase (usability, learning, and motivation principles).
My favorite thing about this talk is that each concept was illustrated with practical examples from the development of Epic games, showing how things went wrong with onboarding UX, why they went wrong, and how they were fixed. Teaching players and tutorial design has always been a special love of mine, so the takeaways were extremely applicable. You can see the slides for this talk here:
Another psychology-focused talk, this was Jason VandenBerghe’s next talk in his series on the 5 Domains of Play. Specifically, this talk was a follow-up to how Jason and his team had used his research and what sorts of practical methods they learned as a result.
He covered how they used “taste maps” based on the 5 domain tables as a way of applying the research to group preference instead of individuals, since as designers we are generally concerned with groups of players. The primary value of the exercise, according to Jason, is as a tool for communication, and a way of describing the intent of your game very early in production in such a way that still has accuracy throughout the whole process. For example, a developer who has a different preference and different player motivations than the audience of the game can better understand the goals of what they are making, and not feel that they are “making the game wrong” just because that aspect of the game differs from their personal preference. It is a tool for managing expectations.
The second big takeaway of Jason’s use of the 5 domains of play in his work was the realization that you start playing a game for very different reasons than you continue playing a game. The 5 domain personality traits ended up being good predictors of why a player would try out a game, but a different model was needed to explain why players keep playing in the long term.
This latter element ended up being driven more by self-determination theory (SDT): competence, autonomy, and relatedness as the sources for motivation to keep playing. Jason went into detail about each of these sources and offered tools for reflection on how your game satisfies each. In addition, there are also already a lot of talks and much research on SDT in terms of games, so there are many avenues for follow-up.
For a good summary of the talk, check out this gamasutra article:
While the psychology of game design is near and dear to my heart, I also try and see GDC talks that I feel will expand my horizons. I know very little about the Idle Game genre, beyond how my build engineer friend has had a tab of Cookie Clicker open for literally years, so I was ready to learn. Anthony Pecorella of Kongregate gave this talk, which apparently also was a follow-up to a previous talk on idle games.
The modern form of Idle Games is quite new – Cookie Clicker is only 3 years old – and is one of the more successful genres in terms of popularity, player retention, and revenue. Because the development time for idle games is relatively short, the genre has been rapidly iterating and thus evolving. The talk reviewed the most defining mechanics of idle games – progress without interaction with no real lose conditions and frequent check-ins encouraged by modifying the game’s growth curve.
He explained the concept of “prestiging,” which is a common concept in idle games of resetting your progress to start over with more power than before. Prestiging gives an opportunity for players to think about long term strategy, which seems counter-intuitive when on the surface it looks like resetting all your progress, but this concept is what keeps players in for the long haul. He also covered how monetization tends to work in Idle Games and why the models seem more palatable to players even though they appear to be similar to typical free-to-play monetization. He then discussed some of the innovations that have shown up in idle games just within the past year, and suggested potential routes for innovation in the future.
I enjoyed this talk for its numerous examples for each concept, and its practical way of explaining how and why idle game features work the way they do. I’m not sure I’ll be jumping into making an idle game any time soon, but this talk certainly expanded my designer brain to consider it an option in future project brainstorms.
The slides from this talk can be viewed here:
Elan Ruskin is one of my favorite speakers, and my motivation for this talk was to expand my knowledge about practical use for statistics, which is an aspect of design where I am currently somewhat weak. No one can make a math talk quite so entertaining as Elan.
The talk focused on four different types of statistical tests, how they worked, what circumstances to use one over the other, and how to use them to approach design arguments empirically. Or, as he put it, “Four ways to science decisions instead of opinioning them.”
Most of the examples in question had to do with making decisions based on small sample sizes, which is a common situation in design. He warned of the dangers of making decisions based on averages, which tends to be a default tactic to those of us who are less experienced in the maths. Elan gave hypothetical examples and explanations of when to use the following tests:
- Student’s t-test (on continuous outcomes with normal-ish populations)
- Paired t-test (continuous outcomes with paired samples)
- Relative risk or difference of proportions (on binary outcomes)
- Mann-Whitney , a non-parametric test (for non-normal distributions)
The examples used to illustrate these scenarios were quite relatable, and Elan went through many cautions about many common pitfalls encountered in trying to use statistics. In addition, he provided instructions on how to do all of these in Excel. You can see these examples and a copy of his slides here:
This was a series of 10 minute talks hosted by Richard Rouse, wherein each designer presented a design rule that was personal to them, and how they used it. All 5 of the mini-talks were excellent, but for the sake of time I’m going to focus on the one I went to see: Liz England’s tip on creating actionable documentation.
Game design documentation is always a point of contention, with the poorest examples being large, lengthy “bibles” that no one reads and are instantly out of date anyway. I’ve always known Liz to make excellent documentation, so I was curious to see her insights.
The first takeaway was to make documentation for people, not features. Your documentation has an audience, and what goes in it and how it is formatted will depend on who that audience is. A programmer that needs to implement a feature has different needs than a designer who has to use that feature in their level. The more specific the audience, the better the documentation tends to be. Maybe this AI programmer prefers use cases and that one prefers flowcharts. Basically it is a reminder that documentation is a tool for a very specific audience.
The next takeaway was that documentation should be actionable, it should have an explicit purpose. Liz encouraged us to approach this with a philosophy that all designers are already familiar with: “use your verbs.” The purpose of documentation is never just for someone “to read.” Maybe it’s documentation to inform marketing of what the features of the game are. Maybe it will help a programmer to implement a feature. Maybe it is written to help QA to debug a particular system.
Liz ended with examples of a number of different forms of documentation she did for the missions and quest system of Sunset Overdrive:
- A highly detailed and visual map of the in-game city used by most of the team to keep track of the state of the city. (For the team to track)
- A more simplified printed map and moveable post-it notes to help the challenge and quest designers identify where to populate the game with content (For quest designers to plan)
- A dense mostly-visual flow chart that showed how content unlocked in the game and the order of missions and quests used by QA to know how they should be testing each bit of content (For QA to debug)
- Another more detailed flow chart for the mission system programmers with more text explanations of the logic flow of how players accept missions, what happens when they fail, die, quit in the middle of one, etc. (For programmers to implement)
- A more generalized version of the same flow chart with specific examples from game for mission designers to reference when considering what might affect their mission structure. (For designers to plan)
She closed with some other practical considerations when it comes to documentation, such as retiring documentation when it has served its purpose, how documentation style can depend on team size and structure, and the suggestion to write documentation only when it is needed, not before. It was an excellent summary of useful tips on an aspect of being a designer that isn’t necessarily the most glorious, but one which is important.
Liz’s slides along with the slides of the other tips which I didn’t go into can be downloaded here (powerpoint) http://paranoidproductions.com/miscwritings/RulesOfTheGame2016.pptx
That’s all from me! In addition to these talks, there were a number of others that I didn’t see but heard were quite good, and I definitely intend to check them out on the vault when they become available – lots of topics on procedural generation, machine learning, and process talks from a number of post-mortems.