peterb

Most members of this board probably understands what is meant with the term “d100-system”, a system of rules designed to facilitate role-playing, which is class less, level less, has no arbitrary limits on what a character can do and which resolves in-game tasks by rolling a d100 under a threshold value. I'm contemplating a few conversion projects in which material written for use with the d20-system are converted so that they may be used with the d100-system. This means that I'll have to use the open gaming license (OGL). That license forbids any kind of compatibility statements with existing products, product lines or trademarks, unless you have a separate license to do so. It then becomes quite interesting to sort out if d100 is a trademark, and if it is – who owns it? Having searched the trademark databases of both the EU and the US I'm fairly certain that “d100” is not a registered trademark (for games in any case...). I have a very vague recollection of having seen a d100 logo on one of Chaosium's products but now I cannot verify that. Chaosium does not these days, as far as I can see, market BRP as anything else than “Chaosiums d100 system” or possibly “The Chaosium system”, which makes sense. There are quite a number of companies that also have or still does publish game systems that are similar to Chaosium's and it would therefore be very difficult to claim such a trademark and in the EU, due to our trademark laws, it's quite impossible. In the EU the mark “d100” (and d20 as a matter of fact) would be seen as generic descriptors of a certain type of game mechanics and also as the name of a specific type of dice. In both cases, using a dice designation as a trademark, would be “devoid of any distinctive character” because it “consist exclusively of signs or indications which have become customary in the current language or in the bona fide and established practices of the trade.” (First Council Directive of 21 December 1988 to Approximate the laws of the Member States relating to trade marks (89/104/EEC), art 3.1 b and d) It would therefore seem safe to use a “Compatible with the d100-system” and even using a d100 logo on any OGL publication. Which, from my perspective, is a good thing. The community could in fact benefit from “marketing” a d100 logo of it's own. It's in our own interest, as consumers, that only products that really fit our, by practice, established definition of what a d100 game is, are allowed to label themselves as “d100 compatible”. The community cannot own such a trademark (since we are not one entity and we do not act in a business context) but we could establish a mark that would have a similar effect to a trademark. In the EU we have something called collective, guarantee and certification marks. These marks are used by groups of traders or by authorities to indicate to consumers (and other traders) a guarantee that a product has certain qualities, comes from a specific geographic area or is certified by the correct authorities. A consumer group, such ours could not register such a mark (we are not traders) but we could establish a standard and create a symbol for that standard and with time that symbol would acquire some of the characteristics of a trademark. A company who markets products as d100 compatible, when they are not, could then be reported to the authorities (protection of consumer authorities) and accused of misleading advertisement, which is a quite effective weapon. This could be done already at this point in time but if there's an established standard which the community follows and companies that markets the community follows then we have established a market practice. I therefore propose that we create: a) a d100 charter, a document that spells out the minimal characteristics that a role-playing game, labelling it self as “a d100-system” or “Compatible with the d100-system” must have. a d100-system logo. c) a d100-system logo license (we assume that the logo is copyright protected). The purpose would be to establish a market standard and assign a symbol to that standard and allow, anyone, who is willing to follow the standard the right to use the logo free of charge. Comments are most welcome... /Peter Brink

First of all I should point out that these bare bone formulas have not been used in play. They are the first iteration in an attempt to reach a set of algorithms for standardizing the conversion of d20 spells to the d100-system. They are also a very rough set of rules for a type or arcane and divine magic that would seem familiar to a user of the d20 system and still work well within the d100 framework. I have no problem with a spell cost formula of 1 mp / d20 spell level + 1 mp per extension, as such. I was just worried that wizards wouldn't be able to do any decent manipulations, given that I want to limit the amount of manipulation a wizard can do with any given spell. I might worry to much. The skill system (my method 1) was really only intended for arcane magic. When tinkering with the second system I realised I could link in divine magic into it. The second system is (partly) based on the idea that a wizards ability to manipulate magic increases with skill. That's nothing strange really. I wanted to simulate this increase in skill but also to avoid having to deduct mp:s when the mage became better. So instead I had wizards start with a low mp pool, simulating that at low skill levels the mage must spend, relatively speaking, more energy on each spell. When the magic-user increases his skills the relative cost decreases, the wizard becomes more resource effective. A similar system has been implemented by Green Ronin in their publication “True Sorcery”. Since divine magic is “programmed” into the priest, he really does not understand the spell he just, somehow, knows that if he focus on an aspect of his god he can bring forth a supernatural effect. The priest's ability to do this does not increase with skill, since no skill is used. The default effect is based on the spells description. Increasing the “caster level” is an extension and costs 1 mp per level. Some spells have bonus effects based on character level. Barkskin is an example. In such cases I would use level x 10% and allow the bonus effect at those skill levels. I use 10 as a multiplier instead of 5 because having bonus effects already at a skill level of say 30% is a bit low, IMO. Not really. That's still a problem. One possible solution is to downgrade all dices one step. That is d6's becomes d5's, d4's d3's etc. The maximum amount of damage is also a problem. Limiting the amount of mp manipulated might be one way of dealing with that problem. Yes. That was my intention. I don't really like the skill based approach to resistances used by MRQ, although I can see that it has some merit in some situations. No I don't plan to do that. In any case none that would increase the chance of casting a spell or increase the mp pool. I do see uses for skills such as Knowledge [arcane lore] and such, for example when researching new spells or when analysing magic items or magical effects. /Peter

I agree. Even if some or even the major part of the spells, creatures and items that have been published for the d20 system would seem out-of-line to hardcore BRP/d100 gamers, converting them or at least by providing guidelines for conversion would greatly increase the appeal of BRP to gamers having a d20 background. If you are thinking of moving from d20 to BRP and has a great deal of d20 material, being unable to use that material would be quite some barrier. If we could help with this step we would do our community a service and existing BRP players would also benefit from being able to more easily use d20 material. I do, of course, understand that such conversion projects would not be everyone's cup-of-tea.

This post outlines two methods of incorporating spells that are originally designed to be used with the d20 game system into BRP/d100 games. Since there are a lot of material published for d20 and some of it is quite useful a conversion method could be quite handy - IMHO. The following is just a bare bone set of rules, I haven't even decided for my self which of these alternatives I like the best. Method 1: Skill based system Each school of magic is a separate skill. Spells need not be memorized. Spells can be cast from books, at double the casting time. Each spell has a difficulty rating of 0 to 45 which is subtracted from the school skill level (d20 spell level x 5). Spells costs 1 mp per two d20 spell levels, rounded up, to cast. Thus 0-1:st lvl = 1 mp, 2 -3:rd lvl = 2 mp’s, etc. Spells can be manipulated by expending more magic points. Each expansion of area, range, duration or additional targets or missiles costs 1 magic points each. Example: by default the spell magic missile creates one magic missile, adding three extra missiles costs three additional magic points, for a total cost of 4 mp’s. A wizard can only manipulate an amount of magic points equal to school skill level / 10 (rounded to nearest whole number) at any given time. Example: a wizard with a skill of 63 can only manipulate 6 magic points. He couldn’t expand a fireball (a 2 mp spell) more than 4 points. Learning a spell is a two week task that has a chance of success equal to school skill – difficulty rating. A wizard with 55% skill would need to roll 40 or lower to learn the spell fireball (DR 15). A wizard may add a week to his studies and increase his chance of success by the average of his INT and POW (rounded to the nearest whole number) percentiles. Our wizard, with INT 14 and POW 15, could thus add 14 percentiles to his chance of learning the fireball spell. Method 2: “Fire and Forget” system Casting a known, memorized, spell succeeds on a roll of 01-95. A 00 is still a fumble. Spells costs d20 spell level x 3 mp to cast. Expanding a spell costs 2 mp per expansion (see above). A wizard starts out with POW / 2 mp. Each 10 percentiles of skill in any spell school skill adds one mp. Learning a spell is a two week task that has a chance of success equal to school skill – difficulty rating. A wizard with 55% skill would need to roll 40 or lower to learn the spell fireball (DR 15). A wizard may add a week to his studies and increase his chance of success by the average of his INT and POW (rounded to the nearest whole number) percentiles. Our wizard, with INT 14 and POW 15, could thus add 14 percentiles to his chance of learning the fireball spell. Method 2: “Fire and Forget” divine magic Casting a known, memorized, spell succeeds on a roll of 01-95. A 00 is still a fumble. Spells costs d20 spell level mp to cast. Expanding a spell costs 1 mp per expansion (see above). A Priest or Shaman has POW = mp. Spells are learned from Spell Spirits. Kult spirits normally has POW equal to (spell level + spell level d3). Normal Spell Spirits has POW equal to spell level d6. Example: a priest that wishes to learn a 2:nd level spell must fight with a spell spirit with POW 2d3+2. A shaman trying to learn the same spell must fight with a spell spirit with POW 2d6.

Yes. The "Default Stat Level" and "Stat Quality" comboboxes only sets the level of the stats - not the level of experience of the NPC. Experience is governed by the "Default Experience Level" and the skill level comboboxes.

Thanks! Great that it sees some use beyond my own... Perhaps "Generator" is a misleading name. The intention is that the user has an idea of what kind of NPC he wants to create. When generating animals and other non-tool using creatures you'll get a default creature but when you create a humanoid you'll only get a "skeleton". The GM will have to decide what armour, what weapons and what skills the NPC should have. That being said some things could be better automated. Gender being a good example. In the new alpha 0.9 version gender is automatically generated. Some consideration for the race is taken, dwarfs for example are most often males... When it comes to automatically set armour and the like, I'm somewhat hesitant to add such automatic selection. I suspect that in most cases you'll end up with strange combinations and/or combinations that doesn't fit the GM:s needs. IMHO it's up to the GM to design his NPC. There is of course the possibility of adding some global options that enables or disables automatic selection of armour and weapons. I think it probably makes most sense to take that route. /Peter

New version has been posted. The alpha 0.9 has been re-designed under the hood. A d20 Character converter has been added and you can now add more skills, beyond the default set and the racial skills, when you design your NPC. The link to the zip-file is in the first post of the thread.

Chaosium of course has the text to the RQIII magic chapter and owns the rights so they could easily publish (as a PDF perhaps) a "Magic System Compendium" with additional alternative magic systems if they wished and it might be a good idea. Couldn't cost that much to produce and while it might not generate that much revenues it gives the customers/users more options and added benefits.

I've designed a excel spreadsheet called "Creature Generator" that can be used to generate NPC:s for use with BRP. At the present the spreadsheet can only create fantasy creatures. New! 2008-07-27. This is now a beta release, no new features or data will be added. If you do download and use this utility please PM me any bugs you may find - TIA. The spreadsheet can be downloaded here: Creature_Generator.zip The spreadsheet has been tested on three PC:s. It ran without problems on a Vista PC using Excel 2003 and on a WinXP also running Excel 2003. A Win98SE PC running Excel 97 could not run the macros on the spreadsheet however. It appears that VBA has changed so much that code written for Excel 2003 cannot be run in Excel 97. It also seems that most recent version of MS Office for MAC cannot run the spreadsheet because VBA has been removed from the OSX platform, and when used with Excel 2004 for Mac there are errors because I use functions that do not exists on the OSX platform. You will need to set security to medium and say yes to activating the macros of the spreadsheet otherwise things won't work. /Peter Brink Below is a copy of the information sheet of the workbook: ------------------------------------------------ Creature Generator Copyright 2006 Steve Lieb (under the title: RQ Roller) Copyright 2007, 2008 Peter Brink The VBA source code of this workbbik is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. There is a copy of the GNU General Public License on the last sheet of this workbook. You can also download a copy of the license from <http://www.gnu.org/licenses/>. The data (the contents of the sheets of this workbook) are offered to the public under the terms of the OPEN GAME LICENSE. All the contents of the spreadsheets are Open Content. All Source Code is "Product Identity". The source code is, as stated above, offered under the GNU GENERAL PUBLIC LICENSE as free software. A copy of the Open Game License can be found on the last tab of the workbook. You can also download a copy of the OGL from <http://www.wizards.com/d20/files/OGLv1.0a.rtf> BRP Generator: This is a fork and redesign of a spreadsheet called "RQ Roller" created by Steve Lieb in 2006. This version uses VBA functions and procedures almost exclusively and has a different way of handling user input. The data is however not altered very much. If you want to contact the author of this version of the spreadsheet, please send an email to peter.brink@brinkdata.se. How this spreadsheet works: By clicking the "Create Minor NPC" button on the SETUP page the user can set the properties of the NPC on a form. The choices made on the form are stored and used by function calls from the OUTPUT page. The Miniblock page is linked to the OUTPUT page. By calling a macro the user can save the contents of the Miniblock page to the Report page. By using another macro the user can save the contents of the Report page to a new workbook. The report page is then cleared. The contents of the "Data", "Weapons", "HitLocs", "Armour" and "Other" sheets can be altered by the user. The VBA procedures and functions need not be adjusted to account for such changes. Usage: 1) Click the "Create Minor NPC" button on the SETUP sheet. A Form titled "BRP Generator :: Minor NPC/Creature" will appear. 2) Fill out the form. The only mandatory field is the Creature Type combo box. All other settings can be left at default values if desired. The Location, Name and Title fields on the "Basic Data" tab are useful if you want to add some personal details about the NPC. They will all appear on the OUTPUT page. 3) Click "Create" when you are done, or click "Exit" to terminate the form. 4) When the form closes you will automatically exit on the OUTPUT sheet. You can now review the NPC and add some notes if you wish. 5) When you are done reviewing the NPC and wants to keep it, press "CTRL + SHIFT + S", this will trigger a macro that copies the contents of the Miniblock to the Report sheet. 6) You can now flip back to the SETUP page and create a new creature or you can press "CTRL + SHIFT + G" and the Setup form will appear. 7) Each time you copy a Miniblock to the Report sheet it will automatically be placed below the Miniblocks you already has created. Thus the Report sheet stores the output of the generation process. 8) When you have created all the creatures you need you can call a macro to copy the Report sheet to a new workbook. Press "CTRL +r". The Report sheet will now be copied to a new empty workbook. The entire sheet is copied, including page setup settings. The Report sheet is configured with a header and footer and the margins have been set so that three Miniblocks fit into one page. The settings are designed for the A4 format, but they can easily be altered and since the sheet and not just its contents are copied to the new workbook any such alterations are automatically "inherited" by the new workbook. The Report sheet will be cleared of all contents after the sheet have been copied to a new workbook. Now you can start generating a new batch of creatures. d20 Character Convertor: (New for alpha 0.9) Press the "d20 Convertor" button on the Setup page and a form will appear. You can enter the data of a d20 Character on this form and the data will be converted to data items usable with the BRP game system. When you are done press the "Convert" button and the BRP Generator form will appear, pre-populated with the data entered on the previous form. The converted character can now be manipulated as any other creature can, using the BRP Generator. As of alpha 0.9 the only feature that does not work is the Parser. A parser may or may not make it into the beta stage. Implementing your own house rules: Since all game system functions are implemented as VBA functions you can easily modify the behaviour of the workbook. I would recommend that you put all house rules in their own modules, for example "House rules", and copy the functions and procedures that you want to adapt to that module and prefix the copied functions with "my". Your version of the function genStat (which generates STR and CON etc.) would thus be called myGenStat. This way you could benefit from possible future enhancements of the BRP Generator. Keeping your own functions in their own module and using modified names makes it easy to move your functions to a new version of BRP Generator. The data can also easily be modified. Inserting new rows (new creature data for example) is no problem. Inserting new columns (new categories of data) could however create problems. Making the functions 100% independent of user manipulation of the data is on the "To-do" list. Revisions [table]Version|Author|Notes Beta 0.12|PB 07/2008|Bug fixes. Fixed problem with armour ENC calculation. Fixed problem with deletion of armour pieces. Fixed problem with skill level calculations when user choose to give creature converted from d20 a "default" skill. Beta 0.11|PB 07/2008|Added 450+ new creatures. Beta release. Alpha 0.10|PB 06/2008|Updated data to the standards of the new BRP book. Added the EDU stat. Changed name to Creature Generator. Licensed source code under GPL and data under OGL (previous editions where 100% GPL). Alpha 0.9|PB 04/2008|Refactored arrays as dictionaries. Refactored user-defined types as classes. Added a d20 character converter. Added default options to the setup page. Bug corrections. Alpha 0.8|PB 04/2008|Refactored user-defined type "armour" to a class. Rewrote the armour selection feature. Alpha 0.7|PB 04/2008|Added License page and the information page. Finally removed the Collection page. Fixed Report page reformat bug, Max/min racial stat values bug and armour overlapping bug. Removed cells linking to the old RQ Roller workbook. Alpha 0.6|PB 03/2008|Armour by hit location. Fixed values for stats. Min/Max values for stats. ENC calculation. Save Report sheet to a new workbook. Alpha 0.5|PB 03/2008|Moved most of the remaining calculations to VBA functions. Replaced the setup sheet with a form. Added a report sheet. Removed name generation. Alpha 0.4|PB 11/2007|Converted core functions to VBA function. 1.02|SRL 12/12|add broo diseases/chg move, chg qstaff parry base 1.01|SRL 8/10|added name generation, Miniblock format 1.00|SRL|core functions complete, working on name generator[/table]

Having some descent knowledge of licenses and law (law school student) I'd like to throw in my 2c. If you want to keep the project accessible to as many as possible I would go for GNU GPL. While the Creative Commons licenses have been specifically designed for works other that sourcecode and works very well, the CC licenses lack one feature that (IMHO) would be important in a project such as this and that is access to the "source". Even if you publish PDF-files that are easy to print people that wants to build upon your material will need the raw text in a word-processor format. You will also want to have easy access to the creations of those that spin off from this project and the GPL enables you to request the source and CC licenses don't (nor does the OGL). So I would recommend you to go with GPL. As for splitting Setting and Rules. That's probably a good idea - design wise. Statblocks aren't really copyrightable nor are rules as such so there's no real reason - legally speaking - to separate the two but it's probably a good idea out of practical reason. When designing computer software the mechanics (the code) is as much as it's possible separated from the user interface so that the UI designers can work without having to bother with the doings of the coders. Having a setting with all the details needed for play would enable people to use the setting with their favourite system. Which would make your material much more useful and allow you to target at wider audience. /Peter Brink