A Walk in the Dark A look in to the mind of an RPG designer


The 11th Skeleton

With the release of the Dungeons and Dragons 5th Edition Starter Kit and Player's Handbook, I have decided to convert my long languishing adventure "The Coming Dark" to 5E. But, unlike other publishers who will remain nameless, I am not going to rush it out there, and no one's going to see a thing about it until (1) the licensing options are given, and (2) the Dungeon Master's Guide is released.

That being said, I have started to try and figure out how 5th Edition works in terms of creating adventures. In 4E, creating balanced encounters was rather simple because everything was equally balanced - given an equal level, five monsters were an even match to five PCs - but that's not exactly the case any more. Now it's more like 3.5E and earlier versions, where a monster's difficulty is reflected in an obscure "Challenge Level" which is extremely hard to calculate. I mean, after you stat up a monster how do you know what CR Challenge Level to give it?

That led me to wonder about balance in general, specifically how balance is determined. 5th Edition had an unprecedented amount of playtesters, so they had access to a variety of groups that could test and retest things in the hopes that they could determine what is balanced and what is unbalanced. But there's an inherent problem with that: not every group is the same, and not every player is the same. If an exploit exists, it will take a small handful of "high end" players to find it... so if something is taken advantage of by so few, is it really a balance issue? Can the game be unbalanced by something you're not even aware of?

So I thought about how some things could be experimented with... and the programmer in me realized that this is no different than load testing an application. When you do that, you don't run it a few times and see what happens. You run it a LOT of times and get the average results.

So I decided to create a simulator.

Combat Simulator


In the first scene of "The Coming Dark", the players are set upon by a large group of skeletons. But how many is enough? At what point does the encounter go from being a cake walk to a crushing defeat?

So I wrote a program to simulate 50,000 combats between two groups: the five pre-generated characters that are included in the Dungeons and Dragons 5th Edition Starter Kit versus an indeterminate amount of skeletons. How many skeletons does it take before the players are likely to be on the losing end of the battle?

The small little program I wrote takes a few considerations:

  • All the attacks are basic attacks. Every class uses its preferred melee attack except the rogue (which uses his shortbow) and the wizard (which uses the cantrip ray of frost).
  • The noble fighter and cleric are the "preferred" enemies of the attacking skeletons. These are the front line defenders, and likely the ones that stand between the skeleton and the wizards. Only when they both fall is the rest of the party at risk.
  • No high end magic of any kind. Needless to say this would quickly sway the encounter in the player's favor.
  • No healing. No action surge, no cleric healing, no potions, etc... again, this is something the players have that the skeleton's don't. This also means that the players will not use any limited resources during the combat.
  • No one gets advantage or disadvantage on any roll. For that reason, the rogue never deals additional sneak attack damage.
  • A natural 20 deals double the normal damage. I know this isn't precise, but it's easier to code.
  • All the damage is rolled; no averages are used.
  • The skeletons have an AC of 12 and 6 hit points each. They have a shortsword as a weapon, which gives them a +3 to the attack roll and deals 1d6+1 damage on a hit.
  • The PCs are the five defined in the starter kit: Noble Fighter (greatsword), Folk Hero Fighter (bow), Cleric (morningstar), Rogue (shortbow), and Wizard (ray of frost).
  • Since he deals bludgeoning damage and the skeletons are vulnerable to it, the cleric deals an additional die of damage on a hit. Again, not precise... but easier to code.


I ran 50,000 iterations of each combat, adjusting the number of skeletons from 6 to 12. The simulations yielded the following.

# of Skeletons PC Wins PC Losses
6 49258 742
7 47238 2762
8 42606 7394
9 35178 14822
10  26024  23976
11  17060 32940
12  9388 40612

So, in a nutshell, the 11th skeleton is quite the badass. Players could more or less handle ten of them, but when that 11th one steps in things go to crap pretty quickly.

So what did we learn from this exercise?

  • It's very possible for PCs to trash a modest amount of low end minions without having to fire their big guns.
  • The above doesn't use healing at all, which means that even if the PCs get dinged about a bit they are still able to recover. PCs can win an encounter with 8 skeletons over 80% of the time and immediately go into the next encounter.
  • Dailies, spells, healing potions and other consumables - things that the monsters generally don't have - tip the scales considerably in favor of the PCs.
  • If you walk into a room with 6 skeletons in it, you can probably dispatch them fairly easily. As glorious as it might be, you don't have to nuke the whole room.

Until more concrete guidelines for monster creation and encounter balancing come about, I'll keep using this simulator and try to get a feel for how things should be. Over time, I might improve the simulator more and more so that it's more representative of each PCs actions in an encounter. Who knows? Maybe this will end up being a full on AI framework?

I can't help but wonder if WotC does this sort of analysis. Like I said above, sure they have tens of thousands of playtesters but it's such a diverse group with so many different situations that it may be hard to quantify. Not to mention that, if you present a specific combat situation to two separate groups, 99% of the time you'll get two different approaches and two different outcomes.

Can't wait to try this out on goblins and kobolds...


If you're curious, you can view the C# source code for the simulator HERE.


The Day After

Happy Post-April Fools Day everyone!

Time for an explanation... On April 1st 2001, while I was actively developing The Opera, a total conversion for Half-Life, I launched an "Opera Pre-Alpha", which is actually still visible and downloadable HERE through the Internet Archive (amazing... the ZIP file is still there to download!). You can read the entire background there.

No images are visible in the archive, but here it is for those of you unable to run that version:


Six months ago, amidst the news of "D&D Next", I made the choice to do it again and create another language interpreter using Dungeons and Dragons content. To be honest I had three choices of games I wanted to emulate: Zork, Wizardry (Proving Grounds of the Mad Overlord) or Ultima (III: Exodus or IV: Quest of the Avatar). All things considered, Zork was the easiest to do.

I did not have the benefit of having the source code to the original one I created 12 years ago (in C++, if you're wondering), so I set out to re-create the entire natural language interpreter in C#.Net. Yes, you read that correctly... I didn't use an existing interpreter like Z or Muddle; I created my own interpreter from scratch.

The result was The Caverns of Mayhem: A Dungeons and Dragons Adventure!


This was actually somewhat of a challenge to do. Not so much the language interpreter - I've done that at least three times before, each time in a different programming language - but how exactly to translate the D&D game mechanic to an interactive text adventure. I did the best I could, but there are certain things that are noticeably absent; for example, I didn't implement skills because I didn't quite know how. And the cleric's Channel Divinity powers were for the most part omitted because most of them were reactions which just wouldn't work.

To "win" you have to battle your way to the treasure room, take the treasure and return to the tavern with it. There are goblins and a medusa in your way; everything else is just filler. As was the case with the first one I did in 2001 (read the write up linked above), there was a lot more that I was thinking about but just didn't have time to do. For example, I had much more interaction planned with the tavern staff, the orc and the gazebo.

Now, in case you haven't tried some of these, here are some things you can try and some Easter eggs:

  • There are numerous responses taken verbatim from Zork, such as responses to suicide, jumping, yelling or typing "xyzzy" (or any other magic word from Sorcerer, Enchanter, Spellbreaker or Wishbringer for that matter).
  • Use any one of George Carlin's seven dirty words.
  • Use a Doom cheat code like "idkfa" or "iddqd". The response mimics what the game Hexen does if you try to enter a non-Hexen cheat code in to it.
  • As a wizard, "cast magic missile" while in darkness.
  • "Cast burning hands" (as a wizard) or "cast flames of the phoenix" (as a monk) in the presence of the gazebo.
  • Sell the orc's pie in the tavern.
  • Count the leaves. This is an inside joke in several Infocom titles. The number also has special mathematical significance: 69 in hexadecimal is 105 in decimal, and 69 in decimal is 105 in octal. I had other plans for the leaves, but just never got around to them.
  • Search the refuse in the Refuse Room. Yes, I implemented dire rats that most people will never see.
  • As a barbarian, you can "rage" or "flip out".
  • Roll the dice and either get snake eyes (curse) or box cars (boon).
  • Try to cast a spell while in the tavern.
  • Besides myself, all the other names in the README are characters from films directed by Stanley Kubrick.
  • Other things I don't remember.

I worked on and off on it for the past two months, and it was kinda fun to do and I'm actually really proud of it. I wish I could do more, but there simply wasn't enough time. And it wasn't perfect; there was actually a crashing bug if you tried to eat the leaves (among other commands). I have since fixed that and uploaded the new version.

If you are curious, below is a link to where you can download the complete source code in C#.Net to The Caverns of Mayhem: A Dungeons and Dragons Adventure! The project is compatible with Microsoft Visual Studio 2010 and only requires the Microsoft .NET Framework v2.0 to run.

I hope you all enjoyed it as much as I enjoyed creating it. Maybe next year I'll have a Wizardry emulator...

Download complete The Caverns of Mayhem:
A Dungeons and Dragons Adventure
source code
(C#, Microsoft Visual Studio 2010)

Filed under: 5E, DnD, Programming, RPG No Comments

DLI Acquires DnD Next Video Game License


"Omne ignotum pro magnifico"

If you've been following this blog, you know that we have had our fair share of communication with the legal department over at Wizards of the Coast, and as a result we have not only learned a great deal of what we can and cannot do as far as licensing but we have been able to figure out exactly who the right person to talk to is in order to get the necessary licensing agreements in place

Several months ago, after a great deal of negotiations (most talks of which started with the words "now please don't sue us, but...") we have managed to talk to the right people and sign the proper agreements to do what we thought was impossible: secure a provisional license to use the Dungeons and Dragons brand name to create the next state of the art video game based on the "DnD Next" rule set. The official press release can be read below:

Official Press Release by Darklight Interactive (PDF)

Since we are not authorized to be direct competitors to the upcoming MMORPG Neverwinter by Cryptic Studios, our product is a single player campaign that will be a traditional delve through a dungeon. While we have had a group of professional, well known writers working on the story - most of which you are familiar with, but we are not allowed to disclose names yet due to Non-Disclosure Agreements - I and a group of experienced software developers have been working on the engine.

Since we do not want to take funding away from Wizards of the Coast and would rather they spend the resources they have to get "DnD Next" developed and released, in a few weeks we intend to launch a Kickstarter project to fund the development of the final product. We did not want to launch a Kickstarter before we had a "proof of concept", and unlike some other companies we do not want to launch a Kickstarter to fund said "proof of concept". So we have been developing the engine on our own, on our personal time and at our personal expense, in the hopes that it can show the world what we're capable of and more easily reach our goals once the Kickstarter launches.

After further negotiations, and painstaking work over the past few months to get it in running condition, I have been authorized to release our first "proof of concept" (which we refer to internally as an "alpha" build) for The Caverns of Mayhem: A Dungeons and Dragons Adventure (tentative title... we'll let the writers come up with something better) that you can download below!!!

Download The Caverns of Mayhem: A Dungeons and Dragons Adventure (ZIP)

The game engine is not exactly a direct port of the "DnD Next" ruleset simply because, as is the case in Neverwinter, a lot of the rules don't exactly port flawlessly from the tabletop to a video game. But it has everything you've come to love about D&D: it's got dungeons, it's got monsters, it's got treasure... and, heck, it's even got a dragon!

The "proof of concept" which you can download below has been developed for Microsoft Windows (we're investigating a Mac port, but none of us actually own a Mac so we'll probably have to wait for funding on that) and requires nothing more than the .NET Framework 2.0. It is not graphics intensive so it should run on pretty much any machine; in fact, for those of you with inferior machines our game will probably run significantly better than Neverwinter because the hardware requirements are much lower. And, thanks to proprietary compression technology, it uses a lot less drive space!

As we mention above, it is a very early "alpha" build and has some known issues. And, since it's an "alpha", I ask that you do not start reporting bugs in it; we pretty much know what most of them, and have tried to document them in the "readme" file included with the distribution. Please read that file prior to launching the game so you understand what to expect and are aware of the aspects of the game that have yet to be completed.

We here at Darklight Interactive are entering an interesting time, and we would like to thank everyone at Wizards of the Coast for giving us the opportunity to use your license. We hope that, after looking at our proof of concept below, you support us and await our upcoming Kickstarter launch.

Thank you all for your support.

Download The Caverns of Mayhem: A Dungeons and Dragons Adventure (ZIP)

Requires Microsoft Windows operating system and the Microsoft .NET Framework v2.0
(c) 2013, Darklight Interactive - All Rights Reserved
Dungeons & Dragons, D&D, Neverwinter, Wizards of the Coast, and their respective logos are trademarks of Wizards of the Coast LLC in the U.S.A. and other countries, and are used with permission. Hasbro and its logo are trademarks of HASBRO, Inc.
Please don't sue us.


The Shotgun Approach

WARNING: THis post might ramble on a lot for little purpose. Read at your own risk.

For the most part, I've been reserving a lot of opinions I may have about "DnD Next" and trying not to actively engage those people who choose to complain about it at the top of their lungs. Doing the latter is harder than I thought, and sometimes I can't help but respond, but lord knows I try. So even though this post refers to one or two specific elements about DnD Next, this is not necessary a criticism of those elements but a concern about the fact that, good or bad, they exist in the first place.

The Development Process

Before I continue, let me try to describe what a product's development cycle is like.

Whenever a version of a product comes to the end of its development, there is inevitably a big meeting of all the employees in which the owners ask "OK, so what features should we have in the next version?" Usually, these meeting are a no holds barred brain dump of information where any and all employees mention even the slightest inkling of an idea they may have for a future feature. It could be something monumental that could take months to develop, or it could be something that even the lowest level programmer could do in minutes, or it could be "are you f%#&ing stupid?!?" quality material... it didn't matter. All these ideas, however nonsensical and unrealistic they may be, are gathered in one enormous list for the higher authorities of the company to mull over. And this list exists for a considerable amount of time without any concept of feature importance or development time needed to create what's on it.

For the next several weeks, especially after a major development push, programmers are allowed to muck around and experiment. A lot of designers will actively create something using the engine as a proof of concept, or they may just BS around and consider it a sort of mini-vacation, at least until the higher authorities decide who does what. While working on Deneba's Canvas graphics package, I spent four weeks writing something that ended up being patented by Adobe and could not legally be included in the product... but it was really cool and fun to do, though!

At some point, the higher authorities meet and begin to set levels of importance on everything in that list. This is when the sales people come in and look at the list alongside the development leads to decide what features they must have in order to make the product more sellable and justify a new version that people will buy; if there aren't enough "wow" features, there's no real reason to spend a ton of development resources for a product people will have no reason to purchase, so they may hold off the new version until they do have sufficient new features to justify it.

But once the list is sorted by importance (with the "are you f%#&ing stupid?!?" items removed, of course) and the group starts to get an idea of how long things will take, they must collectively draw a line in the sand. Anything above the line is a "must have" which is required to be in the product for it to be a viable new version, and anything below the line is a "would be nice once the 'must haves' are done". And then the "must have" list is disseminated to the developers, while the "would be nice" might never get to the developers at all. After all, they wouldn't want the developers to waste time doing stuff that isn't necessary to make the next version bankable.

I need to point out that I've actively worked in development shops where if you're supposed to be doing something on the "must have" list and decide to do a "would be nice" thing, if your superiors found out you might as well start packing your stuff while your fellow developers lay claim to your office space. Why? Because, in the eyes of the higher authorities, the "would be nice" list has no value right now. It does not add to the value of the product and it's ability to be sold, regardless of whether you agree with that choice or not. A feature you might consider cool, fun or whatever might be worthless to a the people that pay your salary.

Depending on the length of your development cycle, you may never finish the "must have" list. Ever. Heck, you might not even get close to finishing it by the time your product goes "gold"; there will come a time where the higher authorities will see the time estimates to complete development becoming longer than the time left before the day the sales people decided the product will launch, and they will start to cut things or push things to the next release. Don't be surprised if something you've been working on for months gets cut in such a way that you may be forced to surgically remove from the current build any trace of what you were doing to begin with (god help you if you were working on a vital system; be ready to work 37 hours a day to get it done before going gold).

And, of course, this is assuming that you will only go gold once... I've worked on a project that went "gold" five times in three days.

The Shotgun Approach

It took me a full action to load this.

In the above series of events you will note that the "higher authorities" - be they owners, salespeople, marketing folks, customer service, etc. - are the ones that consolidate the ideas and decide what has priority in the development cycle. In software the salespeople carry the most authority in this decision; in order to sell the next version, it has to be better and have sufficient "wow" features to justify current customers forking over money to buy a product they kind of already have.

But in the world outside of software, such as in the world of roleplaying games, it's hard to quantify what "better" is. If you read this blog, odds are you've seen the discussions that can come up: if you ask ten people what makes an RPG "better", you'll get ten different responses. So who decides what is in the next version? Who decides what makes the next product bankable?

In this case, it boils down to the fans. Since the salespeople are inevitably involved, they have to look at the audience and see what elements would provide a higher financial return. This could mean creating an element the majority wants, or perhaps creating an element that is so different from the prior version that its mere existence deprecates everything that came before and forces people to buy a new version (or a mandatory "upgrade"... like Internet Explorer). Sometimes these features might be the personal wants and wishes of the developers themselves, but in those cases they have a very difficult battle to fight; they have to sell their ideas to the higher authorities, and may be forced to accept the higher authorities telling them "you can't do that." I have a sense we've seen this sort of thing at WotC recently, but I digress...

But sometimes you just don't know what's bankable. You have ten possible ways of doing things and don't know which will be the preferred way, the way the majority of people will accept enough to add financial value to the product. So you have no choice to use what I refer to as the "shotgun approach": give it both barrels and try it all.

Rarely you see the "shotgun approach" in video games, but in the early days of mod development it happened a lot. Indie mod developers would look at the list of all the most popular games out there and say "let's do ALL of that!", and you wound up with sixty different versions of CounterStrike. Oh, and people like Team Fortress too, right? Let's railroad in some TF elements in to our CounterStrike clone... now we have BOTH! That'll be awesome, right?

Like I've mentioned before on this blog, while creating the Half-Life add-on The Opera I received numerous requests to add a ROCKET LAUNCHER to the game. Did it fit my theme? No. Did it make any sense to have? No. Did a small handful of players demand it or else they wouldn't play my game? Yup, you betcha!

In cases where somebody is incapable of making the decision of what gets worked on and what doesn't, the simple choice is to develop it all, however mindless and nonsensical it may be, and see what sticks with the audience. If people don't use it, there's no harm to its existence. People aren't going to hate the game because of this one optional feature that we could ignore, right? ... Right?

There's some problems to the shotgun approach:

  • Your "to do" list is significantly longer, and now you can't ignore the features you thought "would be nice". You now have to allocate development resources for any small thing on the list, however inconsequential it may be, and hope you don't run out of time before your "gold" date.
  • As developers, you will not like doing certain things on the list. It's your game after all, and it doesn't matter how many times you think "this is f%#&ing stupid" ... You gotta do it anyway. Nothing's worse than a developer that doesn't like what he's developing.
  • Since the feature list is customer driven, you end up working on things that a minority of people mentioned because you're just not sure if everyone else wants it or not. You have a handful of people saying "yes", but nobody has actively said "no" yet. When the product gets published in any way, the "no" people will be screaming with bullhorns from the rafters.
  • Every small thing, however nonsensical, must now fit in to the big picture. You can't add an item that actively conflicts with the core, so every seemingly trivial item must be analyzed to ensure it doesn't break the rest of the game.
  • Every small thing adds another test case. It it exists, someone has to try it. After all, god help you if you publish something untested.
  • Every small thing requires additional resources true developers don't think much about: layout resources, artwork, editing, copying of that information to other sources of information, etc. Heck, it requires more ink, and that may impact the product's retail price.
  • You could be working on things that simply don't belong in the game solely because some people think it does.

Focus on What's Important

So why am I talking about all of the above?

In the recent Rule of Three column on the Wizards of the Coast site, a single line raised my concern and that of a lot of other people:

Mike has drafted some very tight, clean rules for facing that should add a lot of tactical depth to combat, and make movement and positioning even more important than ever.

The reason the above concerns me personally is the thought of what didn't get worked on while Mike was writing a paragraph or two on "clean rules for facing"...? Personally, I'm not against the facing rules themselves; I've never used them in any prior edition, don't know what they are, don't know what impact they will have in the game... I haven't a clue. Yes, if the rule existed I would try to be a diligent play tester and give them a go to see if they add or detract from the game.

I tried to ask how many people actively requested such a feature, and the basic response was that "some" did (Note: the tweets of the person that answered my question have since been deleted). So I inevitably have to imagine the massive amount of requests WotC is facing in terms of features DnD Next should have, and really have to wonder why such a feature - which I can only assume is way down the list of "would be nice" - is getting such visibility. In a playtest that's currently missing what could be seen as an overwhelming amount of content, why is this even being discussed when other more critical elements of the game should come first?

But at a glance you have to question whether they belong as part of the game or not. For a majority of editions D&D has arguably not been a tactical game, and even 4E was tactical to a point. When you start adding things like this, you run the risk of turning the game in to something that it might not be. Knowing which direction your facing has little impact on the roleplaying and combat aspects of the game, and it's a borderline insignificant detail that could be handled via "theater of the mind" anyway. If you take the tactical aspects of the game farther than the roleplaying aspects of it, it stops being ther game you know and risks turning in to CounterStrike: D&D.

Another example: I can't help but wonder how many people told WotC that DnD Next was useless without having half a page dedicated to how long it takes to put on and take off armor. I mean, it took someone a certain amount of time to think about that, right? Was it really that crucial to the game? Will the game be unplayable without it? And how many people asked for it? Hundreds? A dozen? One? Was the WotC blacksmith the only guy that thought it'd be a cool idea?

When there are so many other things that need work and are vital components to the game, why is nonsensical stuff being considered at this point? Focus on what makes the game bankable, sellable, playable, fun...Spend your resources to get the important stuff done, and eventually throw in some of the lesser bells and whistles. Nobody's going to buy or avoid DnD Next because it takes 10 minutes to put on plate mail.


I wondered how much text is involved in describing combat facing, so I decided to check the D20 SRD.

Here is the page on "Combat Facing", which is a heckuva lot more than a couple of paragraphs.

Filed under: 5E, Design, DnD, Mechanics, RPG No Comments

DND Next: The Pseudo-Ranger

As the result of a write-up of the ranger "design goals" on the Wizards of the Coast website, there has been a lot of discussion of what a ranger is and what it should be. I figured I'd chime in with an opinion because rangers are the second most common class I play (the first being rogues), and I've played a ranger on more than one occasion in every edition they've existed in in D&D. I felt it necessary to come to their defense.

Before I continue, let's have a little history on the ranger as a class... The ranger existed as a core class as far back as AD&D 1st Edition (it was technically absent the in Basic edition; support for playing a ranger in the Basic edition was provided in Dragon Magazine), and since then it has been a constant presence in the D&D class list despite going through some seriously radical changes in each edition:  he went from having favored enemies to quarry damage, his spellcasting power source wavered between primal (druid), arcane and divine, and at one point rangers were even limited to the races and alignments they could be (in 1E, they were forced to be of good alignment).

But with the coming of "DnD Next" many are asking whether the ranger should be its own class at all. Logically, it's very possible that the ranger could be a subset of the fighter or rogue and made more ranger-like through the use of themes. After all, a ranger is arguably not much different than a fighter but with an affinity to natural environments.

Several arguments have been made regarding this, and quite a few of them actually make a very good case and could work quite well as a theme... but a problem exists: the ranger class has a history. It doesn't really matter if a ranger-like PC can be better designed with themes, background, feats or a lot of flavor text; the ranger has to exist as a class because it's been that way for over thirty years. If a player sits down at a game and says "I want to play a ranger," he can't be told "there isn't one" or "here's to play a character that is kind of like a ranger... only not."

In my opinion, there are certain aspects that have become required elements of D&D. Some more than others, of course; players will always have the six attributes, they will always have some sort of AC defense (how it is calculated is another matter), and will always roll d20s to resolve things. Just as there will always be mages and clerics, the ranger has become somewhat of an integral part in all that is D&D, and as such it should always be defined as a class even if it makes more sense for it to be something else.

Finally, many have mentioned that they would like "DnD Next" to contain only the four base classes - fighter, thief, mage and cleric - and create all other types of classes using themes, backgrounds, etc. The problem with this is that it really overcomplicates the class design; all of a sudden, you have a "fighter" that can be defined twenty different ways, and each one of those ways has to be explicitly worded so as not to cause confusion with each other. By separating like minded themes in to a new class, it makes the creation of both classes significantly easier. I won't have to wade through five different ranger-like themes when I want to create a straight up fighter.

So, please, let's keep rangers as their own class. Besides, it'll probably be the only way I'll once again get my velociraptor animal companion! 🙂

Filed under: 5E, Design, DnD, Mechanics, RPG No Comments