Goblin-King
February 19th, 2007, 09:09
With the expanded possibilities available in ruleset customization coming with FG 2, there has been discussion about our update policy regarding rulesets and the impact any such updates would have on custom rulesets made for the users' own use. We've had ideas about this brewing for a while now, but decided this would be a good time to ask for your input on this.
I will first point out our design goals for any improvements to the system, then outline a plan we have made, and finally make a small list of things how this would affect the average user, as well as the ruleset modification expert.
Goals
First, we want to make sure the system is as friendly as possible for casual users (from the ruleset engineering point of view). These would be people who don't have the technical skills, the time or the effort to actually get their hands dirty with ruleset modifications. They might, however, be interested in using some custom modifications, if they could simply download and install them without further hassle. The killer for people like this is an update that invalidates something in their game that they can't or don't want to fix.
Second, we would like to make it possible for people to share what they have done, without having to lock them down to one modder's creations, and without having to distribute a 10 megabyte download each time a simple modification to a basic d20 version is made.
Third, we want to keep the d20 ruleset up to any requirements and suggestions put forward by the people using it. With the updater coming in version 2, we can do this in an effective manner, but having to consider the implications on any imaginable ruleset in use that has drawn influence from the d20 ruleset might really bog things down.
Fourth, we believe that since it's quite impossible to do any updates without them having some ripple effects on modifications based on the updated systems, it's better to shift the responsibility for maintaining any custom ruleset snippets from the user using them in his/her game to the creator of the modification. I think this is especially true for anything someone might make available for download - it's only natural to check the original place where you downloaded something if it breaks for any reason.
The Battle Plan
The first possibility we want to prepare for and would like to get into swing soon after 2.0 is out, is what we've been calling ruleset addons. These would be to rulesets what modules are to campaigns. They would basically be small extensions to the ruleset files, perhaps only containing a new sheet for followers, a different version of the character sheet or improved functionality for existing features. You could install these for a particular ruleset, and select a number of them for use in your game from the launcher. The important bits are that they, by default, use most of the existing ruleset (hence not requiring all of it to be updated and not breaking down when the ruleset is updated) and you could use several at a time with them living happily together.
The second change would be the removal of interdependencies between rulesets. Currently, a ruleset can simply include a file from another ruleset folder, but this feature has not been widely used and carries the problem of invalidating the changes made whenever the original file is changed. To make this clearer to everyone, the plan would be to move from absolute filenames (e.g. "rulesets/d20/charsheet.xml") to relative filenames ("charsheet.xml"), indicating that a ruleset is a contained whole. As a positive side effect, this would also mean that you could simply copy a ruleset as a basis for an entirely new ruleset and not have to rename paths in the xml files. Copies would be independent, and updating one ruleset would not directly impact another.
The Result
Some of the implications of this system would be:
The possibility to pick and choose a set of addons that you like, regardless of if you can or want to do them yourself, or merge them by hand into a custom ruleset
Out of date addons might be individually identified and disabled if necessary
The d20 ruleset could be further developed by us, and any updating required to support the addons would fall to the addon developer instead of the individual GM. While not a silver bullet that guarantees automatic hassle free updates, at least everyone could plan ahead and know where things stand.
The base ruleset (such as d20) would ideally require functionality dedicated to supporting addons, such as dynamically adding icons (like the story book etc.) on the desktop. These could, however, be implemented as updates to the ruleset itself.
Ruleset creators could more easily pick features from available rulesets into their own.
A ruleset would be more likely to mean just that, forming a common base for a particular system, and any customizations being separate.
While individual rulesets (possibly based on d20) might be larger transfers, they would not be subject to an unclear inclusion mechanism that is not widely used anyway. Small modifications would be easier to implement.The Disclaimer
All of this is just planning and drafting at this time. Please remember that all or some of this might make it or not make it, and technical implementation aspects might change if this gets implemented.
I will first point out our design goals for any improvements to the system, then outline a plan we have made, and finally make a small list of things how this would affect the average user, as well as the ruleset modification expert.
Goals
First, we want to make sure the system is as friendly as possible for casual users (from the ruleset engineering point of view). These would be people who don't have the technical skills, the time or the effort to actually get their hands dirty with ruleset modifications. They might, however, be interested in using some custom modifications, if they could simply download and install them without further hassle. The killer for people like this is an update that invalidates something in their game that they can't or don't want to fix.
Second, we would like to make it possible for people to share what they have done, without having to lock them down to one modder's creations, and without having to distribute a 10 megabyte download each time a simple modification to a basic d20 version is made.
Third, we want to keep the d20 ruleset up to any requirements and suggestions put forward by the people using it. With the updater coming in version 2, we can do this in an effective manner, but having to consider the implications on any imaginable ruleset in use that has drawn influence from the d20 ruleset might really bog things down.
Fourth, we believe that since it's quite impossible to do any updates without them having some ripple effects on modifications based on the updated systems, it's better to shift the responsibility for maintaining any custom ruleset snippets from the user using them in his/her game to the creator of the modification. I think this is especially true for anything someone might make available for download - it's only natural to check the original place where you downloaded something if it breaks for any reason.
The Battle Plan
The first possibility we want to prepare for and would like to get into swing soon after 2.0 is out, is what we've been calling ruleset addons. These would be to rulesets what modules are to campaigns. They would basically be small extensions to the ruleset files, perhaps only containing a new sheet for followers, a different version of the character sheet or improved functionality for existing features. You could install these for a particular ruleset, and select a number of them for use in your game from the launcher. The important bits are that they, by default, use most of the existing ruleset (hence not requiring all of it to be updated and not breaking down when the ruleset is updated) and you could use several at a time with them living happily together.
The second change would be the removal of interdependencies between rulesets. Currently, a ruleset can simply include a file from another ruleset folder, but this feature has not been widely used and carries the problem of invalidating the changes made whenever the original file is changed. To make this clearer to everyone, the plan would be to move from absolute filenames (e.g. "rulesets/d20/charsheet.xml") to relative filenames ("charsheet.xml"), indicating that a ruleset is a contained whole. As a positive side effect, this would also mean that you could simply copy a ruleset as a basis for an entirely new ruleset and not have to rename paths in the xml files. Copies would be independent, and updating one ruleset would not directly impact another.
The Result
Some of the implications of this system would be:
The possibility to pick and choose a set of addons that you like, regardless of if you can or want to do them yourself, or merge them by hand into a custom ruleset
Out of date addons might be individually identified and disabled if necessary
The d20 ruleset could be further developed by us, and any updating required to support the addons would fall to the addon developer instead of the individual GM. While not a silver bullet that guarantees automatic hassle free updates, at least everyone could plan ahead and know where things stand.
The base ruleset (such as d20) would ideally require functionality dedicated to supporting addons, such as dynamically adding icons (like the story book etc.) on the desktop. These could, however, be implemented as updates to the ruleset itself.
Ruleset creators could more easily pick features from available rulesets into their own.
A ruleset would be more likely to mean just that, forming a common base for a particular system, and any customizations being separate.
While individual rulesets (possibly based on d20) might be larger transfers, they would not be subject to an unclear inclusion mechanism that is not widely used anyway. Small modifications would be easier to implement.The Disclaimer
All of this is just planning and drafting at this time. Please remember that all or some of this might make it or not make it, and technical implementation aspects might change if this gets implemented.