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



Offline 4E Dice Calculator

For a while I've been using Sly Flourish's online 4E Dice Calculator for all my campaigns; it's quick and easy and I find it better to use than looking up the entries on a PDF and doing the math to adjust the die sizes. But recently - primarily due to that fact that I'm over my monthly broadband bandwidth limit by a crapload - I've felt the need to have the same functionality as the above web page but in an offline capacity.

So, for now, I've created the standalone application below. It's currently written using the .NET 2.0 Framework and is for use only on Windows machines, but I'm currently investigating making something Java-based so it can be used cross-platform. That's taking me a bit since, quite honestly, I've never written a Java application with a user interface (all the Java apps I've done have either been console applications, plug-ins, extensions and the like)... But I'm getting there.

I'm also considering making an Android applet as well, but that's uncharted territory for me.

I expanded my tool a little bit to include a d20 as an available die size. I know that might sound somewhat weird, but my expectation was to make the tool also support the "adjusted" damage equations provided by C. Steven Ross over at DMG42. The only reason I haven't fully implemented those yet is because I haven't been able to consistantly match his equations, but I may get around to that yet. In the meantime, you are allowed to use d20s to roll damage, and the system will warn you in cases where it's impractical (for example, using a d20 at level 1 is higher than the average damage, so it's not really permitted).

And if you click on the equation, it actually rolls it for you. It's pseudo-random and it doesn't use the means of generating random numbers that other die rolling systems use, but it's better than nothing.

I'd like to thank Sly Flourish for providing the online tool on which this is based. if I ever get around to creating an offline cross-platform version, I'll make it available in the same manner.

If you have any issues or suggestions on how to improve this tool, please let me know.

4E Dice Calculator
(MSWindows, .NET 2.0 Framework required)
Approx. 16Kb


Utility: New Monster Builder

I'm probably going to be a little critical of Wizards of the Coast here... I'm sure they have their reasons for releasing what they did, but I'm seeing it as an impartial observer, a paying customer and a software developer.

Most of this post was conceived when it first went Beta, but I didn't have a place to post it back then.

Yesterday Wizards of the Coast released the new Silverlight powered Adventure Tools, which includes the new version of the Monster Builder. I'm going to analyze it from two viewpoints: as a user and as a programmer.


To be honest, the old version of the Monster Builder is one of the most frustrating applications I've ever had to use. I understand the need to make the application "pretty" and pleasing to the eye, but that should not be at the expense of usability. It had numerous bugs, it was slow, and some things just didn't quite work right; with some patience, you could learn to accept it.

But it had one thing going for it: it was useful, and it served a necessary purpose for almost any DM out there. It might take you half a day, but you are able to create brand new monsters, edit existing ones, print stat blocks, etc...

The new Monster Builder has none of that... Yet...

Several months ago this new MB went in to beta for an elite few. At the time I thought it was simply a "proof of concept", to show people what it would look like and what it would be capable of, in addition to being what a beta is intended to be: test the integration between the application and the back end framework that supports it. At the time the app did little, but I kind of accepted that because I assumed they would add features over time during the beta cycle and allow their testers to try things out.

Now, several months later, they released the Monster Builder to the public... and it's apparently the same as when I first saw it.

Here's what the new Monster Builder can and cannot do:

  • The only power detail you can edit for each monster is the NAME of each power. Can't change the flavor text, range and area of effect, the attack information, the type of action, etc...
  • Beyond that, you can only edit the creature's name and level. Can't change defenses, hit points, abilities, skills, equipment, etc...
  • You can level an existing creature up or down from level 1 to level 55. Unless WotC is considering doing what MMORPGs often do and somehow increasing the level cap (because of how 4e is designed, I can't even begin to consider what this would involve), I can't imagine the need to level anything past level 30. Heck, Orcus is *only* level 33... I can upgrade up a kobold to level 55 that would pound him in to the ground like a railroad spike.
  • No means of exporting the creature. You can't even print to a PDF friendly format (the Character Builder has this same flaw... Considering the criticism there, you would think they would have considered it).

And that's it. Several months of development... to release the same product in "beta" form? A product that is literally missing 90% of the functionality that exists in the product it is replacing?

And while we're on the topic of the "beta" label...


I don't quite know when the term "beta" lost its meaning, but Wizards of the Coast isn't the first company to forget what the term truly means.

The official definition, as posted on Wikipedia, is:

Beta is the software development phase following alpha (beta is the second letter of the ancient Greek alphabet, used as the number 2. It is not nowadays usual to speak of a later gamma test). It generally begins when the software is feature complete. The focus of beta testing is reducing impacts to users, often incorporating usability testing. The process of delivering a beta version to the users is called beta release and this is typically the first time that the software is available outside of the organization that developed it.

(Emphasis mine.)

A lot of companies, however, follow the concept of a "perpetual beta"... GMail, for example, was in "beta" for close to three years, but at least GMail was reasonably "feature complete" before it ever saw the light of day; it had enough features that people could use.

The Adventure Tools are labeled "beta" even though they are not: they are nowhere near being "feature complete", and one could argue that they aren't even testing potential new features currently in active development. The Character Builder, however, *is* "beta" even though I don't believe it is labeled as such. It's even kind of amusing when you realize that the version number on the Monster Builder ( at the time of this post)  is remarkably similar to the Character Builder ( at the time of this post), despite the CB being actually usable and has a boatload more features.

Addendum: In retrospect, The third part of the version number is most probably an integer, which means that the CB is in fact higher. But it is the third part of the version number, which designates the actual build number rather than the release number. In other words, the CB has simply been compiled more often.

Their reason for releasing it in its current state? WotC_Trevor speaks...

Main reasons, short and sweet -  we wanted to give all the DDI members a chance to check out what we're working on, and we wanted to make sure that all DDI members had the chance to use the MB to import monsters into their VT games during the next step of the VT beta.

This would be acceptable if the product was described like that from the start. I may be crazy, but I somehow expected a Monster Builder to allow me to build monsters.

Also, you can't tell me to look at this application I and realize what they are "working on". The application hasn't changed at all in three months of Beta.


As both a programmer and an engineer, I'm curious. I'm the type that as a child would dismantle toys just to see what made them tick. So, to get a better idea of the technical aspects, I decided to analyze this new Monster Builder a little further.

In case you are not aware, Silverlight applications with the ".xap" extension are actually ZIP files; you can simply rename the extension to ".zip" and extract all the content, which includes the binaries and the reference data. Once you do that, it's quite enlightening.

Let me go through the technical discoveries:

Prettiness Versus Usability

I am one of the worst UI designers I know... I'm not "artsy", and much rather prefer to focus on core functionality than how an application looks. I like to think that my applications run remarkably well, even though they might look like they were visually designed by a caveman.

The new MB suffers from the same problem the old one did: the effort put in to making it look aesthetically pleasing causes the performance to suffer. Personally I would rather have an application that reacts immediately and looks like something IBM would make ("let's make it big, black and weighing several tons!"), rather than have a gorgeous application that I have to wait for every time I move my mouse.

The problem is that people like things that are "pretty". Of all the complains floating around on the 'net, I'm probably the only person that is bothered that it looks good. I don't care how it looks in the end... I want it to work!

Embedded Content

Included in the archive is a file called "Monster.data", which is a serialized data set of a considerable amount of monster information. This level of data - header information, if you will - is arguably necessary for the filters to work, but this is something that could have been more easily offloaded to the server. Basically, be a "dumb client" and do what the Compendium currently does: every time you look for something, ask the server to find it.

Instead, this file - let's call it the "monster index" - is loaded in to memory as one large data stream, so you have some general information for every one of the 3,700+ monsters floating around in memory even if you may not need it. Even if you load up the MB to make a quick change to a single monster, it has to load up that entire list.

This is what makes the Javascript-driven Compendium so nice to use: it's dumb. When it first loads, it knows very little about the information it is designed to retrieve (it only knows the categories of data), and every time the user asks for data it has to query the server through a .NET Service call and returns an XML response containing the results. Using this method of design the client never has to change, and any data updates could be done transparently at the server level at any time.

In the end, it ends up being a toss up between bandwidth and hardware. There was a time when bandwidth was scarce, so developers would try to bring as much information to the client as possible. Nowadays it's the opposite in some cases... I personally would prefer to use a lot of bandwidth if it meant not overwhelming the memory on my local PC or causing Silverlight and Internet Explorer to implode.

Web Application Ethic

Because the monster index is part of the Silverlight application itself, every time a monster is added or changed the entire Silverlight application needs to be recompiled, repackaged and redistributed. That means that your browser will never cache the monster data separate from the application. Even if they add one monster, you have to take the hit of downloading the entire Silverlight archive (3Mb compressed) and the system has to expand it out in to a temporary folder for execution (expands to 12+Mb), even if they didn't make any changes to the code base.

Again, the data should either come from a web service in the same manner as the Compendium or loaded as a separate archive from the server. Part of the reason they chose to move to Silverlight is that it was easier to make updates. What's easier: repackaging and distributing a new Silverlight application to everyone or changing a data record at the database server level?

Security Measures

One thing that bothered me about the original Monster Builder was the way the data was stored in the client.

First of all, the data was highly encrypted using government-level DES encryption, which is absurdly slow when it comes to handling a large amount of data. Secondly, the data was stored in a non-native XML format, which might be good for readability but is slower to process than if it were in native binary. Both of these issues are what made the offline MB so painfully slow when it initialized or did anything data related.

In the new version both of these issues are no more: the monster index is unencrypted and stored in a serialized binary format, while the data that isn't in the index is returned by the server in a very simple XML format (which would automatically be converted to a native binary format through .NET Service call management and the serialization engine).

Future Catalogs

The main screen of the Adventure Tools shows all the available catalogs. Currently there's only one - "Monsters" - but looking through the design it is clear they intend to have many more offerings. There are class libraries in the Silverlight code base for things like traps and encounters. I would not be surprised if there are future plans for a Trap Builder, Encounter Builder, Skill Challenge Builder, etc...

As good as this might sound, my fear is that this will ultimately replace the Compendium. Sometimes I just want to look something up and don't need the overhead of this Silverlight application loading up and offering me editing functionality I have no intention of using. The Compendium is up and active instantly; sometimes, that's all I need.


The product is obviously incomplete, and WotC themselves has said that countless times, but the product should have been released when it reached a point where it can not only be useful but be on par with the deprecated product it is replacing. Now that they no longer support the old Monster Builder (it can be downloaded but they're not updating it), users are left out in the cold with nothing they can use.


When I started to use the original Monster Builder for myself, I hated it. So much so that I began to look for an alternative, and ran across the Monster Maker by Asmor. It was the perfect little app, and did everything I wanted the original Monster Builder to do with less flair and "prettiness". It worked beautifully!

I had some crashing issues with it, so I sent an email to Asmor himself asking about it. He essentially said "I'm not supporting this any more... You want it?" Shortly thereafter, I had in my hands the complete .NET source code to Asmor's Monster Maker.

At this time I had a crazy idea: I sent an email to everyone I can think of at Wizards of the Coast telling them that their current MB is lousy and that I would be willing to create a Monster Builder for them for free. I even offered to make a web version (using Javascript, AJAX and other technologies significantly simpler and more portable than Silverlight or Flash). My only concern was access to the existing creature catalog, which I was capable of generating on my own but wanted their permission to do so before they tried to sue me.

I sent this email before anyone outside of Seattle knew where they were going with these Silverlight applications. Needless to say, they never answered me.

I have since tinkered a bit with Asmor's Monster Maker, and I think I could make a viable application that would compare in functionality with the MB but maybe not be as pretty (maybe if someone out there would help me with the "artsy" stuff that might not be the case). The only thing that has prevented me from going full bore on this little project is because the application would have to be devoid of any actual monster data: because of WotC's SRD guidelines, I can't contain any monster information from the core rulebooks in it. I can't include the 3,700+ monsters. How useful would it be for everyone to have to recreate the monsters from scratch?

But I remain optimistic... I'm hoping that WotC will do what is should be expected of them and make the Monster Builder what it is meant to be. Give the people what they need, what they are paying for, what they want from a company to which they are paying membership fees.

In the meantime, I'll be here if you need anything.


Utility: Truly Random Die Rolls

Image provided by XKCD - http://xkcd.com/221/

I've been a programmer for close to thirty years, and during all that time I've had a nasty habit that I show no sign of getting rid of: if I need a program, I don't spend much time actively looking for it... I just write one!

In the online D&D games I was a part of before I entered the world of the Wizards of the Coast forums, there was a certain degree of trust: the DM made all the rolls. The players simply said what actions they wanted to take and trusted the DM to not screw them. As a DM it also allows me to, every now and then, to "fudge" the rolls of the players so that things don't go from bad to worse for them (DISCLAIMER: If I ever fudge player rolls, it's always in the player's favor. I never do anything malicious to the players because I don't like how the dice fall). So far, this has worked out pretty well.

In the Wizards of the Coast forums I noticed an interesting phenomenon: players like to be in control of their own fate. They want to make all their own die rolls, even death saves (I've seen players do several death save rolls all at once, just so they know how long they have before they're truly dead). With that in mind, a lot of DMs go as far as to post the monster defenses right from the start so the players themselves know when they hit or miss before the DM does; with that knowledge, they can write the hits and misses in to their own roleplay text.

But there is little trust in this... Players can't say "I rolled a hit"; they have to prove it. So they use a variety of online die rolling sites: Invisible Castle and CoCo's die roller, and post direct links to the rolls on the site.

I've tried to use these sites, but they just feel... awkward. So I wrote my own: dice.brainclouds.net.

Now one would think that creating a die roller is an easy thing: just generate a random number every time. But I'm a computer science/mathematics person, and I realize something: computers can't generate "random" numbers.

A computer's random number generator is actually a complex equation based on a variety of internal factors. Since it is a mathematical process, it might not seem obvious but over time some patterns do occur. One could argue that similar patterns exist in physical dice; as the edges of the die wear, dice begin to roll a certain way. But I wanted something truly, genuinely random... So I turned to the place that provides just that: RANDOM.ORG.

RANDOM.ORG "guarantees" randomness because they technically do not use a mathematical equation. I'll let their website explain:

Perhaps you have wondered how predictable machines like computers can generate randomness. In reality, most random numbers used in computer programs are pseudo-random, which means they are a generated in a predictable fashion using a mathematical formula. This is fine for many purposes, but it may not be random in the way you expect if you're used to dice rolls and lottery drawings.

RANDOM.ORG offers true random numbers to anyone on the Internet. The randomness comes from atmospheric noise, which for many purposes is better than the pseudo-random number algorithms typically used in computer programs. People use RANDOM.ORG for holding drawings, lotteries and sweepstakes, to drive games and gambling sites, for scientific applications and for art and music. The service has existed since 1998 and was built and is being operated by Mads Haahr of the School of Computer Science and Statistics at Trinity College, Dublin in Ireland.

But then I thought of something else... "Law of Averages". If many people were using the system, if one person got lucky and got all the good rolls another person would get the bad ones. So I decided to make all the die pools unique to each person. In other words, imagine you own your set of dice that nobody else could use. Nobody will "steal" die rolls from you!

So there you have it... an over-engineered die rolling program. What did you expect from a software engineer, anyway?

Anyone and everyone is welcome to use it. It's currently in what I like to call a "beta" form, and is being actively used by several people on the Wizards of the Coast "play by post" forums, even though it technically isn't an officially sanctioned utility for such a thing. Maybe some day it will be.

Here you go: http://dice.brainclouds.net/

Finally, I also have the functionality on the website as a standalone application (that goes to RANDOM.ORG and retrieves the rolls). One of these days I'll package it up and distribute it. I'm also considering making something similar for smartphones, but that will take some doing.


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.