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

      

19Jun/12Off

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.

Filed under: 5E, Design, DnD, Mechanics, RPG Comments Off
Comments () Trackbacks (0)
  1. Great post.

    One issue with this is that bad code in software can make the game unplayable. A bad rule in a tabletop RPG can usually be avoided or houseruled or errata’d or handwaved. Even in the best RPG’s there’s probably something you consider a bad rule. But it also means that once the core is relatively done, you can work on optional systems in parallel to some degree. There still needs to be some communication, but it’s not as vital as in software. In fact, it should probably be done in parallel because you need to make sure that the core rules are flexible enough to deal with the optional content before the core rules are set in stone.

    The rules on donning armor are important to old school players who like to have random encounters interrupt your sleep. And they look to be remarkably similar to older editions. They probably took it exactly from an older edition, gave it a once-over and pasted it. Not a lot of time spent.

    Also, this game has “Modularity” and “Appeal to different styles of gaming” on the must-have list. Because of these you need to build modules for things that some people don’t think belongs in the game. It means that they have to pay attention to a number of the vocal minorities. I think it’s a risky and challenging move, but it’s what they’ve decided to do.