Reply to thread

Message

<blockquote data-quote="Crazy Jerome" data-source="post: 5657562" data-attributes="member: 54877">Like the idea. One minor quibble though, and this is one of those things that even well-organized RPG editors continue to do--that irritate me to no end: If you are going to relate classes to talent trees, put the relation information on the side with the longer list or that is expected to vary the most. That is, nothing in the fighter write up would say what access to talents they get. In the talent, you say which classes can use it.&nbsp;I realize you didn't mean it this way, and it is left over from the thinking that classes will be added. You idea, however, implied that the class list would be limited and that the talents would be the varying thing. And if really both things are going to vary that much, then just take the information out of the classes and the talents, and have a separate list that shows who gets what. This will get updated all the time anyway. So might as well keep it separate and short.&nbsp;And then eventually it expands so much that you get the 3.5 spell lists issue, but that could be handled by keeping the class list under control. Which is why what I would really prefer is that the connection not be direct (e.g. fighter &lt;--&gt; sword and board) but via keywords. I recognize, however, that those kind of keyword relationships are a lot easier to do after the fact than to plan ahead of time, when you don't know exactly what will be on both lists.&nbsp;Gee, that's a lot of text on a minor irritant. Can you tell that I've been dealing a lot lately with poorly designed relational databases, especially improper many-to-many relationships? <img src="http://www.enworld.org/forum/images/smilies/angel.png"&nbsp; class="smilie" loading="lazy" alt=":angel:" title="Angel&nbsp; &nbsp; :angel:" data-shortname=":angel:" />&nbsp;Oh, and I completely agree about the hit points.&nbsp; I'd really prefer damage-dealing scale very slowly, and hit points to match.&nbsp; But have attack chances and defense scale more rapidly.&nbsp;&nbsp; Not only is it easier to track, it reduces some of the rapid multiplicative effects (hit chance times damage) on the scaling.</blockquote>

[QUOTE="Crazy Jerome, post: 5657562, member: 54877"] Like the idea. One minor quibble though, and this is one of those things that even well-organized RPG editors continue to do--that irritate me to no end: If you are going to relate classes to talent trees, put the relation information on the side with the longer list or that is expected to vary the most. That is, nothing in the fighter write up would say what access to talents they get. In the talent, you say which classes can use it. I realize you didn't mean it this way, and it is left over from the thinking that classes will be added. You idea, however, implied that the class list would be limited and that the talents would be the varying thing. And if really both things are going to vary that much, then just take the information out of the classes and the talents, and have a separate list that shows who gets what. This will get updated all the time anyway. So might as well keep it separate and short. And then eventually it expands so much that you get the 3.5 spell lists issue, but that could be handled by keeping the class list under control. Which is why what I would really prefer is that the connection not be direct (e.g. fighter <--> sword and board) but via keywords. I recognize, however, that those kind of keyword relationships are a lot easier to do after the fact than to plan ahead of time, when you don't know exactly what will be on both lists. Gee, that's a lot of text on a minor irritant. Can you tell that I've been dealing a lot lately with poorly designed relational databases, especially improper many-to-many relationships? :angel: Oh, and I completely agree about the hit points. I'd really prefer damage-dealing scale [B]very[/B] slowly, and hit points to match. But have attack chances and defense scale more rapidly. Not only is it easier to track, it reduces some of the rapid multiplicative effects (hit chance times damage) on the scaling. [/QUOTE]

Verification