WotC Announces Digital Tools… AGAIN.
***SHAMELESS PLUG***
Cavern of the Damned is now available for Pathfinder (through DriveThruRPG) and for Dungeons and Dragons 5th Edition (through the DM's Guild)!
God, has it been *that* long since I posted anything here?
My year has been kind of chaotic, to say the least... but leave it to Wizards of the Coast to announce something that might just bring this blog back from the dead: at PAX, WotC announced D&D Beyond, a new suite of digital tools being created by Curse to support D&D 5th Edition.
Wait, what? You mean you've heard this story before? Well... about that... Time for a history lesson.
Background: The History of D&D Licensing
In the days of 3rd Edition and 3.5E, WotC created the Open Gaming License (OGL, for short) so that publishers can create D&D content. Soon the market was saturated with content, and everyone was reasonably happy.
But the OGL created something that blindsided WotC: Paizo went through the OGL with a magnifying glass and, soon enough, Pathfinder was born. Suddenly there was a new player in town that directly threatened WotC's crown as the king of fantasy RPGs. WotC was terrified, and from that point forward they became more protective of their content than ever before.
When 4th Edition (4E, for short) came around, WotC decided to close the door on the possibility of such a thing ever happening again, so they discarded the OGL in favor of the Game System License (GSL, for short). The GSL did allow some publishers to release material, but it was heavily restricted and had several limitations as to what you can actively publish. Yes, you could continue to publish things using the OGL, but besides certain things you could not include legally (creatures that were part of WotC's "intellectual property") you could make no mention of WotC or D&D at all. Many were forced to do silly things like say their product was "compatible with the 4th edition of the world's most popular roleplaying game" (a claim that itself was in doubt due to the rise of Pathfinder).
Then there's the whole situation regarding the digital world... At the beginning of 4th Edition some of the core books were available in PDF format, but WotC quickly realized that they had no control over their distribution and weren't making as much money off them as they could. They were, in their eyes, losing money. So they yanked all the PDFs, took a step back in to the dark ages and pretended PDF technology didn't exist at all (some argue that this is the same reason why Dragon and Dungeon magazines were terminated; there was no way to make reliable money off them). Only recently, with the appearance of the DM's Guild, did PDFs return... and with such an absence of PDFs that was fostered over so many years, the demand for PDFs exploded and it was a rousing success.
For 5th Edition, WotC decided to go back to the OGL, but there's still an air of uncertainty as far as digital tools. It's not that people can't create the tools... it's that people are afraid to. WotC legal is a nasty foe to have (trust me on that), and many that have tried to create online tools before were violently shut down. There's such a cloud of uncertainty around digital tools that no one dares to do them for fear of WotC's wrath.
The Beginning of Digital Tools: 4th Edition
Prior to 4th Edition, in what you can arguably call the early days of the internet, WotC didn't have many digital tools to speak of to support 3rd Edition and 3.5E. Creation of such tools was in the hands of third parties, who could freely create these tools under the conditions of the OGL.
When 4th Edition's GSL came around, the GSL had a specific clause added that never appeared before: third parties were explicitly denied creating any digital tools or applications using the 4th Edition ruleset. WotC seized on the opportunity to create the tools themselves, and DDI (D&D Insider) was born, where WotC would charge a monthly fee for users to access their digital tools.
There's just one problem with that: WotC is not in the business of creating software (with the growth of Magic the Gathering Online, that has recently changed... but, even so, MtG's their golden goose). It never was, nor should it ever be. Yet they tried, and the results were disastrous.
At first they created a standalone application to create your characters, but WotC quickly realized there was no way they can charge a monthly fee for something that can be used offline. So they abandoned the standalone application in favor for an application hosted on their website. And to give you an idea of how much of a mess that was, do an experiment: go find any experienced software developer you know and see how they recoil in horror when you say the word "Silverlight".
Almost as soon as 5th Edition was announced (to be honest, I don't remember the exact timeline here), WotC announced that the 4th Edition tools would no longer be supported and would eventually be abandoned entirely. This went along with the new mindset WotC had: basically pretend that 4th Edition never happened.
Digital Tools for 5th Edition, Chapter One
DISCLAIMER: The following is based on discussions I had with someone who, for now, asked to remain anonymous. Since WotC legal has me on speed dial, I cannot elaborate on where they got this information, but I personally trust it.
Trapdoor Technologies was a modest company that had an interesting product: a way to get content online and hyperlink the ever loving crap out of it. Admittedly, not a lot of people were using their app in the first place, but it was a nice idea at least.
But there's one thing that made them different: they were gamers. Basically the entire upper level staff at Trapdoor were heavily in to RPGs (they were the first group to ever playtest a product of mine, Cavern of the Damned for Pathfinder). And they saw that their tool would be a really cool idea to use for RPG content.
So they took a shot and pitched their idea to someone (I don't know who) at WotC, and that person at WotC loved the idea. At first Trapdoor only suggested the product they had - hyperlinking D&D content - but WotC is the one who asked Trapdoor if they can do that *and* create a character generator to boot. Trapdoor, a company with not much of a development team to speak of, agreed to do just that without having any real idea what they were getting in to. Contracts were signed, Trapdoor got some funding to begin development on what would end up bring Morningstar/Dungeonscape, and spent six months developing the product before its announcement at Origins.
Thing is, Trapdoor seemed as much of a developer "shop" as WotC was in the 4E days. They seemingly had no idea what they got themselves in to, and had nowhere near the infrastructure and resources to deliver a product of such scope. Prior to this they hadn't even created an Android app at all ever, so they immediately had to run around and find the developers to actually do that (I have to admit, I offered my services to them to do that). When someone brought up desktop support, they were equally flustered.
During this time, Trapdoor was in constant conflict with WotC over pricing. Trapdoor wanted to price the tools themselves cheap, preferring the users to spend the money on the actual books. WotC, for who knows what reason, wanted to go the other way: they wanted to add micro transactions *everywhere*. For example, they wanted to charge $1.99 for each class and each race you wanted. But, so long as the funding continued and the fans seem so like what they were doing, Trapdoor pressed on because, after all, they did have WotC's blessing to continue... right?
After GenCon of that year, in an act that should come as a surprise to no one that has dealt with WotC before, everything changed.
Apparently, the person at WotC that was dealing with Trapdoor was working autonomously, and had not even bothered to run it up the chain of command. In other words, 600K and six months were spent developing Morningstar while the upper echelon of WotC management - and, specifically, WotC's branding and legal departments - had no idea it was happening.
As soon as the "powers that be" found out, chaos ensued. WotC immediately demanded that they remove the books from Morningstar, which was the whole reason the project was green-lit in the first place. Without the book content, Trapdoor lost the only thing that WotC had apparently agreed upon, and they were left with not much of a product after that.
Trapdoor panicked and tried to renegotiate a new pricing deal with WotC, but WotC didn't see the future in the same way. Not only did WotC immediately terminate the contract, but they effectively threw Trapdoor under the bus and chastised them for "not meeting WotC's expectations." Trapdoor was thrown like a discarded bone at the fans, and they mercilessly tore into them.
Trapdoor tried to stay afloat, but there was no wind in their sails. In the eyes of the public, they failed. As a company, they didn't last long before their investors pulled the plug and shut them down.
Trapdoor still owes me $14.10 for Cavern of the Damned, but I'm not bitter...
Digital Tools for 5th Edition, Part Deux
And here we are...
Trapdoor was effectively an indie startup that was barely staying in the black, but Curse is an established software development company with over ten times the staff (141 employees, at least according to their company profile). Curse is also owned by Twitch and has multi-platform products out there in the marked that are used by tens of thousands of gamers, so they've arguably done this before.
But Curse is that and only that: they actually are a programmer "shop". I have no doubt they can create a good product that would be easy to use, but they are only creating a front end for WotC's content. WotC has absolute say in how much access to that content costs, and as we've described above: when it comes to the digital realm, WotC is still in the dark ages.
Based on a Reddit post by the product lead at Curse, it looks like WotC is leaning towards the micro-transaction route that they tried to ram down Trapdoor's throat. So expect to pay as much for a 5th Edition character class as you would for a handful of hearts in Candy Crush.
Conclusion
I have confidence in Curse being able to make a decent app, but this project might be doomed from the start because of WotC's pricing model. I remain cautiously optimistic that WotC will see the light some day and change their ways. We can only hope.
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.
Objective
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.
Results
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...
*EDIT*
If you're curious, you can view the C# source code for the simulator HERE.
New Dice-Related Tools
I've recently been working a bit on some tools I us to make my life easier, so I thought I'd share them.
Both of the following apps are for Microsoft Windows and require the .NET Framework (as I write this I don't remember if it's 2.0 or 3.5). They are standalone EXEs that are fairly portable and have a small footprint.
1) Damage Calculator
A while back I posted an offline 4E damage calculator that used formulas based on Sly Flouish's calculations. I modified the application to support adjustments due to ongoing damage and automatic percent increase for brutes (25%).
You can download the new version HERE.
4E Dice Calculator
(MSWindows, .NET 2.0 Framework required)
Approx. 14Kb
2) Dice Pool Graph
While kicking around ideas for an RPG I'm thinking of doing, I needed an easy way to visualize bell curves for dice pools of varying sizes and for multiple different dice combinations. Thanks to followers on Twitter I was directed to AnyDice.com, but I needed something a little more portable.
The application shows you the distribution for any dice equation you put in, from the basic (3d10) to the complex (3d6 +1d8 +9). It will show you the mathematical probability but also has options to make 100, 1000 and 10000 die rolls to be a little more convincing.
You can download the app HERE.
Die Pool Grapher
(MSWindows, .NET 2.0 Framework required)
Approx. 10Kb
And there ya go... If you have any issues or requests with the above, please let me know.
Unless I think of something else to make my life easier, my next application will most probably be a Monster Builder. The 4E one I was working on is actually farther along than I would have thought, so I might make that one available after all. Stay tuned!
Light and Dark Fonts
It's been over a month since I posted? Gosh, I've been busy... Sorry.
A long time ago, for an alternate reality game that... well... failed miserably, I created two custom font sets. I actually used these two fonts in "trailhead" packages to start the game, writing the entire sender's address label in the corresponding font.
I expected the folks at UnFiction to take a few days to decode it. It took them hours, maybe less.
Since I imagine that some of you DMs out there might be interested in writing things, like for puzzles, in a cryptic font but may not have the time or inclination to create your own font to do so, I thought I'd provide these two.
"DLI Lightscript" was made to be used by an angelic, apparently good/lawful organization; it was designed with smooth curves and lines, portraying a certain level of symmetry. Almost mathematical, if you will. Numbers are included as well, and the symbols appear similar except the pips are solid black I think.
"DLI Darkscript" was made to be used by a shady, apparently bad/evil organization; it's chaotic, with no sense of rhyme or reason. No curves in it at all, entirely made by sharp lines and hard corners. Even the line thicknesses vary between characters. It's kind of a mess, but it was made to be that way.
Both files are provided as Windows TrueType (TTF) fonts wrapped inside a RAR archive.
If you do use this, I'd be really interested in knowing how. Let me know!
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.
AS A USER
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...
AS A PROGRAMMER
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 (1.3.23.0 at the time of this post) is remarkably similar to the Character Builder (1.3.207.0 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.
TECHNICAL ANALYSIS
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.
CONCLUSION
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.
AN ALTERNATIVE
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.
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