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

The Shotgun Approach

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

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

The Development Process

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

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

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

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

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

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

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

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

The Shotgun Approach

It took me a full action to load this.

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

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

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

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

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

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

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

There's some problems to the shotgun approach:

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

Focus on What's Important

So why am I talking about all of the above?

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

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

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

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

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

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

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

 ADDDENDUM

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

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

DND Next: The Pseudo-Ranger

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

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

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

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

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

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

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