• Please note: In an effort to ensure that all of our users feel welcome on our forums, we’ve updated our forum rules. You can review the updated rules here: http://forums.wolflair.com/showthread.php?t=5528.

    If a fellow Community member is not following the forum rules, please report the post by clicking the Report button (the red yield sign on the left) located on every post. This will notify the moderators directly. If you have any questions about these new rules, please contact support@wolflair.com.

    - The Lone Wolf Development Team

Ultra-Customizing d20

MPHopcroft

Well-known member
This is somewhat related to my question in the Developer's Kit query about renaming a cloned data set. what I'd like to know is how one goes about creating an ultra-customized d20 dataset using the d20 core mechanic but a completely different set of skills, spells, etc.

Although I imagine one would need the mature Developer's Kit to do a ground-up rebuild such as a point-buy system, how would one create a d20 variant in which, for example, spells are purchased using a completely different mechanic?
 
At 11:09 AM 3/20/2007, you wrote:
This is somewhat related to my question in the Developer's Kit query about renaming a cloned data set. what I'd like to know is how one goes about creating an ultra-customized d20 dataset using the d20 core mechanic but a completely different set of skills, spells, etc.
You can currently do two things within Hero Lab that are not very apparent and that make this possible. There is the "hidden" mechanism and the "replace" mechanism.

The "hidden" mechanism allows you to effictively remove a thing from existence within Hero Lab. For example, if I hide the "Appraise" skill, it stops appearing.

The "replace" mechanism allows wholesale replacement of a thing. This can be incredibly useful, since the replacement "cascades" through all dependencies. For example, if I replace the standard Longsword entry with a new one that does 2d4 damage instead of 1d8 (because that's how my group plays it), then every Longsword through the data files is automatically changed. That means every pre-defined magic weapon that happens to be a Longsword gains the new damage behavior with a single change.

All that being said, it would be an extreme nuisance to have to individually hide all spells, skills, etc. to come up with a completely new list. So what we should probably make available is a "d20 core" set of data files that omit all the skills, feats, etc. Then someone could start with the d20 mechanics and nothing else, adding the information he wanted on top of that. Since all of the skills, feats, etc. are available in the d20 "source" directory, it would be easy to re-use anything from that material. I'll put this on the todo list...

Although I imagine one would need the mature Developer's Kit to do a ground-up rebuild such as a point-buy system, how would one create a d20 variant in which, for example, spells are purchased using a completely different mechanic?
What sort of mechanic are you envisioning? We have plans to build a few more relatively common mechanics into the base data files, so you might be looking for something that is going to be included shortly. Also, the difficulty depends on facets of the mechanic you want to implement.

For some types of mechanics, it can be done now. For others, it will require that we get the Kit documentation updated to include the details on how to define new custom "classes" and/or modify existing "classes". Doing that is not "hard", but it's multiple weeks of work to do well and that's time not actually enhancing the product itself. So that's why it hasn't been done yet and the current plan is to get it done in May (barring any surprises).
 
rob said:
At 11:09 AM 3/20/2007, you wrote:
This is somewhat related to my question in the Developer's Kit query about renaming a cloned data set. what I'd like to know is how one goes about creating an ultra-customized d20 dataset using the d20 core mechanic but a completely different set of skills, spells, etc.
You can currently do two things within Hero Lab that are not very apparent and that make this possible. There is the "hidden" mechanism and the "replace" mechanism.

The "hidden" mechanism allows you to effectively remove a thing from existence within Hero Lab. For example, if I hide the "Appraise" skill, it stops appearing.

The "replace" mechanism allows wholesale replacement of a thing. This can be incredibly useful, since the replacement "cascades" through all dependencies. For example, if I replace the standard Longsword entry with a new one that does 2d4 damage instead of 1d8 (because that's how my group plays it), then every Longsword through the data files is automatically changed. That means every pre-defined magic weapon that happens to be a Longsword gains the new damage behavior with a single change.

All that being said, it would be an extreme nuisance to have to individually hide all spells, skills, etc. to come up with a completely new list. So what we should probably make available is a "d20 core" set of data files that omit all the skills, feats, etc. Then someone could start with the d20 mechanics and nothing else, adding the information he wanted on top of that. Since all of the skills, feats, etc. are available in the d20 "source" directory, it would be easy to re-use anything from that material. I'll put this on the to do list...[/quote]

Yes! That would help a great deal! (Sorry for the delay in responding, by the way: technical issues, etc.) If you could build your feat/skill/spell/classes list from scratch, that would allow the development of datasets for numerous variations of d20 (Modern, Mongoose OGL, etc.) with much less heavy lifting than the other methods.

It still wouldn't enable the pure-Point Buy variants (Anime d20, for example), but interest in those may be questionable at this time.

What sort of mechanic are you envisioning? We have plans to build a few more relatively common mechanics into the base data files, so you might be looking for something that is going to be included shortly. Also, the difficulty depends on facets of the mechanic you want to implement.

Guardians of order, in their fatal flirtation with d20, came up with two examples: a spellcasting mechanic where spells are learned and cast in a completely different manner than in D&D (which bore more resmbalnce to video-game magic than D&D magic), and a character creation system in which a system of Attributes was grafted onto several of the d20 mechanics, and you paid for attributes with character points, as well as everything else (including your Ability Scores).

For some types of mechanics, it can be done now. For others, it will require that we get the Kit documentation updated to include the details on how to define new custom "classes" and/or modify existing "classes". Doing that is not "hard", but it's multiple weeks of work to do well and that's time not actually enhancing the product itself. So that's why it hasn't been done yet and the current plan is to get it done in May (barring any surprises).

I imagine a few new licenses would count as "Surprises"....[/quote]
 
At 07:58 PM 4/25/2007, you wrote:
Quote:
For some types of mechanics, it can be done now. For others, it will require that we get the Kit documentation updated to include the details on how to define new custom "classes" and/or modify existing "classes". Doing that is not "hard", but it's multiple weeks of work to do well and that's time not actually enhancing the product itself. So that's why it hasn't been done yet and the current plan is to get it done in May (barring any surprises).


I imagine a few new licenses would count as "Surprises"....
[/quote]
Funny you should say that. :-) I can't give any specifics, but it looks like May is going to result in my personal focus being shifted to something other than documentation. :-( So this is unfortunately going to be pushed back a few extra weeks. Sorry about that, but there are only so many hours in each day....
 
Funny is not the word. happy for the success, certainly. I just wish the DK documentation were on its way a bit more quickly. Not a demand -- I know your time is needed elsewhere -- but it has been a while now.
 
At 10:15 PM 5/8/2007, you wrote:
Funny is not the word. happy for the success, certainly. I just wish the DK documentation were on its way a bit more quickly. Not a demand -- I know your time is needed elsewhere -- but it has been a while now.
I concur that it's overdue, and it's bugging me that it's not completed yet. There just aren't enough hours in the day to get everything done as quickly as I'd like. :-(
 
Back
Top