Chad Perrin: SOB

22 February 2009

By the way — I hope RPG Bloggers comes back.

Filed under: Metalog,RPG — Tags: — apotheon @ 07:02

I visited RPG Bloggers today, only to find a blank white screen with the following text on it:

Error establishing a database connection

. . . in big, bold, <h1></h1> black text. Ah hope it ain’t broke fer ever.

What is the importance of RPG terminology?

Filed under: Geek,RPG — Tags: , , , — apotheon @ 06:52

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

In Encounters vs. Scenes – RPG Terminology and Philosophy, Rick Neal talks about the differing implications of the terms “encounter” and “scene” as employed in the game books for White Wolf games and D&D:

I really started to notice it starting in 3E D&D, and it’s become even more prevalent in 4E. Adventures for D&D are breaking down to a collection of encounters. That’s the way the DMG addresses adventure creation, that’s the way the majority of the published adventures are written, and that’s the way I’ve been thinking about creating adventures.

He quotes the 4E DMG:

An encounter is a single scene in an ongoing drama, when the player characters come up against something that impedes their progress.

. . . and White Wolf’s SAS Guide:

Each scene is built as a discrete game encounter (or a closely-tied collection of game encounters) for the troupe to play through.

Scene Style

Leaving aside for the moment the fact that D&D 3.5 didn’t present quite as clear-cut a focus on combat encounters in its explanation of what constitutes an “adventure”, there’s some merit to the notion that the choice of terminology in a game’s rulebooks is very important. I just don’t think it’s important in exactly the way Rick Neal assumes — and I think it isn’t as important for how an adventure can play out as some other factors.

More important than the term used for something like the interactive waypoints in a game session, adventure, plotline, or campaign is the design of the system. My (A)D&D games have used “encounters” more like what the guy describes as “scenes” since before the first edition of Vampire: the Masquerade was even published. I’ve been prone to modifying the system with house rules to help support that style of play (among other reasons), but I’ve never felt a particular need to trade the term “encounter” for “scene” in those games. When I’ve felt compelled to change terminology, such as I described in New Attributes, (Mostly) Old Rules, it has been as an accompaniment to altering what the rules whose terms have been changed actually mean.

The greater importance of the choice of terms such as “scene” or “encounter” is the social effect. Notice that, with the significant focus on “storytelling” terminology rather than “roleplaying” terminology, the old-school World of Darkness games produced a far more acting-oriented approach in its gaming community. The flavor of a game’s community is going to be influenced by the game’s marketing — and all that flavor text, including the choice of Official Terms™ sprinkled throughout that flavor text, is part of that marketing. Whereas D&D grew out of a combat-oriented tactical miniatures wargaming tradition, and its terminology reflected that history, Mark Rein-Hagen together with White Wolf consciously sought to engender a very different perspective on how the game is played, and intentionally selected terminology that would foster such a perspective.

Encounter Style

As a result, D&D’s place in the gaming world only evolved toward a more roleplaying approach to gaming at the insistence in changing trends in the gaming community, and its designers have even fought against that community influence (as I feel 4E is an example), while V:tM aimed to land on the far side of where the gaming community sat, and drag it further in that direction.

I believe that tended to have a stronger effect on who played each game than on how people played a given game once they committed themselves to it, however. As the terms’ implications are described in Encounters vs. Scenes, that meant that encounter oriented gamers gravitated toward D&D, while scene oriented gamers gravitated toward WoD games — not so much that gamers found themselves pushed into either an encounter oriented approach or a scene oriented approach based on what game they played. When such acquiescence to pressure did occur, I believe it was more peer pressure from other people already playing the game, who invited a new player into their groups, than it was the terminology in the books shaping the way people approached gaming. Regardless of what terms are used in each game’s books, I have seen people take a more scene oriented approach to D&D and other people take a more encounter oriented approach to V:tM many times, with no hint that they even noticed the implications of the terms used in the books if those implications didn’t fit with their personal styles.

Of course, the differentiation of my New Attributes, (Mostly) Old Rules approach to terminology changes from the encounter vs. scene change in terminology is nebulous and very heuristic. It’s possible I’m imagining a greater point of differentiation there than actually exists.

Software design is not architecture.

Filed under: Geek — apotheon @ 03:21

It seems that, when one discusses software architecture at all, someone inevitably brings up building architecture. The two are compared, and conclusions about software architecture and design are drawn from physical building architecture and design. While the relationship between software architecture and physical architecture is closer and more equivalent in concept than some might think, that closeness can be misleading, and lead people to inaccurate conclusions about software development.

object oriented architecture

In many cases, putting together a new building consists of little more by way of analogy than burning a copy of a program onto a new CD — though of course, in reality, there’s a lot more to it. The actual analogous activity to writing up the blueprint of a new building design is writing the source code for a truly new program design, because what the builders at the site are doing is analogous to what your compiler does and not what the programmer does. The way many software dev shops divide up the job of software development into programmers on one hand and “architects” on the other is akin to breaking up the job of a physical architect into “idea guy” and “pencil guy”. Of course, the skills involved in software development are different enough from those in actual physical architecture that I’m not sure that’s really a valid comparison for coming to any conclusions about this software development practice.

On the other hand, most buildings are primarily duplicates of previous buildings, and there’s some similarity with software in that there are scads of CRUD applications created every year that do roughly the same thing, but at the same time there are more essentially new software designs every year than new building designs.

I think that builders are unavoidably more risk-averse than software vendors in large part because of the greatly increased cost of copying where buildings are concerned. If you think software development has gotten into a rut, with new programs being to a fair degree just rip-offs of old programs, you should try getting a degree in architecture and finding a job where you’re allowed to do “interesting” and “new” work with physical structure design, where something new and untested that causes the structure to collapse will cost tens of thousands of dollars at minimum, and that’s just during the “beta test” stage — let alone in production, where people will likely be inside it and get killed by the collapse.

Beyond that, there’s also the simple fact that there is not the same need for innovative architectural techniques when constructing buildings as there is in the software industry. The very ease with which completed software is duplicated and distributed completely changes that dynamic, as does the way the software industry operates (influenced by corporate culture, the environment engendered by strong copyright law, and other social and economic environmental factors). Perhaps more importantly for explaining the differences between how the field of architecture progresses and how the field of software design does so, however, is the cost that is passed on to the end consumer.

Software’s marginal cost is near zero — because once it’s “done”, it’s nearly free to duplicate it. Distribution can cost a lot of money, but it certainly doesn’t have to, and it is (perversely enough) largely the fault of traditional software business models that attempt to duplicate the form of business models that revolve around physical product that imposes any nontrivial distribution costs at all. Keeping all that in mind, the major production cost center is also quite reasonably the major target for investment in innovation. With actual physical construction, however, the major cost is in duplication because the marginal cost is so high. As such, it makes sense to devote far greater resources to innovation in the building process, rather than focusing on the designing process.

For this reason among others, it is only in very limited, incremental changes that any “advances” are made in the techniques used to develop new buildings. For the most part, one might expect that nobody really spends any appreciable money on improving the design process itself, because all the money is going toward improving building materials and similar actual construction costs — except in cases of specific needs, such as improved earthquake tolerance. There’s no object oriented design in the field of architecture, as far as I’m aware, and that’s because architecture just hasn’t gotten that far. Give it another thousand years, though, and building architecture may have caught up with today’s software architecture in terms of the growing complexity of structures.

In truth, software design bears a lot in common with architecture. They are similar enough that, in theoretical terms, the word “architecture” really fits software design quite well. In the real world, however, it leads people to make comparisons that don’t really work — and the similarity of practices convinces people to overlook the obvious problems entirely too often.

Put another way, software design is architecture, of a sort — but the field of software design today is quite different from that of architecture. Give it a century or two for the field of architecture to provide better insights into the field of software design as it exists today. Given another five years of software design innovation, however, and we might have to wait another couple hundred years for building architecture to catch up.

Of course, that doesn’t guarantee that all this “innovation” is going to be good in the long run.

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