Max Nichols' Game Design blog
Let’s talk about making choices. Full-time game designers typically make hundreds of choices every day. Most are tiny, some are more substantial. Most are made unconsciously or with only a second of thought, and most of the rest are decided quickly. These quick daily decisions are the engine of our game design aesthetic: they showcase it and refine it.
I’m here to talk about two related topics!:
1. Tools teams should prioritize their users’ ability to maintain focus while working.
2. Not every second saved is equal, even for the same person within the same workflow.
There is a tendency for tools teams to use the metric “time saved” to help prioritize their work. For example:
– “This change will shave 5s off of an operation that is used 1000 times a day across the studio.”
– “This change will save 2 hours on a task that 10 people do once a month.”
After 9 years–fully half of my adult life–I was let go from Bungie this morning, along with MANY other amazing folks.
Getting to work on a game like this, where I made and helped make experiences that are enjoyed by millions of people, was a huge privilege.
But I don’t want to leave this off with a simple “it was a privilege, thank you Bungie”.
In a recent twitter thread, I posted a general challenge to professional game designers to share more of their game design documentation. The goal: give academia more examples to learn from. I’d better put my money where my mouth is!
But first, I wanted to share some general thoughts about project documentation, and examples of common documentation archetypes.
As game designers, you’re used to thinking about games as systems of rules. You may know rules as things that are enforced by game systems via constraints and affordances: a game is hard-coded to allow this action, but not that action. Voilà, a possibility space is defined!
But many rules are NOT enforced by code or systems, and are instead conventions, patterns, or best practices that the developers stick to when building content. Let’s look at some examples.
I gave a presentation on the Technical Game Design role via Twitch at the Indy Summer Showcase in July 2020. In it I include my definition of tech design, some examples of what tech design work is like in a AAA studio, and some detail on how one can become a Tech Designer.
With the end of our semester fast approaching, let’s talk
about “closing” this week!
I use the term “closing” for a set of related things:
The final stage of a project or milestone, where you’re trying to take it over the finish line.
The skills that one uses during that final stage.
The mindset of wanting to close: not leaving loose ends, wrapping up work in a finished state and moving on.
This week let’s talk about an important skill: Prioritization.
In a large studio environment, the ability to prioritize –
triage – every task or problem that comes your way is crucial, especially if
you’re in a role where you may be randomized or need to react to sudden pivots,
changes, or requests.
Let’s do some quick vocabulary. These are all terms that we use at Bungie. I can’t promise that they use these same definitions everywhere, but they’ll help us talk about these concepts:
“Technical game designer” as a role in the industry is hard to pin down. I’ve known people with that title who solely build tools, and others who never touch code or tools and instead build content. Ask around, and every tech designer will give you a slightly different definition for the role. Here’s mine.
“Technical Game Design” is a subset of Game Design as a discipline. There are two features that set the role apart:
Chris Clay was a senior designer I worked with at Turbine. Sometimes we would spend a lot of time in the weeds, talking about a…
Preface (5/12/2015): A few weeks ago Polygon posted a news article revealing the Arkham Knight DLC and pricing. The news post was very aggressive and judgmental…