Compromise and Conceit

This is a topic which has bothered me consistently since I first played Neverwinter Nights, and I was reminded of it today when reading the debate about unified game mechanics at Jeff’s Gameblog. I have been a fan of the development of unified game mechanics for many reasons for quite a while (that is what my own modifications of the d20 system are aimed at), but I was recently reminded by a friend, who is playing OD&D, of the richness and diversity of gaming experience in some of the early games, where every aspect of the system had a slightly (or wildly) different mechanic, and different rules and outcomes. I can still almost smell my Dungeon Master’s Guide and see the dense text describing what were in essence separate game sub-systems for every character and every spell. I wonder sometimes if unified game mechanics – even those with spells – can sometimes spoil this diversity.

What does this have to do with Neverwinter Nights? Well, I played Neverwinter Nights (NWN) purely and simply because it was by the crew who brought me Baldur’s Gate. Baldur’s Gate was a rich and diverse playing experience, with every scene, room and adventure section unique. Even game backgrounds differed from room to room. But NWN was, by contrast, disappointingly arid. Every room looked the same, every outdoor setting had the same sound and scenery, and although the mechanics were much simplified over BG, there was no sense of challenge or fantastic setting in it. The world was empty. I think this came down to the different design methods for the games. By the time NWN was released there was a rich library of graphics-cards programming methods, which I think were based on modern Object Oriented methods, which made it easy to produce scenery at a high level of interaction (visually in fact) using the editor – this sort of thing is facilitated very well by object oriented programming. These methods also enabled the consistent mechanics of action resolution. But in BG, the scenes and the monsters were built up piece-by-piece, using a more old-fashioned and time-consuming method (I think BG was from a previous generation of games which still used large amounts of specialised programming for each section). The result was art. For all the messiness of action resolution through toolbars and pausing so you could click and point and click again, there was a diversity of play and experience not present in NWN (or NWN2, IMHO).

Unified mechanics have, I think, something in common with Object Oriented programming. They essentially define a set of classes of objects, methods and properties for interacting with them, and provide the DM a toolkit for resolving actions smoothly and consistently at every stage of gaming. I think DnD 4e shows this, with every character having an “attack” method which is essentially resolved exactly the same way – only the look of it is different. Cutting out the diversity in favour of simplicity of resolution has removed some of the flavour, too. I think you can get this back through personal effort (I think the spells in my Compromise and Conceit world have a lot of flavour even though they use a common mechanic for resolution), and it is true that ultimately a lot of what happens in the gaming realm can be divided into attacks, buffs, effects or non-combat moves which simply beg for a unified resolution method. But I think it is subject to the same flaw as NWN experienced – it’s easier to bash out a very same-same set of rules, with no powerful descriptive properties or diversity, by favouring ease of game construction and task resolution over detail and the pleasure of developing a diverse and interesting system. Certainly I think D&D4e did this, and even 3.5e to some extent.

So, I think the trick with a unified mechanic is to use the simplicity it presents to enable smooth resolution of the detail of conflict which can be missing or difficult to rule on in systems which rely on sub-systems and exceptions to function. For example, I have some ideas for balancing large and small weapons in combat which would make combat a much richer and more tactical experience, but which I think wouldn’t work well in D&D pre- third edition, a system in which differences in weapons really weren’t used even if they were in the rules. The idea I have in mind uses the unified mechanic naturally to enable users of light weapons to take risks in order to close range on, and gain an advantage over, users of longer weapons. The unified skill-check system I use makes this easy to resolve without needing any special mechanics, just perhaps a sentence or two of advice. In general DMs should be using unified mechanics in order to broaden the range of circumstances in which PCs can act, and to diversify play. But I think in reality most unified mechanics are too clumsy or not well-enough explained (or not really sufficiently unitary) for people to do this easily. So they end up feeling arid, like NWN2.

Maybe this is food for thought in game design – don’t privilege unity of mechanical resolution over house-ruling fun stuff. Or, don’t assume that the unified mechanic will be sufficient for every DM in every circumstance, and don’t be afraid to tinker with it for the key parts of the system (i.e. combat). Or maybe it just means that those of us who think unified mechanics offer improvements need to explain how we use them and how they can work better. I might work on some examples of this from my system over the next few weeks…