Reply to thread

Message: <blockquote data-quote="J_D" data-source="post: 3000970" data-attributes="member: 20956">I think you've got part of the idea, but you're missing a vitally important aspect.First, let me state my bias - I'm a software engineer by profession, so I'm strongly inclined to view the subject in those terms.  I'm fully aware that many gamers will vehemently disagree with the views I state below.A roleplaying game can be split into two parts - setting and system.  Setting is the map, lands, cities, NPC's, history, myths and legends - in short, the people, places and things.  The system is the set of mechanics by which events within the setting are adjudicated.  Both are needed for a roleplaying game.  With no system all you have is collaborative storytelling - you don't have a game at all.  With no setting at all, all you have is an flavorless and abstract board game akin to checkers.The system itself can be split up into two sub-parts - rules and data.  Your post addressed only the rules part - the collection of statements of the general form "if situation X, then do Y to produce the resolution Z".  For example, X might be "to see if an attack hits", Y would be "roll d20, add modifiers, and compare to the target's AC", and Z would be "if the AC is equalled or exceeded then the attack hits".  In essense, all the rules can be reduced to this form, and comprise the conditionals and operators that make up the "language".What I want to address here is primarily the data part.  The rules - the conditionals and operators - need something to compare and operate on or they're pointless.  That something is, obviously, the data.  This data is comprised of a number of game objects or 'entities' - classes, characters, skills, feats, spells, monsters, etc, and those objects are defined by some set of values.  For example, classes have names, levels, BABs, saving throws, special abilities.  Characters have names, attributes (STR, etc.), height, weight, age, skills, feats, etc.   I think the data part is the foundation of a roleplaying game, because the rules need the data operate on to produce results.  The "ToHit" rule example is useless without the data - the modifiers and AC - to operate on, just as in a computer or mathematical language the "greater than" comparison is devoid of meaning without two numbers to apply it to.This structure of game data - entities and attributes - is essentially a relational database.  This is where game design must start - what data model will the game be built upon?  What are the entities, what attributes do those entities have, and how do the entities relate to each other?  The data model is the foundation of the game system because you can't design rules to operate on data until you know how the data itself relates with each other.I would go so far as to use this idea as the fundamental basis on which to judge the value or 'goodness' of a game system or any particular mechanic within it.  A good game system is one in which the data model is clean and elegant and (non-software people please bear with my use of technical jargon) is normalized to the Third Normal Form.  The farther away the game system's data model is from the Third Normal Form, the lesser is its quality.Some who object to this might say that a pen-and-paper roleplaying game is not a computer game.  I readily agree with that but it's irrelevant to the point at hand.  Data is data and follows the same rules whether it's electronically automated or not.  The cleaner and more elegant the design of the database, the simpler and more orthogonal the rules for using that data will be, and I think most people would agree that this makes for a simpler and easier to learn game system.  That this will simultaneously make the game easier to implement in a computer application is just icing on the cake.Players or even DM's don't have to be aware of the details of data modeling or relational databases to gain this benefit.  If the rules are simple and the information about classes, characters, etc. is given in easy to use tables, then the players and DM's will learn it quickly and use it efficiently, just like a driver doesn't need to be a mechanical engineer or understand the workings under the hood of his car.The 3rd edition of D&D is a significant improvement over previous editions precisely because the data model underlying the system is more easily implemented in a normalized database.  It's not perfect, of course, but it is an advance over 1st and 2nd editions.As an aside, this principle is why I hate loathe and despise the very concept of the "substitution level" and consider it one of the most deplorable of the recent additions to the D&D rule set.  I've yet to figure out a way to cleanly fit it into the data model, and if I were going to write a computer application to implement D&D I'd have to resort to nasty kludges to get it done; that deeply offends my sense of design.  Even without any computer in use, in any pen-and-paper game I DM substitution levels will be banned outright.It's been my observation that the development of the setting and system parts of a roleplaying game - "fluff" and "crunch" as it's called - require distinctly different skill sets and that it is rather rare to find people who are good at both.  Setting design needs people who are good at the "artsy" type things like history, mythology, politics, etc., while system design needs people who are good at data analysis and number crunching.  For this reason, if I were in charge of a game company I would divide the design and development department into two distinct and separate sections.  I'd put the "artsy" type people in one office to work on the world, hire database architects and data analysts to engineer the game system, and not let the "artsy" people get anywhere near system design.The setting developers can tell the game engineers "it'd be really cool if a character could do this", then the game engineers would take the idea and engineer a data model and rule mechanic to support it.  If a particular "do this" idea is simply impossible to elegantly fit into the game system, then the game engineers will tell the "artsy" folk "it doesn't work; it'd make a stupid and kludgy world - find another idea."  This should be rare, though; good engineers should be able to find a way to fit most things in, and if they truly can't then the idea probably really is a stupid idea that doesn't belong.</blockquote>

Verification