Reply to thread

Message

<blockquote data-quote="Janx" data-source="post: 6210220" data-attributes="member: 8835">Nothing is ever simple.&nbsp; Normal people do not understand or think about the shape of data and what it takes to actually model it in a technologically useful way.Here's a link to the site where somebody made a d20 database in a variety of formats (Access, SQL, MySQL, etc):<a href="http://www.andargor.com/" target="_blank">http://www.andargor.com/</a>One of the handy things is when you DO build your system, I can easily extract exports from it to help populate your system with this d20 content.This is the table definition for a Feat in d20 v3.5:CREATE TABLE spell (&nbsp; id INTEGER,&nbsp; [name] VARCHAR(100),&nbsp; altname VARCHAR(255),&nbsp; school VARCHAR(255),&nbsp; subschool VARCHAR(255),&nbsp; descriptor VARCHAR(255),&nbsp; spellcraft_dc VARCHAR(255),&nbsp; [level] VARCHAR(255),&nbsp; components TEXT,&nbsp; casting_time VARCHAR(255),&nbsp; range VARCHAR(255),&nbsp; target VARCHAR(255),&nbsp; area VARCHAR(255),&nbsp; effect VARCHAR(255),&nbsp; duration VARCHAR(255),&nbsp; saving_throw VARCHAR(255),&nbsp; spell_resistance VARCHAR(255),&nbsp; short_description VARCHAR(255),&nbsp; to_develop TEXT,&nbsp; material_components TEXT,&nbsp; arcane_material_components VARCHAR(255),&nbsp; focus TEXT,&nbsp; description TEXT,&nbsp; xp_cost TEXT,&nbsp; arcane_focus VARCHAR(255),&nbsp; wizard_focus VARCHAR(255),&nbsp; verbal_components VARCHAR(255),&nbsp; sorcerer_focus VARCHAR(255),&nbsp; bard_focus VARCHAR(255),&nbsp; cleric_focus VARCHAR(255),&nbsp; druid_focus VARCHAR(255),&nbsp; full_text TEXT,&nbsp; reference VARCHAR(255))The bottom half has some fiddly bits so he can define what classes can access the spell, but the top half should be familiar and kind of obvious.Now, will these fields apply to PathFinder's spells?&nbsp; D&amp;D 4E, GURPS, ShadowRun, D&amp;D Next?Some probably, like the name and description.&nbsp; But the rest is stricly fields defined by the structure of spells in D&amp;D 3.x.That means in practical terms, you can't define a generic Database for Spells, and stick everybody's spells in there (well, you could one design pattern is to have ALL the unique fields people need, and then hide the ones they don't by keeping a definition somewhere of what fields a ruleset needs).What I'm saying here is, if you haven't realized that Spells are described very differently between game systems and will need different fields to contain them, and your developer hasn't figured that out, you will NOT get the product you think you want.Because I am versed with the subject matter (RPGs) and with database design, I understand the nuances that have to be dealt with.I caution you that if you think what I'm talking about is out of scope with your product, that you may be making a mistake.&nbsp; Your developer may not realize what you're really asking for, and will give you a database suitable for holding PathFinder data, but not one suitable for other game systems (even related ones).</blockquote>

[QUOTE="Janx, post: 6210220, member: 8835"] Nothing is ever simple. Normal people do not understand or think about the shape of data and what it takes to actually model it in a technologically useful way. Here's a link to the site where somebody made a d20 database in a variety of formats (Access, SQL, MySQL, etc): [URL="http://www.andargor.com/"]http://www.andargor.com/[/URL] One of the handy things is when you DO build your system, I can easily extract exports from it to help populate your system with this d20 content. This is the table definition for a Feat in d20 v3.5: CREATE TABLE spell ( id INTEGER, [name] VARCHAR(100), altname VARCHAR(255), school VARCHAR(255), subschool VARCHAR(255), descriptor VARCHAR(255), spellcraft_dc VARCHAR(255), [level] VARCHAR(255), components TEXT, casting_time VARCHAR(255), range VARCHAR(255), target VARCHAR(255), area VARCHAR(255), effect VARCHAR(255), duration VARCHAR(255), saving_throw VARCHAR(255), spell_resistance VARCHAR(255), short_description VARCHAR(255), to_develop TEXT, material_components TEXT, arcane_material_components VARCHAR(255), focus TEXT, description TEXT, xp_cost TEXT, arcane_focus VARCHAR(255), wizard_focus VARCHAR(255), verbal_components VARCHAR(255), sorcerer_focus VARCHAR(255), bard_focus VARCHAR(255), cleric_focus VARCHAR(255), druid_focus VARCHAR(255), full_text TEXT, reference VARCHAR(255) ) The bottom half has some fiddly bits so he can define what classes can access the spell, but the top half should be familiar and kind of obvious. Now, will these fields apply to PathFinder's spells? D&D 4E, GURPS, ShadowRun, D&D Next? Some probably, like the name and description. But the rest is stricly fields defined by the structure of spells in D&D 3.x. That means in practical terms, you can't define a generic Database for Spells, and stick everybody's spells in there (well, you could one design pattern is to have ALL the unique fields people need, and then hide the ones they don't by keeping a definition somewhere of what fields a ruleset needs). What I'm saying here is, if you haven't realized that Spells are described very differently between game systems and will need different fields to contain them, and your developer hasn't figured that out, you will NOT get the product you think you want. Because I am versed with the subject matter (RPGs) and with database design, I understand the nuances that have to be dealt with. I caution you that if you think what I'm talking about is out of scope with your product, that you may be making a mistake. Your developer may not realize what you're really asking for, and will give you a database suitable for holding PathFinder data, but not one suitable for other game systems (even related ones). [/QUOTE]

Verification