RPM: Beta features update

[KingofStorms]

Some of the other 20 questions could work like this:

say, question 5: "Do the creatures have magic items on them? Check all that apply:"

Now, you have a huge set of checkable circles (like the ones I had to fill out to register to this website....) below the question. They look like this:

Value/Strength:
.....Poor........So So.......Okay.......Good........Darn Good......Great!


Also, under each column like "Poor," there is a box for "How Many___?"

(Now here, under each of these columns are a pattern of the same checkboxes, such as "Potions" "Rings" "Rods" "Wands" etc..... and if I check the "Rings" circle beneath the "Darn Good" category, RPM evaluates these choices and finds the approprate magic item for our selections.... We can check any and all of the combinations and as many items as are entered in the "How Many___" area under each column are generated for each selection. Next to the "How Many___" box, there could be a checkbox for "Randomise each roll?" to make sure if we put 3 down, we don't get 3 of the same exact thing.

Using this system we could easily fill our enemies with potions of varying potency, rings, etc.... now just expand on this for each of the 20 questions, including equipment, treasure (gems, etc..) until you are satisfied with what you think the results will be....

Just thought I'd elaborate on how this would work.... hope it made any sense....

Later!

 

[meatpopsicl3]

Equiping through Math...

LUKE:

Large groups of creature or NPC generation could be done like this: (I apologize if this turns out to be too confusing. I think I could actually create the screens quicker in Photoshop to SHOW you what I'm talking about than to describe them, but oh well...)

Step 1: THE 20's FORM...
QUOTE]

I've run into similar problems in object-oriented programming -- my solution was to build "interfaces" for the various factors that could effect what equipment is available, then take the NOR function of all the interfaces to come up with the final filter, apply that filter to the Equip list (or sublists) and then pick randomly from the filtered subsets.

OK, I know that made little sense, probably, so I'll break it down:

The class "Druid" has an armor "interface" that specifies "No" for the "Metal" quality -- you might store this as a 32-bit number, whose binary representation represents a series of 1 or 0 's (Yes or No) for a particular qualities. Storing the Yes/No combination as a 32-bit number is how you get the speed...

at the same time...

The feat "Shield Proficiency" has an armor quality as part of its interface that specifes "Yes" for the "Shield" quality, etc...

now, the NOR function of all interfaces (Race, Feats, Classes, Level, etc...) will create a final filter where all interfaces must specify a non-zero in order for the final filter to be non-zero. In other words, if one of your your Feats specifies a NO, but all your other interfaces specify a YES, you still get a NO. All the interfaces have to be YES in order to get a YES.

So how would you do this in RPM? You would need to add an "interface" field to every item, feat, skill, class, race, etc that specifies which equipment that quality allows (1) or disallows (0).

So, how is this extend to d20? Well, when people add new races, classes, whatever, it puts the burden on THEM how to specify what kinds of equipment work with it... Hell, you sould start with a relatively small set of qualities like 20 or so, and leave a whole 12 available for others.... say someone wants to use RPM for Star Wars and they want Jedis to have a strong preponderance for Light Sabers -- well, lookey here, they just take the 21st bit and call it the "Light Saber" bit, and then set that bit to 1 for Light Sabers and for Jedis... now, when equipment is chosen, any light saber could be availble for any Jedi...

 

[Luke]

Re: Equiping through Math...

I've run into similar problems in object-oriented programming -- my solution was to build "interfaces" for the various factors that could effect what equipment is available, then take the NOR function of all the interfaces to come up with the final filter, apply that filter to the Equip list (or sublists) and then pick randomly from the filtered subsets.

OK, I know that made little sense, probably, so I'll break it down:

That's understandable. Thanks.

I see how you can build up a list of allowable equipment, but I still don't see how you get the relative chances appearing, since we seem to be examining the entire (in this case) set of weapons.

So, if you happened to have a level of Druid somewhere amongst your multiple classes, and you knocked out weapons until you were left with just the non-metal ones, the relative chances of selecting a particularly druidic weapon might not be any greater than selecting a particularly undruidic wooden weapon.

The ability to have multiple classes makes the problem very interesting. You might construct tables that had different magic items and probabilities for different classes, and give a roll for each one (perhaps based on class level). Whilst that works okay for wondrous magic, it's quite different for weapons, where you're likely to focus one just one particular weapon. A weapon chance would take the racial bias, and all the different class levels bias into account.
I don't like the approach of *coding* equipment generation differently from, say potions, since that's looking at the problem through D&D goggles. If you're running a sci-fi genre, the specifics are quite different (and the restrictions likely to be much more important).
It's a more clear example of how "examine all items" doesn't actually give you sensible chances of one compared to another, once you know what your final item set is.

All very heady stuff. I'm beginning to see possibly why Jamis Buck never did the equipment generation for his NPC generator...

This is also starting to seem like "instant generation" will get slower and slower. Is the answer perhaps to not try and get too clever? Just throw out something semi-reasonable, and leave it to manual tinkering?

Thanks Guys!

 

[Cergorach]

Luke,

Let's concentrate on the basics, or the beta release will be many months away... If someone really wants the complex tables described above, they can as long as the basics are in.

 

[Alessio Pauri]

I'm downloading RPM now, hoping the net to be not too slow today.

Meanwhile I'm reading this forum, and even if I only saw screenshots and read messages, there is a question I would like to ask. Maybe it's ok already, but since it is a tricky point, who knows? The question is: if a sorcerer or wizard takes divine oracle or sacred exorcist Prc he gains the domain (divination or exorcism); in RPM does he gain the domain as he have to? Note that he should also acquire knowledge of all domain spells from 1st to 9th level.

Hope I could help more than this in the future.... grrr I hate to have such a slow connection!

 

[smetzger]

Originally posted by Alessio Divine Oracle and Sacred Excorcist are not OGL/OGC material so they don't 'ship' with RPM.

You would need to input this stuff yourself and then do the appropriate scripting to support the special abilities.

*:> Scott

 

[Alessio Pauri]

Thanks! I didn't know that. But what exactly is in OGL/OGC material? If I want to add something myself is it difficult or not?

PCGen has a database with all this stuff; did it acquired some special licenses? Is it possible to import PCGen Database into RPM?

 

[Leopold]

Thanks! I didn't know that. But what exactly is in OGL/OGC material? If I want to add something myself is it difficult or not?

PCGen has a database with all this stuff; did it acquired some special licenses? Is it possible to import PCGen Database into RPM?

we do not have a 'database' per se of information. Each .lst file is loaded into the applicatioin when the user selectes the sources to load. It is then stored in internal memory until released. This way we don't have a proprietary database that can't be run on every OS out there.

as for the licensing: We are on a LGPL which is a subset of the GPL license for software. The OGL/OGC issue is complied with by going to the publishers, showing them our works, explaining the benefits of pcgen and what it can do for the company and players alike and then putting the informaiton into a .lst file (list file) and then loaded into the program. This alllows the publisher to see their work in clear unencrypted text layout without a special utility (notepad views it just fine). In this way we show we are not modifying their PI/OGC/OGL material in anyway.

As for the import into RPM, It would be nice. Myself and Luke have talked about it and we might be able to come up with something. There are a few more tweaks we are going to do first and then I think RPM and PCGen might be able to work together.




ps. None of this is gospel unless the benevolent dictator merton_monk says so, all praises be him, and may he have code monkey snacks (patent pending) forever....

 

[Cergorach]

As for the import into RPM, It would be nice. Myself and Luke have talked about it and we might be able to come up with something. There are a few more tweaks we are going to do first and then I think RPM and PCGen might be able to work together.

YES! You guys rule!

Where can i send my wishlist ;-)

 

[Leopold]

YES! You guys rule!

Where can i send my wishlist ;-)

hahaha it still must be approved by the powers that be and we shall see what happens....