Menu
News
All News
Dungeons & Dragons
Level Up: Advanced 5th Edition
Pathfinder
Starfinder
Warhammer
2d20 System
Year Zero Engine
Industry News
Reviews
Dragon Reflections
White Dwarf Reflections
Columns
Weekly Digests
Weekly News Digest
Freebies, Sales & Bundles
RPG Print News
RPG Crowdfunding News
Game Content
ENterplanetary DimENsions
Mythological Figures
Opinion
Worlds of Design
Peregrine's Nest
RPG Evolution
Other Columns
From the Freelancing Frontline
Monster ENcyclopedia
WotC/TSR Alumni Look Back
4 Hours w/RSD (Ryan Dancey)
The Road to 3E (Jonathan Tweet)
Greenwood's Realms (Ed Greenwood)
Drawmij's TSR (Jim Ward)
Community
Forums & Topics
Forum List
Latest Posts
Forum list
*Dungeons & Dragons
Level Up: Advanced 5th Edition
D&D Older Editions, OSR, & D&D Variants
*TTRPGs General
*Pathfinder & Starfinder
EN Publishing
*Geek Talk & Media
Search forums
Chat/Discord
Resources
Wiki
Pages
Latest activity
Media
New media
New comments
Search media
Downloads
Latest reviews
Search resources
EN Publishing
Store
EN5ider
Adventures in ZEITGEIST
Awfully Cheerful Engine
What's OLD is NEW
Judge Dredd & The Worlds Of 2000AD
War of the Burning Sky
Level Up: Advanced 5E
Events & Releases
Upcoming Events
Private Events
Featured Events
Socials!
EN Publishing
Twitter
BlueSky
Facebook
Instagram
EN World
BlueSky
YouTube
Facebook
Twitter
Twitch
Podcast
Features
Top 5 RPGs Compiled Charts 2004-Present
Adventure Game Industry Market Research Summary (RPGs) V1.0
Ryan Dancey: Acquiring TSR
Q&A With Gary Gygax
D&D Rules FAQs
TSR, WotC, & Paizo: A Comparative History
D&D Pronunciation Guide
Million Dollar TTRPG Kickstarters
Tabletop RPG Podcast Hall of Fame
Eric Noah's Unofficial D&D 3rd Edition News
D&D in the Mainstream
D&D & RPG History
About Morrus
Log in
Register
What's new
Search
Search
Search titles only
By:
Forums & Topics
Forum List
Latest Posts
Forum list
*Dungeons & Dragons
Level Up: Advanced 5th Edition
D&D Older Editions, OSR, & D&D Variants
*TTRPGs General
*Pathfinder & Starfinder
EN Publishing
*Geek Talk & Media
Search forums
Chat/Discord
Menu
Log in
Register
Install the app
Install
Upgrade your account to a Community Supporter account and remove most of the site ads.
Community
General Tabletop Discussion
*TTRPGs General
Design approachs.
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="Crazy Jerome" data-source="post: 5523780" data-attributes="member: 54877"><p>In any kind of model design work, I think of consistency not a technique but as a pool of "design capital" from which you can draw. That is, any decent model that relates to something meaningful to people, there will be some inconsistency ... "suggested". It happens for various reasons, and each one has different costs and benefits. So by default, you make the design consistent, but when you have a good reason not on some particular case, you weigh the cost of inconsistency and decide if it is worth it.</p><p> </p><p>I think of this as "capital" because I think humans process a small amount of inconsistency with no problem whatsoever. We even expect it. But each time you add to the inconsistency, you increase the cost for less and less benefit. That is, ten inconsistent design choices may be individually worth the cost for the related benefits, but the sum of the costs is greater than the parts, while with benefits the sum of the benefits is often less than the parts. So that implies an opportunity cost to every inconsistent element you introduce.</p><p> </p><p>For those of you exposed to relational database design, this is very similar to database "normalization". A perfectly consistent database is in "3rd normal form". However, most real life databases are "denormalized", that is, made deliberately inconsistent in certain parts, because then the model will be more useful, more convenient, etc. </p><p> </p><p>If you make one skill work mechanically differently from the other 12 in the game, because of some vague notion of "realism" trumping your consistency, you may or may not have made a good decision. If you did, it was luck. On the other hand, if you "denormalize" that skill from consistency because you realize that it being different is going to add certain benefits to the play experience, and that these benefits are surely worth that bit of inconsistency, and worth more than other such inconsistency that you could have introduced--then you've got a good decision, and it has nothing to do with luck. <img src="https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f642.png" class="smilie smilie--emoji" loading="lazy" width="64" height="64" alt=":)" title="Smile    :)"  data-smilie="1"data-shortname=":)" /></p></blockquote><p></p>
[QUOTE="Crazy Jerome, post: 5523780, member: 54877"] In any kind of model design work, I think of consistency not a technique but as a pool of "design capital" from which you can draw. That is, any decent model that relates to something meaningful to people, there will be some inconsistency ... "suggested". It happens for various reasons, and each one has different costs and benefits. So by default, you make the design consistent, but when you have a good reason not on some particular case, you weigh the cost of inconsistency and decide if it is worth it. I think of this as "capital" because I think humans process a small amount of inconsistency with no problem whatsoever. We even expect it. But each time you add to the inconsistency, you increase the cost for less and less benefit. That is, ten inconsistent design choices may be individually worth the cost for the related benefits, but the sum of the costs is greater than the parts, while with benefits the sum of the benefits is often less than the parts. So that implies an opportunity cost to every inconsistent element you introduce. For those of you exposed to relational database design, this is very similar to database "normalization". A perfectly consistent database is in "3rd normal form". However, most real life databases are "denormalized", that is, made deliberately inconsistent in certain parts, because then the model will be more useful, more convenient, etc. If you make one skill work mechanically differently from the other 12 in the game, because of some vague notion of "realism" trumping your consistency, you may or may not have made a good decision. If you did, it was luck. On the other hand, if you "denormalize" that skill from consistency because you realize that it being different is going to add certain benefits to the play experience, and that these benefits are surely worth that bit of inconsistency, and worth more than other such inconsistency that you could have introduced--then you've got a good decision, and it has nothing to do with luck. :) [/QUOTE]
Insert quotes…
Verification
Post reply
Community
General Tabletop Discussion
*TTRPGs General
Design approachs.
Top