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.
Overly Complex Encounters
"Out of intense complexities intense simplicities emerge" - Winston Churchill
Part of my problem designing a D&D 4e module is that I haven't played a live table top D&D game in over ten years. During that time, all the games I've been involved with are "play by post": I'm currently DM-ing several online games, and playing multiple characters in many more.
And the reason I can do so many concurrently is because of the nature of "play by post". The advantage of PbP is that all the mechanics involved in managing encounters is transparent to the players, so the players may not be fully aware of the amount of work the DM has to do. Since all my games are PbP and I have a multitude of utilities in order for me to do that management, I have the luxury of making some rather complex encounters. These may not translate well to a table top setting.
Several of the encounters in Chapter 1 and Chapter 2 of my campaign involve NPC allies. If it were one ally that's not a problem, but I use them a lot, and in once very specific case there are five PCs, five to six enemies and - last time I counted - twenty-three allies and/or non-combatants. I can't imagine what it would be like to handle the status of thirty-four creatures using pen and paper, dealing with things like rolling initiative over a dozen times. Heck, most people might not even own that many miniatures.
So there's my problem... I really like some of these encounters (the one I mention above is my favorite in the entire campaign), but some DMs might take one look at them and think "No way I'm going to deal with all that!" For the sake of publishing, I think I'm virtually forced to modify them so that they are manageable, so that DMs won't be dismayed at running them and elect to either reduce the complexity or skip the encounter entirely.
Another option I'm considering is possibly including two versions in the module, or at least enough descriptive text to explain how to simplify a seemingly complex encounter. But that would feel kind of odd... Including a "normal" version and a "use this if you're crazy" version of the same encounter.
But something interesting happened relating to all this... In addition to all the 4e campaigns I'm active in, I'm also active in one rather epic 3.5e campaign (also PbP). In that campaign we are a group of eight 8th level players currently fighting over ninety orcs, most of which are minions. As a player it doesn't appear that overwhelming, but I can see the amount of work involved in managing such an encounter. Even dealing with all the markers on the digital map is quite daunting sometimes.
But in 3.5e it seems almost... normal, as if that level of complexity was expected and commonplace. In 4e, it's ludricrous. I assume that's simply due to the nature of the 4e mechanic, and the new level of number crunching involved.
So has anyone out there run these sort of "epic" encounters where there are few against many, or perhaps a normal encounter that has a lot of NPCs just waiting to be turned in to collateral damage?
And the reason I can do so many concurrently is because of the nature of "play by post". The advantage of PbP is that all the mechanics involved in managing encounters is transparent to the players, so the players may not be fully aware of the amount of management the DM has to make. Since all my games are PbP and I have a multitude of utilities in order for me to do that management, I have the luxury of making some rather complex encounters. These may not translate well to a table top setting.
And there's the added benefit of time. It's much easier to do that much die rolling and encounter management when you don't have five people sitting across from you at the table wondering "well? Are you done yet?"
Several of the encounters in Chapter 1 and Chapter 2 of my campaign involve NPC allies. If it were one ally that's not a problem, but I use them a lot, and in once very specific case there are five PCs, five to six enemies and twenty-three allies. I can't imagine what it would be like to handle the status of thirty-four creatures using pen and paper, dealing with things like rolling initiative over twenty times. Heck, most people might not even own that many miniatures.
So there's my problem... I really like some of these encounters (the one I mention above is my favorite in the entire campaign), but some DMs might take one look at them and think "no way I'm going to deal with all that!" For the sake of publishing, I'm forced to modify them so that they are manageable, so that DMs won't be dismayed at running them, preferring to reduce the complexity or skip the encounter entirely.
I've been interested in getting a feel for live games once again, even if it was simply observing and not an active player. Maybe then I'll have a better idea of whether these encounters really are as complex as I fear them to be.
Skill Challenge: The Interview
POSSIBLE SPOILER WARNING: If you are participating in my campaign, or intend to participate in it, you may not want to read the attached PDF.
Skill challenges have always been my heroic flaw. I don't think I've been able to run a skill challenge correctly yet, but I'm getting there. A boatload of online resources and posts on other blogs surely helped me get it together, and I suggest everyone to look those up if they're having as much trouble as I.
The first scene in my campaign isn't an encounter... It's an interview. The five players are brought before the rulers of the village of Solis and essentially interrogated for the job of "village protectors". Depending on how they respond, the nobles might like them (in which case they'll actually support their efforts) or despise them (in which case they don't really care if the players die painfully).
In concept this was perfect for a skill challenge, but the mechanic didn't quite fit as it was designed. There were a few concerns:
- The party wasn't doing this as a collective; each person was being interrogated one at a time. They may be able to assist each other, but they can't speak out of turn.
- There were two people asking the questions, and they were both radically different individuals: one was a soldier and war general, the other was a mystic. The DCs should definitely not be the same.
- It was an interview to gauge the ability of the players... Should the players' reactions be restricted to a handful of "primary" skills? Almost anything should be fair game (I had a hard time figuring a way that Stealth could be used, though).
- The two people asking the questions have a high degree of bias for certain races and classes; there are certain types of people that they will be more sympathetic to, and others that they will have a seething hatred for. For example, they're elves who worship Corellon... so God help you if you're a drow.
Here is "Chapter 1, Scene 1" from my upcoming campaign, edited slightly to remove the really major plot spoilers (no "Conclusion"). You'll note a few changes to the skill challenge mechanic:
- Number of failures is irrelevant; only successes count. Furthermore, a PC has the option of not doing a skill check at all. If you're no good at being diplomatic or talkative, you don't have to force yourself to succeed. You simply don't do anything (you can speak, but it doesn't have to be a rolled skill check). In fact, if the players never fail they get bonus XP.
- There are two sets of DCs, depending on who the players are responding to: Laris or Lia. The warrior reacts better to feats of strength and endurance, while the mystic reacts better to diplomacy and intelligence.
- There are a whole boatload of modifiers depending on the player's class and race. You'll probably do great if you're a shardmind psion, but you're pretty much screwed if you're a drow rogue (you're lucky if they talk to you at all).
So here you go... The first scene in my upcoming campaign! Hope you enjoy!
Encounter: Hall of Spiders
We Xogo recently had a "Create an Encounter" contest. Unfortunately I didn't win, but I figure the following encounter should not be wasted.
During the development of my campaign quite a lot of things have changed. Rooms have been added and removed, creatures have changed drastically, the plot has been altered five different ways, etc...
The main reason is that certain things look good on paper, but when it comes to actually using them in a game it doesn't quite work. Many a time I have thought of a really cool idea that I wound up trying to railroad in the the D&D 4e mechanic, and the end result isn't quite what I had hoped. And some things that do seem to fit perfectly end up being a disaster when it comes to playtesting it.
On the massive external hard drive I use to keep all my campaign information I have one folder called "Legacy", which is where maps go to die. But just because they don't fit in to my campaign doesn't mean they'll never see the light of day. Maybe someone out there could use them... Someone like you!
So this will probably be an ongoing series of mine where I provide encounters or scenes that are disassociated from the rest of my campaign, and because I have no immediate plans to use them they aren't "spoilers". Maybe someone out there will breathe new life in to them.
The Hall of Spiders
One of the focal points in my campaign is, without giving too much away, a dungeon with very strong divine and arcane influences that has been abandoned for hundreds of years. In these environments there are generally three different things you can find: undead that simply refuse to die, strange creations infused with arcane energies or nature simply taking residence in a nice comfy place. This is the latter of the three.
This encounter was the very first encounter I developed for my campaign, at a time when I had no idea what the rest of the zone was going to contain. I didn't even know what this was the entrance to... A castle? A lair? The local inn?
After everything else in the zone was developed, this seemed horribly out of place. And the fact that it came immediately after a complicated encounter with a lot of enemies didn't help; I know some would argue that it goes against some sort of DM's obligation, but I simply didn't want to keep slamming the PCs with encounter after encounter.
Originally this had a fixed amount of minions, which you are most certainly welcome to do to simplify your life (I had six Spiderlings in the original design), but recently I read the article by Mario Podeshi on Save Versus Death called "Endless Hordes" Minions and I wondered "why does the number of spiderlings have to be finite?"
So here it is... The Hall of Spiders (Level 4+ Encounter)
Enjoy! If you do use it, or make any modifications to it, do let me know.
Toughening up Minions
There are various schools of thought about minions... Some people like them, some people hate them. Some use them to balance out an encounter, some will throw legions of them at a level one party just because they can.
In several of the starting encounters of my campaign, I use minions a lot. But I used them to give the story some scope, to show that you are facing something seriously evil with an absurdly large disposable army under its control. To the players they were never meant to be a threat, but rather they were an annoyance.
At first I thought a handful was enough; sending a fleet of minions at the party seemed like overkill. That was until one character in my campaign literally bowled over five of them in the first round, before any other creature even acted. By the time the monsters would have gotten to their spot in the initiative order, the room was empty.
So rather than just throw more minions at them (which would arguably unbalance the encounter) I decided to try something, and came up with the concept of a "tough" minion.
Here are the rules I put together:
- Creature starts with 10 hit points in the Heroic tier, 20 hit points in the Paragon tier and 30 hit points in the Epic tier. This is just enough hit points to be somewhat resistant to secondary attacks (for example, a monk will not be able to kill it with Stone Fist Flurry of Blows) and can even sustain attacks from other minions (in my encounter there were also ally minions), but most PCs could still knock them out in a single solid blow. And if the PC has a weak damage roll it might still be standing, which does make some sense if you think about it.
- Creature *does* take damage from a missed attack, but can never die from it. If the miss drops it to 0 hit points or lower, it stays alive with 1 hit point remaining.
- Creature has no healing surges of its own and cannot be healed in any way. It can benefit from temporary hit points, but it cannot recover from traditional damage.
- Creature can have vulnerabilities and resistances, similar to what a normal monster would have. For example, a Tough Decrepit Skeleton would have radiant vulnerability.
- Any damage the creature takes, even if it's a single hit point of damage, qualifies it as "bloodied". So it would be vulnerable to powers and feats such as Impending Victory.
- A critical hit on an attack roll kills it instantly, even if the attack doesn't normally cause damage. For example, if an Invoker critical hits it with Whispers of Defeat, it dies
- OPTIONAL: Double their XP value if you think they caused the players more trouble than they should have.
- OPTIONAL: Have the minion die automatically after two direct hits, also if you think they were more trouble than they should have been.
When the party faced the same amount of these "tough" minions, it was actually a little bit of a challenge, and weren't quite the cannon fodder they were originally designed to be. And they weren't much a threat to the party anyway, but they did go down swinging.
This also has an added benefit: you might be able to get away with making the players think they're not minions in the first round. If a player lands a weak blow and it's still standing, they might suddenly think that there's a serious threat and will begin to start burning off important resources.
There are a lot more minions to play with in my campaign... I'm going to continue using this idea and see how it works in the long run.
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