Chad Perrin: SOB

20 February 2009

We can have more than one combat per session!

Filed under: Geek,RPG — Tags: , , — apotheon @ 11:45

This is part of my RPG series of entries here at SOB. See the inaugural entry in the series for more details.

The title of this SOB entry is a paraphrase of something I have read at least two dozen times in online discussion. This is a common refrain amongst fans of D&D 4E who extol the virtues of the new edition’s “streamlined” combat rules. The statement is meant to convey the sheer weight of 3.5 rules, their complexity and tediousness, and how it takes forever to resolve actions and progress the action through combat. Every time I think about that, the following ideas occur to me:

  1. Maybe these people are moving from high level D&D 3.5 characters to low (first) level 4E characters. Higher level characters tend to take longer to get through a combat encounter than lower level characters, because these characters have more Feats and class special abilities to sift through. This applies to 4E characters, too, especially with the way all classes — not just the nominal spellcasters — now have the equivalent of spell lists with their growing pools of Powers.

  2. The focus on being able to crank through several combats per game session strikes me as a pretty monomaniacal interest in combat. My games rarely have more than one combat per game session, but that’s not because a single combat encounter takes a full session. It is, instead, because most of the game isn’t about combat. The characters in my games actually do things with their lives other than shed blood. They interact — with each other, and with the people in the world around them — and often manage to do so without waging war on each other. The frequency of more than one combat encounter in a single game session is about the same as the frequency of no combat encounters in a game session.

  3. The enemies must not be much of a threat in most of these 4E games if they’re plowing through six combat encounters per session. Usually, a closely matched opponent makes things take longer, and usually, a tough opponent reduces one’s ability to take on the next tough opponent that comes along, if there isn’t any rest and recuperation time between encounters. It’s only the easy, cannon-fodder stuff that goes down in a fountain of gore quickly enough to leave PCs ready to take on the next challenge without batting an eye, and that’s the way it should be if you’re roleplaying instead of rollplaying.

  4. Most of my games aren’t dungeon crawls, so even if my gaming groups were more combat-focused than they are (and less roleplaying focused) there wouldn’t be as much of a “knock down one, another stands just behind it ready to get knocked down” justification for constant combat encounter churning.

More important as a counter-argument, I think, is the gaming experience I had tonight.

In about two hours and fifteen minutes of play:

  • one combat with a creature whose challenge rating was the same as the average group level, in a group of two PCs and one noncombatant NPC

  • one combat with four creatures of a slightly lower challenge rating, involving the same two PCs and noncombatant NPC

  • probably about an hour and a half of noncombat play — roleplaying, travel, exploring, avoiding combat, et cetera

I guess, if we were doing the combat encounter churning dungeon crawl sort of game, we could have fit another four combat encounters in a single session. It’s worth noting that this included having to look up rules a lot, because this is only the second time I’ve run a session with a Barbarian in it using the Pathfinder RPG Beta rules, and I wanted to make sure nothing had changed since the Alpha 3 rules.

Somehow, having paid closer attention to just how long things took this time around, the performance of tonight’s session makes the strident complaints of 4E fans about the lengthy, complex combat rules of 3.5 seem pretty damned thin.

Thinking back, I remember a game session a couple of years ago in which a group of four “good guys” in a D&D 3.5 dungeon crawl cut a bloody swath through half a dozen combat encounters per session. Seriously, I don’t know where these 4E guys get their notions about 3.5 combat.

4E fans: Let’s dispense with the argumentum ad hominem.

Filed under: Geek,RPG — Tags: , , — apotheon @ 07:32

This is part of my RPG series of entries here at SOB. See the inaugural entry in the series for more details.

I regularly see comments like these in defense of 4E’s decision to rip all the variation out of character classes:

The system prevents too much munchkining (which I love) and the people I’ve found who’ve hated it have generally (though not always) been Munchkins.

I see this crap all the time, and it’s getting really old. It seems to be predicated upon the assumption that anyone who doesn’t like the way 4E “balanced” the rules must be some kind of power gamer whose only interest in class variation is min/maxing. News flash: that’s bullshit.

How about in the future, when one of you provincial anti-3.5 jackasses (not all 4E players, mind you, just the jackasses) is tempted to insinuate that anyone that prefers 3.5 over 4E is just a “munchkin”, you shut the hell up? If you can’t come up with an actual counterargument to what someone else offered as a reason he or she dislikes 4E, you should just admit it or keep your mouth shut. Making personal attacks against people as a distraction from the subject of discussion doesn’t prove anything other than that you’re a jackass and you are unable or unwilling to have a reasonable discussion.

Notice how I very cleverly used a parenthetical equivocation to provide some mitigation of the harsh, insulting nature of my statement about “provincial anti-3.5 jackasses”? Yeah. Notice how the quote from a provincial anti-3.5 jackass above does the same thing? Think about how you felt, if you’re a provincial anti-3.5 jackass, when you read my parenthetical remark. Did that make you feel better? Did that eliminate any potential distaste you had for what I said? Do you think I’m convinced you are any less intentionally insulting just because of your own parenthetical remark? Yeah, parenthetical, insincere “Well, not all of you!” comments aren’t really much of an excuse. If you’re going to be a jackass, just own up to it.

Thanks for your time.

Did OOP do this to us?

Filed under: Geek — apotheon @ 06:54

In Two lessons for the price of one, Assaf over at Labnotes referred to No Wonder Enterprise Software Sucks^H^H^H^H^H Is Low Quality. He quoted the following passage:

My point is that the architectural complexity of these applications inhibit a person’s understanding of the code. . . . Without actually doing anything, applications are becoming too complex to understand, build, and maintain.

The original piece of writing about the low quality of enterprise software by Travis Jensen is worth a read, but Assaf’s own brief take on the matter is all I need here:

Every layer makes perfect sense in isolation. The cracks start showing when you pile them up into a mega-architecture, and you can clearly see how some of the layers cancel each other out.

Object Oriented Programming

One of the oft-cited benefits is the ability to “reuse code” without having to rewrite it. This is accomplished by way of encapsulating code with data in a manner that provides a sort of discrete entity to which one can refer over and over again within a program. That encapsulation, along with the protection (that is, protecting the code and data inside an object from contamination by improper access) that OOP offers, provides other benefits as well.

Among these other benefits is increased sustainability of large, complex projects, with many programmers who need not even be familiar with each others’ work (or names, for that matter) helping to develop the overall project. Because object oriented design allows a program to be more fully and easily broken down into separate, largely independent chunks than many other programming styles allow, it is easier to specify an API, then assign its implementation to a single team of programmers, and send them off to finish that task. These groups, in turn, can further break down their own chunks of the overall system into smaller chunks, and hand those sub-chunks off to sub-teams or individuals.

As large, complicated software systems like this evolve over time, they tend to grow in terms of total number of chunks that make up the whole system. Furthermore, mediocre (or even downright crappy) code can flourish within carefully encapsulated and protected classes without ever having to be judged by outside eyes; that is to say, one doesn’t even need anyone outside the team or programmer that developed a single segregated piece of the whole system to view the code, as long as it “works”. Nobody working on any of these individual chunks needs to know anything about the project’s Big Picture, either. There isn’t even any particular need to have a unifying architectural style, and with big enough projects, it can quickly become nigh-impossible to impose such a unifying architectural style anyway.

The Pattern

Can we see the pattern yet?

A while back (like, two years ago), I wrote a consideration of the social effects of OOP on how software has “advanced” titled OOP and the death of modularity. In it, I may have seemed to say the opposite of what I’ve been implying so far, but the very perspicacious among you may notice this isn’t the case. In fact, both OOP and the death of modularity and this piece point out basically the same problem, but in different ways: that software is getting bigger and more complicated without actually separating concerns in as meaningful a way as it could — as, in fact, certain older development philosophies (like “the Unix philosophy”) provided significantly better modularity and significantly reduced complexity.

Of course, I wasn’t then, and I’m not now, saying that object oriented programming is the proximate cause of the ills of bloated enterprise software.

What I’m saying is that people are the proximate cause — people who don’t know what the hell they’re doing. These people accept all the marketing for OOP, which states that it’ll make your code more modular and more stable and just generally better. It won’t. It will help you do good things for your code if you apply it intelligently, and if you don’t use it even when you shouldn’t.

OOP still isn’t a silver bullet. Nor is FP, for that matter. They’re just tools that can help when properly applied. Don’t make the old mistake of assuming that when you have a hammer, everything’s a nail. Sometimes it’s a hex nut, and you need a different tool.

. . . and don’t assume that just because you’re using OOP techniques you don’t have to get actually good programmers to do the work for you. As Paul Graham put it:

Object-oriented programming offers a sustainable way to write spaghetti code.

It doesn’t force you to do so — but it sure does make spaghetti code a lot more attractive.

OOP didn’t do this to us; we did it to ourselves. OOP just held our hats.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License