In the article Keys to Rational Enemy Design, we broke down several approaches to enemy design: where to start, how to identify what your game may be lacking, how to create enemies that hold a meaningful place in your players’ experience…

As a reminder, here are my 5 main reasons justifying having an enemy in a game, from a Game Design point of view:

  • Do I have players’ abilities I want to emphasize?
  • Are there specific players’ skills I want to challenge?
  • Do I need more diversity?
  • Are there players’ behaviors I want to encourage or discourage?
  • What specific players’ emotions do I want to trigger?

Now, between the moment you have the right approach for a new enemy and the moment you have it in the game, there is an enormous gap to fill. And starting to develop it can be daunting. I had more than once the good ol’ Writer’s Block when having to start the design of an enemy, knowing that I only had a short time to produce a full Game Design Document (or GDD) and not the start of an idea for this enemy.

In a game like Assassin’s Creed, the GDD of an enemy is easily 30+ pages long and contains an exhaustive bunch of information:

  • Out-of-combat behavior.
  • In-combat behavior.
  • A precise list of all its attacks and abilities.
  • A full-fledged decision tree: phasing, extreme behaviors (target unreachable, lost line of sight, emergency tracks, etc.)
  • The Signs & Feedback table for this enemy, laying the work for 7 job families to take over.
  • All the metrics of this enemy, for every single one of its actions, attacks, abilities, and reactions: movement speed, attack speed, anticipations, damages, health, anticipations, recoveries, displacements, etc.
  • Visual references: weapons, models, tone…
  • Combat references: combat techniques, special moves, weapon’s specific approach.
  • Full details of the 3D model and other assets required to produce
  • Narrative justification of the enemy.
  • Group behavior
  • The precise detail of new behavior or abilities requiring GPP work
  • Etc.

And let’s face it, this won’t be done over an afternoon with a coffee and good music. It’s a long and iterative process, one that needs to happen through a careful process and baby steps. But then where to start? Well, I personally would build a one-pager.

Enemy One-Pager

This document is the one I ask my Game Designers to produce first when starting a new enemy. It is the first one that will be officially validated by the Game Director and the first document the entire team will see. It crystallizes the core of the enemy, and its place in the experience, and allows a production team to start projecting towards the work it will require to make it happen.

This one-pager is so important to me that I really wanted to give you a template to use on your own games. A one-pager structure needs to be adapted to each game, but the core of it is valid whatever game you work on. In this article, I’ll run you through every part of this template and show you how to use it. Then you can break it apart to fit your needs.

Here is how this template looks applied to Tutankhamun, the final boss of Assassin’s Creed: Origin DLC The Curse of the Pharaohs (the original one-pager is extremely similar, with only a few IP-centric extras):

Tutankhamun boss one-pager

The goal of this document is multiple:

  • Give all key information about this enemy.
  • Answer all critical questions on the Design side.
  • Offer, at a glance, an overview of the enemy’s particularities and unicity.
  • And most importantly: it allows comparing this enemy with the entirety of your enemy’s roster.

When your game contains a wide range of enemies, it becomes increasingly difficult to assess the unicity of an enemy, where it should sit in the game’s experience, and if the entire range of possibilities the game’s systems offer has been considered. By creating a one-pager based on the same template, for each of your enemies, you will be able to navigate between their designs and quickly flag duplicates or missing links.

Pro-tip: Every time you secure a one-pager, print-it and tape it on a wall. You will find yourself going back to it over and over again, and it will anchor the enemy’s design through its development.

Before we head to the details of this one-pager, I invite you to download the template below: I made it into a handy .pptx.

Click to download (do not use Google Drive, it doesn’t like fonts much)

The anatomy of the One-Pager

Should you have opened the template by now, you are probably thinking that this is pretty straightforward. And, in many ways, it is! The goal of such a document isn’t to burden you with extra steps but to make you win precious iteration time and focus on your design process. That being said, there are quite some subtleties to be careful of when filling it.

One important thing about this document first: The part above the red line focuses on the enemy specifics while the part below focuses on the player facing this enemy (remember: an enemy only exists because of the player fighting it).

Empty template

Experience role

I added this part to my last projects and found it extremely useful. This is the extreme core of your enemy, the few words that will make everybody say “Oh yeah, this guy!”. You can see it as a stripped-to-the-bones elevator pitch.

It may sound silly, but these catchphrases give a soul to your enemy! To write them up, I imagine my enemy entering the stage on a WWE match and the commentators screaming their introduction:

  • “[enemy name], THE THIRD ROPE ASSASSIN!”
  • “[enemy name], THE FLYING STRIKER!”
  • “[enemy name], THE BACKSTABBER!”

You can project an entire fantasy through these few words. Try it, go wild!

Side note: wrestlers are a lesson in archetype building, introduction, and evolution. These guys mastered their unicity.

Illustration

Do not wait to have the final 3D model or even a clean concept art to illustrate this one-pager: a fitting reference or a dirty overpaint would do great as you only need to convey the idea of this future enemy (you will have plenty of time to polish it for your future talk at the GDC ;))

Elevator pitch

Writing a good elevator pitch is an art in itself that I can’t pretend to master. Try to stick to the 3 lines given by the template, remove any unnecessary words, and highlight every key-defining part of it.

Key attacks/abilities/specificities

I only left some space for 5 lines for a specific purpose. On one side it forces us to focus only on the defining traits of the enemy (the GDD will take care of the details). On the other hand, it doesn’t allow us to go overboard, removing the risk of creating a jack of all trades that will never find its identity.

The “SHMAR”

It is critically important for me to be able to visualize, and visually compare, the key metrics of my enemies. The ones I use here, strength, health, movement speed, attack speed, and reach, are fairly common and usually of importance in most combat-oriented games. Feel free to replace them with more meaningful metrics if your game is different (reload speed, target acquisition speed, etc.).

What is interesting here, is that even though they represent quantifiable metrics, I do not put any numbers there, and even decide on the size of these bars approximately. The importance here is to define orders of magnitudes: you will then be able to see things like “roughly, these 5 enemies attack with the same frequency, is it an issue?”, or “I never considered an enemy with barely any life, or reach, could it be an interesting opportunity?”.

Expected player strategies

This part is kind of a controversial one… Many would slash me for trying to impose a particular way of playing the game on the player. And indeed, the sense of agency, self-expression, and appropriation of a player is paramount.

But by trying to define the “Right Strategy” for players to defeat that enemy, I realized that we streamline the design in a very pure direction. It gives a unique tint to the enemy and helps shape its details (before playtests shoot our plans mid-flight as real players destroy our plans and we need to iterate on the design to keep sticking to this one-pager).

Player’s skills, abilities, behaviors, and emotions

This part directly refers to the previous article: Keys to Rational Enemy Design. Try and fill all 5 categories: the more you define them here, the easier your work will be later.

Perceived vs. real difficulty

Finally, this distinction is actually a neat little trick I learned working with the folks at Ubisoft Montreal. This concept will tap directly into the concept of Flow: By having a perceived difficulty higher than the real difficulty, you make your players feel empowered and in control (for example by slightly tweaking the enemy hitboxes so that the player feels like he is on a dodging perfection moment). By having it the other way around, you will create frustration and a WTF moment as your players get murdered by a bunny (which could be the desired outcome).

Plenty of games slightly tune the real difficulty lower than the perceived one: reducing hitboxes, expanding hurtboxes, waiting for a few extra frames before registering a hit to let the player finish his dodge, considering the player in a “blocking” state even though his shield raising animation was barely starting and the enemy’s sword wasn’t connecting… Generosity in gameplay can go a long way.

And here we are. My dead simple and yet very powerful enemy one-pager. Let me know in the comments or on Discord what you think about it, or how you would modify it!

Important: should you use this tool on one of your games (or make other versions of it), feel free to send them to me, I’d love to include them in this article!

Did you enjoy this article? If so, please consider supporting GDKeys on Patreon. It helps keep this place free of ads and paywalls, ensures we can keep delivering high-quality content, and gives you access to our private Discord where designers worldwide gather to discuss design and help each other on their projects.