We’re crunching hard on Archmage Rises to get all our monsters in for the pre-order release date of August 4th. It’s been more than two years of development -- and now with just 12 short weeks to go, the pressure is on. Frankly, I need a break. So I’m going to share our monster creation process and tell my wife I’m still working :)
Combat in Archmage Rises is first-person, tactical, and turn-based. A thoughtful approach to combat mimics the tabletop RPGs that inspired the game. One of our design principles is
Every battle should feel like a boss fight.
What I mean by this: If the player is fighting a pack of goblins, it should involve as much tactical strategy (with as much life or death tension) as the boss battles traditionally seen in RPGs. A green punching bag with a short sword won’t cut it.
We started the monster creation process by first thinking about geography. Where do the creatures live? Since the map and encounters are procedurally-generated, this is the only way we conceive them. That led to thinking less in terms of individual monsters and more in terms of races: This race is commonly found HERE; that race lives THERE.
Splitting off and thinking about monsters by race allowed us to design a shared set of racial properties to make them all feel like they fit together -- and at the same time, helped each creature stand out within its race. For purposes of this discussion, I’ll focus in on the goblins.
I recently read Evan Skolnick's book on Video Game Storytelling. I found it interesting that even minor characters are the heroes of their own stories. In LOTR, Samwise Gamgee is Frodo’s friend who assists him on his adventure -- but in the Story of Sam, it is Sam who is the hero. He was about to get married to the shire beauty queen -- only to discover his foolish friend accidentally ended up with a ring of ultimate evil. His friend is too helpless to get rid of it on his own, so Sam gallantly puts his personal goals on hold and helps his friend on a hopeless quest.
In Archmage Rises, every monster is the hero of their own story.
Fortunately, I’m not the first person faced with designing this stuff. D&D has been teaching the average person how to create monsters and battles for decades. The D&D™ 4th Edition Dungeon Master Guide has a handy shorthand for defining the role a monster should play within combat. Here is my quick summary:
Artillery: Excel at ranged combat, attack at a distance, hang back, more fragile.
Brute: Damage dealers, low defense, high hitpoints, slower but do massive damage. Don’t move around much, just deal out the pain -- like an elephant or a linebacker.
Controller: Manipulate opponent or battlefield to advantage -- or assist allies with buffs/heals. Alter conditions, like casters.
Lurker: Some ability that lets them avoid attacks, like hiding or turning invulnerable; concentrate on defense and then make one big blow every few rounds.
Minion: Fast, light, numerous, cannon fodder -- like the little guys in Halo.
Skirmisher: Use mobility to threaten, dart in and out of combat, don’t stay in one place.
Soldier: Hold down the player; average defense and attack; protectors of the other.
What do those seven types sound like? A well balanced pen & paper adventuring party or a raiding party in an MMO! So monsters are really the heroes of their own stories -- off to seek adventure -- and the pesky player gets in the way to stop all their looting fun!
Armed with a race concept for the Goblins, it was time to design the individual monsters.
We picked the roles we felt best fit in with the race concept. Goblins would be encountered frequently, so we felt were worthy of an expanded roster. We concluded goblins should have all the roles except skirmisher. And they should have two different types of controllers. Now we now had seven goblins to design. But not a clean sheet, fortunately! With a specific role as a starting point, the direction of the character was defined from the get-go.
Next, what I think really helped us was:
A) Separating the design of the player spells & abilities and the monster abilities by several weeks
B) Separating the designer from the implementer
Splitting apart player and monster design prevented tit-for-tat design -- where this creature is an obvious target for Fireball, or this ability is specifically to foil Tornado. I’m ashamed to admit this (so let’s just keep it between you and me), but it had been a few weeks since I worked on the player spells and abilities -- and I couldn’t remember their specifics. I think this resulted in a more nuanced Monster-centric design instead of vanilla player-centric punching bag design.
The second is the separation of designer from coder. I’ve learned at my software company never to let programmers write the Specification. If they do, we will have a document that is short and easy to code -- but it won’t solve all (or even any!) of the business problems.
The design/code separation allows me to focus purely on the task of designing cool monster attacks without worrying about how to implement it within the codebase. I’ll confess something else just between us: I’m pretty lazy. If there is an easy road to take, I’ll probably take it. If I was to design something in the morning to code in the afternoon, I would end up making something that was easy to implement but probably not very original in design. Separating design/code allowed me to make decisions based on a solid vision of the monster instead of worried about current limitations in the codebase.
If you are a solo indie and cannot separate design and coding by people, you can at least do it by time. I have found that designing something early in the week to code later in the week is enough time separation to get the best out of me in both. Many a time, I’ve been programming from my design document and thinking, ‘Who the hell wrote this?!?’ If you’re thinking that, you’ve done a good job of separating the tasks.
Note: I’m not advocating wild design, where there is no consideration for implementation. I’ve been a coder for 20 years, so I intuitively know “that’s easy to do” or “that’ll be hard.” By separating the design from implementation, I can think, ‘That’ll be hard… for someone else!’ -- and that makes all the difference :)
Check out monster concept artist Nicholas Cloister over at Carried by Creatures. He paints a new totally original creature (like above), with stat blocks, background, and behavior, on his paetron page every few weeks. You can even license (non-exclusive) the creature for your game for a very reasonable cost.
I had already designed a Controller caster type for the goblins, and now I had to design another one. How can I make it unique and different from the Vexer’s caster role?
An intelligent caster goblin, able to use rudimentary magic for foul results.
This can be tackled in many different ways: I started with the name. I toyed around with different words and somehow ended up with the term “Moonhowler.” That inspired me. It made me think of a crazy person. (The term lunatic comes from the Latin root for moon: luna.) That led me to write this:
Tattooed and slightly mad, these goblin chanters cause fear in their enemies while rallying their allies.
With a name and description, I focused on creating abilities within that theme:
Moonsong +1 actions to all goblins for one turn, +4 hp to all goblins
Moonhowl +20% Fear to player miscast
Moonmirror adds +100% dodge to ally until attacked
Moonbeam 3-6 damage
Without knowing Archmage Rises combat system, it may not be clear that these abilities make this guy friggin annoying! I don’t want to fight him! And that makes me think we’re on the right path...
I posted the task to the Asana project management site armed with the name, one-line description, and abilities -- and assigned it to Rogier the artist.
Fortunately, Rogier is a veteran monster/character artist who has been doing a lot of work with Paizo Pathfinder recently. A few days later he posted this back:
I wasn’t feeling it from this first sketch. But what I did like was the musician angle. As a longtime Warhammer Fantasy player, I liked the idea of a musician encouraging the troops from behind. I gave him some feedback that he didn’t look crazy enough and to take this new musician angle further.
As an aside, the sign of a good team member is someone who can take your ideas and make them better. Many solo developers miss out on this aspect. Before I had a team, I would buddy up with another solo dev -- and we’d use each other as sounding boards. This is very effective.
And so Rogier made him more of a crazy musician:
Now the Moonhowler’s personality is shining right through!
After sketch approval, Rogier painted him up:
... and this is how we got a totally unique goblin caster/controller monster into Archmage Rises!
We’re still balancing his stat block as we are pre-Alpha. To get a starting point we answered these questions:
Right now he is 1.5x times maximum player damage, so in general he can last two rounds, unless the player uses a sneaky combo or rolls a critical to get rid of him in one.
Hope this helps!
If you would like to see more about how we are rethinking the RPG head on over to Archmage Rises.