Toughening up Minions
There are various schools of thought about minions... Some people like them, some people hate them. Some use them to balance out an encounter, some will throw legions of them at a level one party just because they can.
In several of the starting encounters of my campaign, I use minions a lot. But I used them to give the story some scope, to show that you are facing something seriously evil with an absurdly large disposable army under its control. To the players they were never meant to be a threat, but rather they were an annoyance.
At first I thought a handful was enough; sending a fleet of minions at the party seemed like overkill. That was until one character in my campaign literally bowled over five of them in the first round, before any other creature even acted. By the time the monsters would have gotten to their spot in the initiative order, the room was empty.
So rather than just throw more minions at them (which would arguably unbalance the encounter) I decided to try something, and came up with the concept of a "tough" minion.
Here are the rules I put together:
- Creature starts with 10 hit points in the Heroic tier, 20 hit points in the Paragon tier and 30 hit points in the Epic tier. This is just enough hit points to be somewhat resistant to secondary attacks (for example, a monk will not be able to kill it with Stone Fist Flurry of Blows) and can even sustain attacks from other minions (in my encounter there were also ally minions), but most PCs could still knock them out in a single solid blow. And if the PC has a weak damage roll it might still be standing, which does make some sense if you think about it.
- Creature *does* take damage from a missed attack, but can never die from it. If the miss drops it to 0 hit points or lower, it stays alive with 1 hit point remaining.
- Creature has no healing surges of its own and cannot be healed in any way. It can benefit from temporary hit points, but it cannot recover from traditional damage.
- Creature can have vulnerabilities and resistances, similar to what a normal monster would have. For example, a Tough Decrepit Skeleton would have radiant vulnerability.
- Any damage the creature takes, even if it's a single hit point of damage, qualifies it as "bloodied". So it would be vulnerable to powers and feats such as Impending Victory.
- A critical hit on an attack roll kills it instantly, even if the attack doesn't normally cause damage. For example, if an Invoker critical hits it with Whispers of Defeat, it dies
- OPTIONAL: Double their XP value if you think they caused the players more trouble than they should have.
- OPTIONAL: Have the minion die automatically after two direct hits, also if you think they were more trouble than they should have been.
When the party faced the same amount of these "tough" minions, it was actually a little bit of a challenge, and weren't quite the cannon fodder they were originally designed to be. And they weren't much a threat to the party anyway, but they did go down swinging.
This also has an added benefit: you might be able to get away with making the players think they're not minions in the first round. If a player lands a weak blow and it's still standing, they might suddenly think that there's a serious threat and will begin to start burning off important resources.
There are a lot more minions to play with in my campaign... I'm going to continue using this idea and see how it works in the long run.
Hazard: Fleeing Rats
DISCLAIMER: I'm going to be talking about a movie that's over 20 years old. Don't start screaming about spoilers.
A while back, while I was in one of my design sessions, I found myself watching Indiana Jones and the Last Crusade for the umpteenth time (why? Because it was on TV! Duh!). On or about the same time I was trying to think of something to put in a tomb, the scene under the church started. You know, the one where Indy and Elsa (to avoid calling her "the hot chick", I actually had to look her name up) are plodding through a sewer filled with rats.
When they reach the resting place of the knight, the creepy guy from the Brotherhood that's following him lights a match and drops it in to the river of oil. The next scene shows what can only be described as a wave of squealing rats trying to escape the oncoming flames.
Suddenly it struck me: if you're happily walking through a narrow corridor when a horde of a million tiny rats begins to barrel towards you, what would you do?
Run away!!!
I know there is a "Rat Swarm" monster, but that's not quite the same thing. The rat swarm in the Monster Manual is an actual monster and is handled as such: it occupies a specific square, attacks a single target, takes damage until it dies, etc... It arguably has intelligence. That's not what I'm thinking. I'm thinking of the "yelling 'fire' in a crowded theater" sort of mindless panic where tiny, otherwise harmless rats freak out and run in unison without thinking of anything besides "FIRE BAD!". A sea of endless rats small enough that they easily pass through the player's space but individually not big enough to be attacked directly.
And standing anywhere in their path is probably not a good idea.
And thus the "Fleeing Rats" hazard was born...
Now the wave isn't "endless" in the literal sense (although, with magic, anything's possible) so it has a certain size: it has fixed dimensions - a 2x10 grid of contiguous squares - that moves like a snake, in a straight line away from something bad towards something... less bad.
Think of the possibilities this allows:
- The party's pyromaniac can take great pleasure in immolating several thousand rats. You, as DM, can then figure out how to amend the hazard to handle what a swarm of rats on fire would be like...
- The party should be able to see the rats before they arrive, but if you're a particularly evil DM you can treat the swarm's arrival like a surprise round.
- This could be a perfect lead in for something that the players should be afraid of: whatever spooked the rats in the first place.
- Deep down inside, every adventurer wants to be Indiana Jones. They're just afraid to admit it in mixed company.
I'll also point out that this trap will not only work outdoors as well, but it doesn't have to be rats. Spiders, ants, squirrels... Pretty much any small creature that runs on all fours and isn't too bright will work.
So how would you change this?
ADDENDUM: I know I warned you about spoilers, but I don't think I actually included one.
So here ya go... Ready?
...
Indy's father is Keyser Soze.
WotC’s Online Tools: Flawed Design
When it comes to the relatively new "online" character builder by Wizards of the Coast, there just doesn't seem to be a middle ground: you either love it or you loathe it.
But the two major complaints seem to be (1) "why the heck did they choose Silverlight?" and (2) "why do I have to be online?"
As a gamer, I'm not all that thrilled about this new direction they are taking with all their online tools, but as a programmer it makes absolute sense. Let me,as a programmer, address the two questions:
1) Why Silverlight?
From a programmer's perspective, Silverlight is what Flash should have been. It's phenomenally easy to develop applications in it, and it's not all that different than writing a normal Windows Forms application in .NET. And it has a lot of functionality built in right out of the box that Flash simply doesn't have, like easy to use client/server communication. It's a robust framework that will allow you to do most anything.
Also, you have to consider the development environment: there really is no comparison between trying to use Adobe Flash CS5 and Microsoft Visual Studio 2010. With Visual Studio you can design, develop and debug in ways CS5 can only dream of. I spent an hour trying to create code for a Flash app in CS5... After about an hour I wanted to punish the developers (and I actually know some of them personally at Adobe).
A lot of people are complaining that the Character Builder application is bloated and slow because of Silverlight. It's not Silverlight's fault. We'll get to that later...
One last thing: the original CB was written in .NET as well. They didn't have to reinvent the wheel or fire their entire programming group; they continued to work in the environment they were familiar with, the only difference now being how the application was deployed (web versus download).
2) Why online only?
This is the one that, as a gamer, I'm really not thrilled about. But an online application is significantly easier to maintain than an offline one: if you make any changes in an offline app, you have to push it to all the clients as an update. In a typical "programming shop", this means that the updates need to be rolled through a chain of events sometimes known as a build cycle, which includes among other things internal testing (some people call that "validation"). Because of the need to create builds with specific versions, and generate the necessary install packs for those updates, the updates happen infrequently.
On the web, you can arguably make that change transparently, at any time. And, in cases where it's a direct database change, you don't need to worry about updating the binaries at all. All the data's live.
That's assuming that the data comes from the database. Again, we'll get to that in a bit...
So why does it feel "bloated"? Why is it so slow?
First of all, many people don't realize exactly what is required of the Character Builder. It has to know EVERYTHING about character design. It has to know about every single class, race, background, power, feat and piece of equipment available. And any single selection could impact everything else. The amount of data it has to be aware of is astronomical.
But where is that data? Here's where the design fails, in my opinion... Everything the CB needs - the collected knowledge of everything needed to create a character - is contained in one massive XML file that is part of the Silverlight binaries (it's embedded in one of the class libraries as an "Embedded Resource"). So, when you first go to the CB web page and watch it slowly count to 100%, that's what it's dealing with: it has to download that huge file, decompress it and then parse it in to manageable pieces.
This, to me, is somewhat of a design flaw.
First of all, XML is not a "native" format; it has to be parsed every time you need to get something from it. To optimize that, you convert it to binary through serialization, but then why not save it as binary objects in the first place? XML is also raw text, and it's big and unwieldy. Sure it compresses really well, but it's impractical to use in a high end application.
Secondly, does it really need everything? Let's say you're building a 1st level Cleric. The CB has, in memory, *every* power and feat for *every* class. So, while building your Cleric and choosing from about a dozen or so powers, the Character Builder has loaded in memory 7511 Powers, 3045 Feats and 8934 Magic Items.You don't want any rituals? Sorry, I'll load the 314 Ritual entries anyway. Don't want to pick a background? Sorry, I'll keep these 742 Background entries in memory just in case you change your mind. Oh, and I'll keep in mind all 8900+ magic items (up to level 30) just in case... You never know what you might find in a level 1 dungeon crawl...
Whenever you click on anything, it has to plow through all that data. When you want to decide which of the 17 Cleric Level 1 at-wills you want, it first has to plow through 7500+ power entries to get the list of the ones you can choose.
For some things, it might be unavoidable to have all that data, but it should be optional. If I hit the "Background" button, I'd be OK with the system trying to retrieve the data right then and there, in the same manner the Compendium does. If I don't care about a background, there's no reason for me to load that data. If I'm building a Cleric, why do I need to have every power of every class in memory? There are exceptions of course, such as Dilettante, but the system could account for that easily.
All the above issues exist in the current Character Builder, and I kind of wrote it off as an error in judgment. But now I see they're doing the same thing with the Monster Builder... the "beta" of the CB contains ALL the monsters in an XML file that's part of the binary. Don't care to have over 4200 monsters floating around in memory? Too bad.
Mentioning all the above probably won't change anything; I don't see them rewriting the entire CB to use this design ethic. But at least now you can criticize their style of programming rather than their motives or intentions.
In the meantime, I'll keep voicing my design criticisms like the programmer that I am.
Introduction
What better way to start a new blog than to introduce myself.
My name is David "Nighthawk" Flor and I am technically a game designer. I use the term "technically" because I haven't actually done it professionally... That is, nobody has actually paid me to design a game (yet), but you can't blame me for trying.
What I *am* professionally is a software developer, and have been programming for close to 30 years. During that time, as a hobby of sorts, I have done video game design (created "The Opera", an add-on to Half-Life) and alternate reality game design (founder of Darklight Interactive, designed and ran Looking Glass Laboratories), and am now venturing in the strange new world that is campaign design within the Dungeons and Dragons 4e ruleset.
What possessed me to do that, you wonder? For the past two years I've been designing an alternate reality game called Rachel's Walk. It's a massively complex and intricate world, containing people and places both in the real world and in an imaginary game space powered by something I call the "Dream Engine". I admit that my design is a little... how should I say... ambitious. But it was a great idea on paper anyway.
At the same time I was developing the backstory to this campaign, several friends introduced me to the D&D 4e ruleset. Now I'd played D&D before, going all the way back to the first edition, but this new rule set was quite intriguing. It was then I realized something: the backstory I was creating for Rachel's Walk would probably make a really cool campaign.
And so it began. Over the span of several months I created a campaign that spanned nine chapters, taking a party of five from level 1 all the way to level 10. A whole new continent, a band of NPCs, new monsters, new traps, new items... I admit I really got in to it, designing some areas with intricate detail even though the players might never see them. And I found myself drawing some pretty impressive maps, which is quite an achievement for a computer programmer who couldn't draw a square at gunpoint a year ago.
Since then I have launched the campaign on two forums, one of which is the Wizards of the Coast Real Adventures group, in the hopes that it can be playtested. Since my background is video game and alternate reality game design, some of my horribly intricate ideas did not translate to a D&D campaign very well, so I needed players in order to refine the mechanics of it. It was essentially a "beta", and during these controlled trials in which my players went through the paces I began to realize that players are quite a creative bunch. They tried things that I didn't expect, asked questions on story elements I hadn't even considered. They made the design better, and because of their input quite a few things have changed since it was first conceptualized.
So here we are. With the assistance of my players, I have decided to put together this campaign in a module format (whether I sell it or not is still up in the air). And I thought I might as well share some of the design considerations that went in to it with you.
But there's more... While running the campaign, I realized that managing a 4e campaign is HARD. There's so many details that the DM needs to keep track of - hit points, bonuses, detrimental effects, encounter powers, surges, treasure, even things like interactions with NPCs - that it's easy to lose one's mind. So I did what any programmer would do: I began to create a suite of applications - both offline and online - that will assist me in the execution of the campaign. This includes linkable online die rollers (a concept I didn't even know existed until I saw its use on the WotC forums), map generators, image hosting services, encounter managers and more. I realized that these tools should be available to everyone, not just little old me. So you'll see me mention them a lot, with the ultimate goal of making them available to the masses.
This blog will not reveal "spoilers" from the existing campaign; I'll try not to do that as best I can because I do want my playtesters to be able to read this blog without having it spoil their future.
I hope you stick around.
About the Author
Software developer and game designer in Miami, Florida. Currently working on content for Dungeons and Dragons 5th Edition, Pathfinder, 13th Age and other systems.
Links
Recent Posts
- In Response to Threat of Arrest
- Everything Is Better With Tentacles – Planning
- We Have Switched Hosts!
- Hey, GenCon People… Please Read This
- Atomic Age – Dice Mechanic