Dev blog 83 - Making New Enemies

This post is written by Mat, our gameplay designer.

Hello guys and gals! Today I wanted to share with you a bit about how we go about adding new stuff to the game, particularly content.

The Hand of Merlin is what I like to describe as a “rectangular” game, meaning it is validated not by its systems, but by its content. A roundabout way of saying that the game is fun or not depending on what you face, discover, and do in the game.

That means that we have to take extra care in creating cool encounters, enemies and skills for you to use and recombine, and the processes we use to go about creating said content needs to be constantly revised.

In the context of enemies and skills, its a three-stage process.

We identify a fantasy or a niche. This is the verbal stage. It’s usually down to a sentence or two. In the early stages of the game, they were mostly aesthetic, like “Bashing someone with a shield sounds fun” or “I had this image of a big, beetle-like monster”, which would evolve into Bash and Behemoth respectively. Nowadays, so close to full release, we tend to find more mechanical or thematic niches to fill, like “The Warrior could use some self-heals” and “So many enemies punish the melee characters, how about we do the reverse?” turning into Malice and the upcoming Basilisk.
Then, we Systematize - my personal favorite! We have to translate the idea into actual game terms. What does it mean to push someone with a shield? How is it different from a basic attack? Why would you pick it? This stage is still theoretical, but we have to start thinking about how to implement it in-game, often checking with MarkoP to see what’s possible, or making some small tests in-editor. A great example is how Thorntoad’s Bristleback passive went from a desire to “dissuade the player from focusing fire”, into a process: whenever he is hit, he’ll deal melee damage and become more resilient to damage, via the addition of another status effect, Thick Skin.
As a side note, Relics can often start in this step. Whenever we are doing a new skill or fix, we “discover” a possibility in the design and come up with a relic’s functionality first, before finding a fantasy/historical element to it.
Then, we Implement. For most skills and enemies, we could give the artists and programmers a heads-up in advance, so by the time the design team reaches this stage, we have the assets ready to slot in and see them in-engine. We can find out some impossibilities in current technologies, or discover some inconsistencies with our plans: that’s normal, we just go back a step and try again. After a bit, we have something testable. For the Basilisk, we actually were lucky enough to be able to use some pieces of other enemies, like Mandrake’s movement AI and some lessons we learned from Wilfred’s Nonchalant passive, and the implementation was quite quick.
Then, Internal playtest! Up until this point, the skill or enemy was built in a vacuum, with theories and desires alone. We thought it would be a neat idea if, say, Redcap’s Ooze, that ground effect he leaves, actually could heal other abominations. But once you actually see it happening in live play, with 2 Redcaps and a Mandrake, you notice that it doesn’t make a lot of sense. It’s not properly explained, the player’s can’t do a lot about it, and Ooze is already a hassle on its own… Often, the ideas are scrapped or retooled.

In this stage, it’s very important to bring other members of the development team into the loop, since the people that developed the idea from concept to implementation can become numb to its issues, or only see the results from a specific angle. I often gloss over poor descriptions or AI mistakes in the content I implement myself, and have to be reminded by my fellow devs, simply because I’ve been seeing the thing for so many hours that the small details don’t strike me as odd anymore. This is a great piece of advice to any designer: Designing something in a vacuum is dangerous! Get someone else to see and approve your deliverables.
Then we can move on to Iterating. Very rarely do we actually see a piece of content go from concept to seeing live play without at least one touch-up. As an example, an early implementation of Redcap had passive Evasion, meaning that no matter what you did, there was always a 10% chance that you’d miss it. When I designed it, it made perfect sense: The players have it, and it’s good that you build redundancy in your plans, to account for the randomness factor. But other devs played it and found it frustrating! So we iterated: maybe the Gaze ability could introduce the same randomness and require the same redundancy, but in a more straightforward way, that the players can play for. Maybe we can make another enemy gain evasion only if you attack them, like Wyvern turned out to be. We re-systematize, re-implement, retest… until we find it acceptable.
Then you come in. Live feedback is the greatest (and most overwhelming) thing to happen to our game dev process! We show our content piece to you, the players, and see what you think. Sometimes you think that “The boss fight is a bit meh”, or that “A specific map in Zone 2 is the worst”, or, in a brighter light, that “cooldown reduction makes you feel powerful” and “dealing direct health damage is cool”. We take that into consideration, try to account for it, and fix whatever bugs and errors you (or our extended QA team) find out. This step can happen over and over and is still ongoing for many aspects of the game, but it's one of the most important ones too, as it makes the game a better product for you!

So there you have it! The process of how we add content. Now that you know how important your voice is in our development process, be sure to show up on our Discord server to share your feedback with how the game is turning out, so we can keep improving it!

Mat