World of Warcraft quest log
Hi there, in this section of my website I wanted to show some example design work I have done. This will largely focus on design documentation or work that isn’t seen publicly but is vital to making a game with other people.
To be clear this is not work done for past employers or games I have worked on, but rather examples of the kind of work I deliver.
I find myself to be strongest as a Systems Designer so much of this work will be related to a game’s systems. Systems Design is also a very broad topic that is often broken down into smaller disciplines depending the size of your team. Some common examples include:
Character Progression
Enemy/Encounter Design
Combat Design
Game Economy
Monetization
Systems Design work is also often filled with spreadsheet and documentation and often can be hard to see in the final game. For these reasons I felt it is valuable to show this work to you.
Encounter Design
In this page I wanted to show an example of what my Encounter Design Documentation looks like.
Here I was asked to:
Identify rules for creating new monster families.
Design a monster family and 3 of it’s family members.
Create an encounter using the created monster family.
Break down the design of a boss fight from another game.
How I would change the boss fight by changing a single ability.
Below in the large image is the full document and below that there is a quick overview of each page if you want more detail. It is worth mentioning that these are built so that you shouldn’t need extra info, but I figured it wouldn’t hurt to provide some here.
Part 1 is a simple overview of what rules each monster family should follow. This is the biggest part of what makes them a family. This doesn’t mean that members of a family can’t be used along side another family in fact they could work very well with together and at times might even be mixed and matched together for an encounter.
Rule 1 is about sticking to a theme this is important for a family’s identity and the player’s understanding of how a family member might behave.
Rule 2 is how that family behaves as a unit. A family that doesn’t work together is no different than randomly mixing members of different families together, and changing how they look.
Rule 3 address how they look. A monster family should all look like they belong together. You can still have differences between them such as tall skinny ones, and large fat ones, but they should convey their role in the family while also looking similar enough for the player to recognize them as a unit that is working together.
Part 2 is an overview of the monster family. This is the overall behavior of the family along with major themes and what mechanics tie them together without going into detail about individual members on this page. Individual family members are each covered in their own page below.
At the top you see the Design Philosophy and Themes sections. This is an overview how the family acts and what they do differently than others, along with creating a sense of what is important for them to be successful.
On the left in boxes there is a breakdown of the families primary mechanic(s) that all members of the family will revolve around.
While the bulk of the page provide references and an example to illustrate the concept. Our goal is to avoid confusion with a clear example to followed/test.
Lastly I cover some Concerns and Potential Solutions this is important because it forces us to think about what might go wrong and think about how I would address those issues.
Part 2.2 - 2.4 covers each individual enemy. On the top left of each enemy card I go over the Philosophy and Goals for this particular family member. With the top right being a quick narrative blurb to better reinforce the theme.
On the left I again have a mechanical breakdown of how they behave inside of the family as well as in different states that make up the AI’s behavior.
On the right I show an image of the enemy along with a stats overview. I don’t worry about being exact here, but again to get a feel for what they should be.
Below I include any notes that might not be clear in the mechanics or anything else that I feel is important.
On enemy enemy I also cover any major Concerns and Potential Solutions here as each family member has their own issues to tackle.
Part 3 is about showing how they work in an encounter setting. This is an example of how they they work in action. This should showcase their intended strengths and weaknesses.
At the top I go over the Design Philosophy and Goals for the encounter, along with a brief overview of what the encounter is. I have gone over how each monster works in their own pages above so this should provide an illustration of how they work in practice.
On the left I call out some examples of what can happen in the encounter that are shown in the image.
On the right I go over the encounter mechanics in a bit more detail, such as reward structure or difficulty ramping.
I also cover the Concerns and Potential Solutions for the encounter. This forces me to evaluate my own design and either change the design or be ready to make changes if problems come up.
Part 4 is a breakdown of boss fight from another game. In this case I am looking at the Ashava fight from the upcoming Diablo IV and was shown at Blizzcon.
On the left I start with a short overview of the assumed the goals/philosophies used when creating this encounter.
In the center I break down each attack that the boss uses.
The attack’s name.
A short description of the attack.
What the attack pattern or hit box looks like.
Important stats or important effects.
The attack’s role in the fight, such as the intended player reaction or why this attack exists and how it fits into the encounter as a whole.
Part 5 is about changing that fight broken down in Part 4. It goes over any changes that are important and allows us to digs deeper into the fight.
Again I start with Philosophy and Goals so that there is a clear starting point.
What attack I would remove and why. In this case I choose an ability that I felt wasn’t teaching players as much as other skills, but you might also make changes for a number of reasons often this is due to: complexity, technical limits, theme, clarity, or the removed/changed attack is a better fit in another fight.
What was added, along with an overview of how it works.
Why this attack is a better fit, and what it does that was not being done before.
The same attack overview used in Part 4 to be used for comparison and to show it’s fit into the encounter as a whole.
Lastly I again cover Concerns and Potential Solutions and address them.