Max Nichols' Game Design blog
At the most basic level, FPS gameplay is the interplay of line-of-sight, movement, facing, cover, and timing between a player that can shoot what they see, and at least one opposing entity that can shoot back. Let me illustrate a little bit.
As a game designer, maybe you’ve got some high-level goals for a [system/level/feature], but how you achieve them is a blank slate. Too blank.
Earlier in my career this meant undirected brainstorming until something clicked. Agonizing.
Here’s my top-down strategy for this kind of brainstorming.
I hooked up my 360 and Guitar Hero 2 and was shockedpikachu.jpg that my skills had decayed enough that I had to play Medium, hahah.
There’s a lot of great stuff about the game, but I think it is really an absolute masterclass in difficulty ramp design, and teaching players mastery. It’s worth study.
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”.
One of the ways to create a sense of place and make environments more memorable is to engage more of the player’s senses. As game creators we don’t always have a lot of avenues to do this! We can’t actually provide smells, for instance. If you’re working on a pen and paper game, as some of you are, you may not have direct access to ANY of the player’s senses, and need to instead evoke them with words.
So some useful angles to look at this from:
The theme of this class is “World Design”, a subset of Game Design. The goal of this document is to explain what that means!
“World Design” is nebulously defined. Some companies have “World Designer” as a job title, but they don’t necessarily describe the same job. I’ve seen it used to describe traditional mission or level design work, designing vast non-linear spaces in open world games, and even the design of systems or UI related to the game world. So we will use a very broad definition in this class.
If Game Design is…
I recently posted a challenge to game designers to share more of their documentation, so academia had more examples to learn from. And then I posted an Outline of Game Documentation, with some high level descriptions of different types of game design documents. Time for me to share some!
Previously I shared a bunch of character specs from Infinite Crisis. These were finalized spec documents, representing the end point of a long iterative design process before production on the character began in earnest. This time let’s look at some of the documents that I wrote as part of that design process.
I recently posted a challenge to game designers to share more of their documentation, so academia had more examples to learn from. And then I posted an Outline of Game Documentation, with some high level descriptions of different types of game design documents. Time for me to share some!
From 2012-2014 I worked on a DC Comics MOBA called Infinite Crisis. I was one of the Champion Designers: our team was responsible for designing the character abilities and overall balance. I ended up as the tooltip guru: I cared a lot about their conventions and the way we used language and keywords. I have a small collection of documents related to this work!
I recently posted a challenge to game designers to share more of their documentation, so academia had more examples to learn from. And then I posted an Outline of Game Documentation, with some high level descriptions of different types of game design documents. Time for me to share some!
From 2012-2014 I worked on a DC Comics MOBA called Infinite Crisis. I was one of the Champion Designers: our team was responsible for designing the character abilities and overall balance. Generally, a given character would be owned by a single designer from start to finish, and over months of design iteration (which I’ll cover in another post), we’d eventually reach a state where we were confident in the design we were going to make. At that point the designer would write their first draft of the complete “Character Spec” document.
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.
Let’s talk about high vs low granularity in game design, which has always been one of my favorite topics. From Wikipedia: “Granularity refers to the extent to which a material or system is composed of distinguishable pieces”.
In the context of game design, many things can be either high or low granularity, such as:
Let’s talk about a problem that plagues live service games.
If your game relies on releasing MORE content in pre-existing categories –
characters in League of Legends or Overwatch, exotics in Destiny, new cards in Magic: The Gathering – then there are
two fundamental design problems you need to solve:
– Diminishing Returns: How do you make content that is as exciting on the Nth update as it was on the first update? How can your 50th piece of content compete with all 49 previous pieces?
– Narrowing Design Space: How do you leave room for each new thing to feel unique and different over time?
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: