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.
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