|
|
|
|
 | I have never been truly satisfied with Character Generator Tools on the internet for RPGs, as most are either ugly, restrictive, or difficult to configure for the House Rules that every game seems to employ that deviate from the Core specifications. So, I decided to design my own. Or rather, I designed how my ideal software would work to create, configure, edit and use dynamic, autocalculating Character Sheets to manage my characters and character concepts. I then realized that a Character Sheet was just a kind of Form, so this system could also be a generic Form Builder and filler.
Note that my programming skills are amateur at best (I have no experience actually coding a user-interface or building stand-alone applications), so I haven't actually made such software, just described how I would like it to work. I make no claim that this is the "One True" system, but this document is intended rather as a "white paper" to provide ideas for thought and discussion. I decided to share it publicly, in the hope that these ideas can improve existing software. Feel free to offer feedback in one of the Forums where I've announced this document (see below). If you are a software developer, you may also use any of these ideas freely, under the condition that you give me credit and either get my permission or use them for non-commercial (non-profit) purposes.
This document is written & maintained as a nested list of notes, using NoteBook software, by Circus Ponies, and exported as a web page directly from the program. I apologize if the terminology is inconsistent: it has evolved as I was writing. I've tried to edit it for consistency, and may continue to do so, as I get feedback or more ideas.
|
|
|
|
|
|
 | Flexible simple options to build Powerful Forms, that can be easily used and modified: Because many gamers have their own House Rules.
|
|
|
|
|
|
| PCGen is powerful, but the syntax is so complex and specific, that it creates a steep learning curve, rather than using simpler elements ("building blocks") to create a range of specific statements for conditionals (prerequisites), modifiers, etc.
|
|
|
|
|
|
| Would this be easier to learn how to use and therefore edit & customize characters & sheets?
|
|
|
|
|
|
| This system could also be used to build generic interactive Forms, as well as Character Sheets for RPGs: replace "Character Sheet" with "Form", and add more generic random number generator in addition to die-rolling, which is probably a good idea anyway.
|
|
|
|
 |
|
|
| A Character "file" (bundle or library) would be made of modular components (individual files), with character data separate from Character Sheet Structure & Behaviour
|
|
|
|
 |
|
|
| Template System Files (These files make up a Template, aka Form Settings?)
|
|
|
|
|
|
| Structure: field definitions, basic properties
|
|
|
|
 |
|
|
| Rules: field relationships, general modifier objects owned by form fields, rather than List Items, packages, or values of option fields.
|
|
|
|
|
|
| Behaviour: Actions, Die rolls, output, events, associated with specific fields. (Interface & Behaviour)
|
|
|
|
 |
|
|
| Presentation: Layout, skins, CSS, etc. Multiple packages possible.
|
|
|
|
|
|
| Layout: Object Sizes, absolute or relative position on a canvas, including canvas size (fixed dimensions, or boundless on-screen)
|
|
|
|
|
|
| Style: font specifications, borders, colours, backgrounds, Graphics
|
|
|
|
|
|
| Image files stored individually, grouped in one directory for each "style", referred to in the Style definitionfile.
|
|
|
|
 |
|
|
| Content: field values & associated specific modifier objects. This is the character data itself, the other components make up different layers of the Character Sheet (Form) and custom Interface.
|
|
|
|
 |
|
|
| Header information would include the associated Template name, if these files are not bundled with the Character file in a single package.
|
|
|
|
|
|
| A loaded character could have components swapped out, such as a new Presentation layer ("skin"), different rule set, actions, or character data.
|
|
|
|
 |
|
|
| The user would be able to load different rule sets into a character to quickly change game systems, so long as stat fields where not radically different.
|
|
|
|
|
|
| import rule sets from other characters, or stand-alone "rules files" (Templates)
|
|
|
|
|
|
| i.e. races, classes, etc. are a collection of rules and could be included in their own stand-alone files, as well as the basic game rules governing how character stats are related.
|
|
|
|
|
|
| separate file for each race / class "package", or can a file contain multiple packages (i.e. item, spell, compendium).
|
|
|
|
|
|
| pop-up list window to choose one.
|
|
|
|
 |
|
|
| How to handle loading multiple, redundant packages into the file?
|
|
|
|
|
|
| overwrite existing packages: each package is a defined "rules module", with its own name. If another package is loaded with the same name, it replaces any existing one.
|
|
|
|
|
|
| There may also be the facility to load a module that modifies other rule sets, rather than replaces them.
|
|
|
|
|
|
| a module with a different name ("ClassName.mod" for example) but that only contains modifications to existing rules, rather than replacing the entire package.
|
|
|
|
|
|
| PCGen does this, and it might create complicated combinations of rule priorities and sets, files, etc.
|
|
|
|
|
|
| of Packages, List Item objects, etc.: Data for individual elements (items) within Packages or List Objects in a Character Sheet.
|
|
|
|
|
|
| These include Content (Field names & values) AND Structure (associated actions, modifier objects, prerequisites / conditionals, but not field definitions) data. Possibly in separate files grouped within the Library, although this should match the configuration of Content files, since that's where this data will be stored for individual characters.
|
|
|
|
|
|
| Mismatched structure & data?
|
|
|
|
|
|
| Imported data for a field that does not have corresponding field ID in the active sheet is ignored: data that can be matched to an existing field is imported.
|
|
|
|
|
|
| Thus, you can easily add or remove fields from your sheet, and still import the data that does match from other sources.
|
|
|
|
|
|
| Similarly, If importing a new structure over existing data, do the same thing: load structure, then try to import data into structure, and any data that does not have a corresponding field name is discarded.
|
|
|
|
|
|
| Generate Alert in the log output indicating which fields are missing (ignore if you want).
|
|
|
|
|
|
| A more complex solution would be to allow the option of "conversion rules" (a conversion file), where old & new field IDs can be linked to allow data to be imported to a radically new structure, as much as is possible. If multiple source fields are linked to a single destination field, contents are concatenated, with a delimeter (line break or tab?), permitting a "dump" of data that has no direct equivalent into a text field. All other extra data is dumped into the output log (which is not saved with the character, but can be saved externally).
|
|
|
|
|
|
| Is this basically scripting?
|
|
|
|
|
|
 | Dice syntax: ndN, where either n or N is variable (literal constant, calculated, or from another source).
|
|
|
|
|
|
| Include "Fudge Dice": 4dF (or dF = -1, 0 or +1). Could other "dice variables" be defined in the rules or Action file somewhere?
|
|
|
|
|
|
| Checks, using a field's value, or other property as the net modifier: result is the output
|
|
|
|
|
|
| option to allow one-time situational modifiers (mouse click with modifier key, for example)
|
|
|
|
|
|
| Dice rolls, with threshold values, which define decision points (flow control) and may lead to further individual actions.
|
|
|
|
|
|
| Always allow opportunity to interrupt & cancel.
|
|
|
|
 |
|
|
| Prerequisites: conditional statements as part of flow control ("decision trees")
|
|
|
|
|
|
| apply result as a one-time modifier (though this may result in the creation of a persistent modifier object).
|
|
|
|
|
|
| Structurally equivalent, semantically different
|
|
|
|
 |
|
|
| A Rule is associated with Structure, and is saved in the Template files.
|
|
|
|
 |
|
|
| A Modifier is associated with Character-specific data, such as List Items (gear, magic items, feats, special abilities, conditions, spell effects, etc.), and saved with Content data.
|
|
|
|
 |
|
|
| Rules are applied before (lower priority) Modifiers
|
|
|
|
 |
|
|
| Both are defined as a Modifier Object
|
|
|
|
 |
|
|
| A Modifier Object consists of: (properties)
|
|
|
|
|
|
| = name of source field &/or Priority? concatenated with target, operator, conditions?
|
|
|
|
|
|
| Analogous to Priority, and may not be necessary, except to serve as a reference for other modifiers to target a specific modifier by name, because other properties are not fixed.
|
|
|
|
|
|
| For the same name, or pair (source, target, type, is the same), larger integer number = higher priority
|
|
|
|
|
|
| priority can also be established indirectly via generality (conditions), or type (and stacking rules).
|
|
|
|
 |
|
|
| The "owner" of the modifier: if the source in inactive, all associated modifiers are also inactivated.
|
|
|
|
 |
|
|
| or, an inactive source inactivates all modifiers that use it's value as a modifier value: except that some modifiers are fixed, but only from one source (items, feats, etc.).
|
|
|
|
 |
|
|
| Basic structural Rules are owned by Form Fields, rather than the contents of those fields (such as List Items, Packages, or Option values)
|
|
|
|
 |
|
|
| Defined within the Template Files
|
|
|
|
|
|
|
| may have no Source or Owner and describe how fields relate to each other in a persistent fashion?
|
|
|
|
|
|
| But a modifier that applies a field's value to another field is implicitly owned by the source?
|
|
|
|
 |
|
|
| what about feats: some apply only to specific attacks, and might be owned by the target, not the source?
|
|
|
|
|
|
| field to which Modifier is applied
|
|
|
|
|
|
| Can be a field, or other Modifier Object
|
|
|
|
|
|
| Prerequisites, requirements.
|
|
|
|
|
|
| Conditional statements (If [field] has a value [in a certain range], or contains certain data)
|
|
|
|
|
|
| Modifier Expression / Operator
|
|
|
|
|
|
| Expressed In terms of how the Source affects the Target
|
|
|
|
|
|
| Either explicitly (named) or ideally relatively (expression contains only the terms "Source" and "Target" or stand-ins like "A" & "B" or something.
|
|
|
|
|
|
| This assumes only a single source at a time, which is consistent with modifiers originating from the sources, but would be problematic if a field were to be defined as having multiple default, baseline sources.
|
|
|
|
|
|
| Mathematical expression / Operation
|
|
|
|
|
|
| usually arithmetic summation (add, substract)
|
|
|
|
|
|
| sometimes geometric / multiplication (multipiers stack by addition, however)
|
|
|
|
|
|
| could be the result of a field modifying another, or a field's value/contents being calculated entirely from other fields.
|
|
|
|
|
|
| Only symmetrical operations, where order does not matter can be included in single modifiers (source->target).
|
|
|
|
|
|
| +, - or only * (but not division; use multiplication by an inverse number)
|
|
|
|
|
|
| Sum or Product (Arithmetic, Geometric summation) as a property of the field?
|
|
|
|
|
|
| or multiplication is expressed simply as a value added to itself (a number of times equal to the multiplication factor?).
|
|
|
|
|
|
| Field Property / contents Operation
|
|
|
|
|
|
| add something to a list, or remove something from a list?
|
|
|
|
|
|
| contents as a string (text value) or Table list of objects.
|
|
|
|
|
|
| set properties of another field (activate / deactivate, etc.)
|
|
|
|
|
|
| One field's status alters another field's status, or modifier.
|
|
|
|
|
|
| Add a condition (activate a condition)
|
|
|
|
|
|
| losing Supernatural and spell-like abilities in a dead magic zone, for example.
|
|
|
|
|
|
| When other modifiers should NOT be applied (de-activated).
|
|
|
|
|
|
| value to be applied to property of an object.
|
|
|
|
|
|
| Active / inactive, text contents, integer value, etc.
|
|
|
|
|
|
| Integer value: fixed constant, or based on value of source
|
|
|
|
|
|
| additional child object (adding options or list items)
|
|
|
|
|
|
| Modifier Type (Tags, Keywords)
|
|
|
|
|
|
| for stacking rules, generally only the highest value modifier of any type is applied to each target, with some exceptions ("untyped": Dodge bonuses, circumstance modifiers).
|
|
|
|
|
|
| modifiers of the same type do not stack: highest value of each type is applied.
|
|
|
|
|
|
| untyped modifiers always stack
|
|
|
|
|
|
| True / False switch (Check-box).
|
|
|
|
 |
|
|
| Modifiers can be edited (In "Configure" Mode)
|
|
|
|
|
|
| Copy, Paste between Owners, Duplicate
|
|
|
|
|
|
| Edit all properties, including Value, Operator, Source & Target
|
|
|
|
 |
|
|
| Activate, Deactivate (Unless Sheet is Reset)
|
|
|
|
|
|
| The syntax should be simple & powerful: few keywords and formatting to have to learn, but many possibilities and power to combine.
|
|
|
|
|
|
| The problem with PCGen is that the syntax learning-curve is very steep, and there are too many different keywords and formatting to learn, in order to do everything you want.
|
|
|
|
|
|
| "Target" = +floor("Modifier"/2)
|
|
|
|
|
|
| if(condition is true, "Target" = -("Modifier"))
|
|
|
|
|
|
| condition1, modifier; condition2, modifier; etc.
|
|
|
|
|
|
| Active; if (conditions); Source, Target; Operator: Value
|
|
|
|
|
|
| parsing & validation required.
|
|
|
|
 |
|
|
| Priority: larger number = higher priority.
|
|
|
|
|
|
| "Priority" is only really necessary in the event of a conflict, or when order matters, not just opposing modifiers that cancel each other out. Stacking rules may suffice.
|
|
|
|
|
|
| How could conflict arise? opposing modifiers that disable, then enable a modifier: the order in which they are applied determines the final result.
|
|
|
|
|
|
| Order also matters for complex math (addition AND multiplication modifiers).
|
|
|
|
|
|
| Order can also be generated (for complex math) by collecting modifiers of each type of math (arithmetic+, geometric*) into separate container fields, and then combine those fields using another type of math.
|
|
|
|
|
|
| Specific rules with more restricted conditions take priority over (applied after) general rules with fewer, or no conditions.
|
|
|
|
 |
|
|
| By Source (lower on list = more specific, overrides previous)
|
|
|
|
|
|
| No Source (baseline, general)?
|
|
|
|
|
|
| Otherwise, as encountered / entered in the rule set file, or resource of the character file. (This is the default "priority order" property of a rule, unless explicitly set by the user).
|
|
|
|
|
|
| Rich-text, or HTML & CSS-formatted
|
|
|
|
|
|
| No modifiers, or other structure, but very flexible in terms of information content.
|
|
|
|
|
|
| Images, movies, and other non-numeric, non-text data. (Character Portraits, for example).
|
|
|
|
|
|
| Essentially a link to a file that is stored within the Character Sheet's file package ("library"). Supported graphics files are displayed within the interface, otherwise, a file link icon is displayed, and the file is opened by an external program if activated.
|
|
|
|
|
|
| File and hypertext links are a kind of text data, so could go in a generic text field.
|
|
|
|
|
|
| Contains other Fields & Objects: used to create groups, panes, and modular clusters.
|
|
|
|
|
|
| Probably restricted to a rectangular configuration, like a "block", but collapsible. Panels can be created by resizing containers to be smaller than layout of contained fields, and automatic scrollbars allow frame to be moved around.
|
|
|
|
|
|
| Integer or Real Numbers (Interval), or Option value (check-box, etc.) or Text.
|
|
|
|
|
|
| Displayed as formatted text.
|
|
|
|
|
|
| May contain one or more Modifier Objects
|
|
|
|
|
|
| Not a target of Modifier Objects.
|
|
|
|
|
|
| Therefore, may contain modifier rules, but is not the target of other modifiers.
|
|
|
|
|
|
| Integer or Real Numbers (Interval), or Option value (check-box, etc.) or Text.
|
|
|
|
|
|
| Displayed as formatted text.
|
|
|
|
|
|
| Associated with an action
|
|
|
|
|
|
| Generally used to resolve actions
|
|
|
|
|
|
| Usually calculated based on other fields, as a target of one or more Modifiers and do not modify other fields, but could, if used as an intermediate step before generating a final calculation in another Summary Field.
|
|
|
|
|
|
| Therefore, may not contain modifier rules, but is the target of other modifiers.
|
|
|
|
|
|
| It might be useful to have a property for a Base Value, or Formula, calculated from a number of basic sources, using potentially more complicated math than simple addition. In some situations, this would be simpler than building a large formula piece by piece with modifier objects. A Modifier Object could easily be used to supply a single base value to it's owner, which is calculated as a result of a complex formula: only the result is shown as the "value" of the modifier, rather than all the sources in the formula. Naturally, this would not prevent other modifiers from targetting the field, as usual, but only provides a short-cut for more complex, static formulae.
|
|
|
|
|
|
| A "button" is really just a fancy text field, with custom actions defined. Hidden in "View / Print" Mode.
|
|
|
|
|
|
| Integer or Real Numbers (Interval)
|
|
|
|
|
|
| Reset value, maximum (optional)
|
|
|
|
|
|
| to track amounts based on increases & decreases
|
|
|
|
 |
|
|
| reset action sets current value = reset value, but only if a reset value is defined.
|
|
|
|
|
|
| Display as Text (numeric value), check boxes (Integers ≥0 only), "bar" (current as % of max; Integer or Real values), or icons (= to checkboxes or discrete version of bar)?
|
|
|
|
|
|
| with reset values: hit points, ammo, uses per [time period]
|
|
|
|
|
|
| no reset values: [class] Level, XP
|
|
|
|
|
|
| Integer values only (Ordinal)
|
|
|
|
|
|
| 2 values (properties, sub-fields, or paired fields?):
|
|
|
|
|
|
| automatic count of other fields and/or their values.
|
|
|
|
|
|
| simply a count of appropriate items. As they are added & removed, this value is calculated automatically.
|
|
|
|
|
|
| target of modifiers: modified by class, level, etc.
|
|
|
|
|
|
| If current used > Max, you have done something wrong (indicated by non-interrupting alert / conditional formatting).
|
|
|
|
|
|
| optionally, this restriction can be enforced, but it would be nice to override if necessary.
|
|
|
|
|
|
| An Object that contains a list of other objects that all share the same structure. Unlike a Container, which is like a single item in a list, and contains many different field objects.
|
|
|
|
|
|
| Each List Item (Row, record or element) is a container field that holds consistent field types (columns) within each instance. Each cell is still it's own field with properties, value, etc.
|
|
|
|
|
|
| Each List Item, as a container object, has it's own set of properties (modifier objects, active status, Actions) that are inherited by the sub-fields consistent in each row.
|
|
|
|
|
|
| View option: as Table or Sub-Form.
|
|
|
|
|
|
| Could look like a table if fields are arranged linearly in a row (with labels only at the top, as column headers)
|
|
|
|
|
|
| Essentially a min-database.
|
|
|
|
|
|
| Equipment, Skills, Feats, Spells, Special Abilities, Conditions.
|
|
|
|
|
|
| List of Powers, or attacks, or even spells, for example: each record is a sub-form unto itself.
|
|
|
|
|
|
| A List Object is defined by the fields that make up the "columns", and the relationships between them (default modifiers & rules that are automatically applied to new rows: These are Structural Rules, rather than character-associated Modifier Objects).
|
|
|
|
|
|
| Each field in the table is uniquely identified (named) by the containing Table, row number (and name), and field name (column).
|
|
|
|
|
|
| Table Column fields become extra properties of the row objects (and can be referred to and modified as such).
|
|
|
|
|
|
| Sort by fields (columns), ascending or descending, or Manually.
|
|
|
|
|
|
| store configurations in a separate option field: order of list items, tree structure (which items are nested within which others), and active states; no other field values. These can later be applied via actions attached to the option field, targetting the appropriate List.
|
|
|
|
|
|
| Records undefined in the configuration setting go to the bottom of the list, unchanged.
|
|
|
|
|
|
| Records in the configuration that do not exist, are ignored.
|
|
|
|
|
|
| e.g. Item configurations, spell buff suite, etc.
|
|
|
|
|
|
| though a spell suit might involve rather a set of actions that add spell effects (modifier objects) rather than re-order an existing list: This would be done with a "button", or an option field with associated actions for each defined set in the list of options.
|
|
|
|
 |
|
|
| Would have a property indicating external Library files that contain a collection of appropriate objects to be added to the table (an items file, feats file, spells file, etc.)
|
|
|
|
|
|
| Data from these files are used to build list of objects to add to the list (pop-up window, inspector, or associated list field).
|
|
|
|
|
|
| Note that the data in these external files would have to be specific to the target List (including data field names & types).
|
|
|
|
 |
|
|
| A prerequisite could be handled as a field in the list (possibly hidden), but there would have to be a way to check if the prerequisite was met: conditional formatting to highlight rules violations, but they are still permitted.
|
|
|
|
|
|
| If the prerequisite conditions refer to other basic field objects, they are "prerequisites", if those required conditions are items in a list that can change (conditions, or active feats, for example), then they are "requirements", which may be met some of the time, but not always for that character.
|
|
|
|
|
|
| Actions can be defined for adding objects (i.e. buying items applies a one-time modifier to money field, reducing the value by the cost of the item).
|
|
|
|
|
|
| But, you can always fill in a blank record with custom data (and build associated modifier objects).
|
|
|
|
|
|
| List / Table Items (rows) can contain other nested Items (rows) to build a tree.
|
|
|
|
 |
|
|
| Additional property: # of contained items
|
|
|
|
|
|
| Combine with Tracker Field to monitor container capacity.
|
|
|
|
|
|
| The left of each column will contain an "open / closed" switch (triangle / checkbox) to indicate whether contained items should be displayed or hidden (using dynamically modified CSS?).
|
|
|
|
|
|
| Contained rows are indented a small amount (first column only, 10% of the column width, for example), and possibly joined by a border.
|
|
|
|
|
|
| A table/list should not contain another table/list as row elements.
|
|
|
|
|
|
| As a list of children in the parent element
|
|
|
|
|
|
| As nested xml objects in the data itself?
|
|
|
|
|
|
| do the children store the name of their parent items?
|
|
|
|
|
|
| This is simpler, but may take longer to process.
|
|
|
|
|
|
| If all fields can contain other fields, any field can potentially be a list, or nested tree.
|
|
|
|
|
|
| complex combination of modifiers
|
|
|
|
|
|
| one label, with a cascade of associated modifiers and options.
|
|
|
|
|
|
| Class is associated with abilities, other progressions, etc.
|
|
|
|
|
|
| But spells & abilities should have class as a prerequisite, rather than a class providing abilities?
|
|
|
|
|
|
| or both, allowing default items to be included, as well as optional extras to be loaded
|
|
|
|
|
|
| or selecting objects to add from another file, without having to load every available option until needed.
|
|
|
|
|
|
| some abilities are automatic, others are selected from a list of possible ones.
|
|
|
|
|
|
| these objects would consist of a series of fields, values, and prerequisites.
|
|
|
|
|
|
| Subclasses can be generated by nesting packages: A Class package contains (a reference to) a subclass package, and so on.
|
|
|
|
|
|
| This would suggest multiple packages in a single file or library.
|
|
|
|
 |
|
|
| save as separate rules files, which would overwrite relevant section within the overall rules governing the character / sheet.
|
|
|
|
 |
|
|
| Value can be entered manually (along with modifiers, if you really want), or selected from a list of loaded options available for the package name, in the Resource Library: The selection loads a file containing a package of modifiers.
|
|
|
|
|
|
| This is the main distinction between a Package and an option or basic text field that is used as a prerequisite for other fields: A Package includes not only the name, but also a list of other modifiers (class-specific level progressions), and adds options to other fields (available powers, abilities, other class-specific options), all of which typically have the package value (name) as a prerequisite.
|
|
|
|
|
|
| Basic structure simply uses the value of a field as the value of the modifier (Basic fields), rather than the value determining which modifiers are applied to the field (Package).
|
|
|
|
|
|
| This could essentially be a script (of Actions) that adds the package file to the list of files loaded in the Resource Library for a series of Option Fields, and possibly other package fields.
|
|
|
|
|
|
| Field Properties (General)
|
|
|
|
 |
|
|
| interacts with Presentation
|
|
|
|
 |
|
|
| Affects order of associated modifiers?
|
|
|
|
|
|
| for possible filtering, grouping, or searching based on field properties, rather than contents.
|
|
|
|
|
|
| e.g. "attack", defense, utility, daily, etc.
|
|
|
|
|
|
| Drop-down menu / single choice list.
|
|
|
|
 |
|
|
| Data type (conditional on field type?)
|
|
|
|
|
|
| List of options, check box, etc.
|
|
|
|
|
|
| true/false switch (check-box)
|
|
|
|
|
|
| Single-choice (drop-down menu)
|
|
|
|
|
|
| Multi-choice (choice list)
|
|
|
|
 |
|
|
| What is contents of Lists and other container fields?
|
|
|
|
|
|
| Field Definitions, or all contained objects?
|
|
|
|
 |
|
|
| file paths to appropriate Library files?
|
|
|
|
|
|
| could be calculated using certain other fields (using a Rule).
|
|
|
|
 |
|
|
| If a field is the target of modifiers or rules (automatic calculation), it should not be edit-able.
|
|
|
|
|
|
| ability to override calculated values, until the sheet is updated again?
|
|
|
|
|
|
| If the sheet is calculating values incorrectly, you should be able to adjust the rules to fix it. That's the whole point of allowing access the rules as a separate module.
|
|
|
|
|
|
| OR, a field has a "baseline value" and "net value"; but you can also create separate fields for these.
|
|
|
|
|
|
| defines how the current field's value is applied to another field on a persistent basis (not just one-time).
|
|
|
|
|
|
| Incorporated into underlying Rules set.
|
|
|
|
|
|
| behaviours triggered by buttons, clicks, modified clicks.
|
|
|
|
|
|
| one-time modification of other field's value (until next update).
|
|
|
|
|
|
| e.g. adjusting counters or basic stats, but not targets of persistent modifiers, which would be quickly overridden.
|
|
|
|
|
|
| Could also create an entry in a list somewhere, with an associated persistent modifier (adding a spell effect to a list, with persistent associated modifiers that disappear when the spell effect is deleted).
|
|
|
|
|
|
| attached to label if field is editable, or field itself if field is locked (Net modifier Summary field).
|
|
|
|
|
|
| True / False switch (Check-box).
|
|
|
|
|
|
| True / False switch (Check-box).
|
|
|
|
|
|
| Can the value / contents be edited, or purely calculated?
|
|
|
|
 |
|
|
| This could be associated with a default action that allows contents to be edited with a specific mouse-click, overriding calculated contents temporarily. Ediing is still possibly, but round-about.
|
|
|
|
|
|
| True / False switch (Check-box).
|
|
|
|
|
|
| Layout: field size, dimensions, position?
|
|
|
|
|
|
| top, bottom, left, right, hidden
|
|
|
|
|
|
| Each field is automatically assigned a class based on it's field type, and a name/id, according to it's name property.
|
|
|
|
|
|
| names of cells in tables correspond to column name, with a number suffix corresponding to the row number.
|
|
|
|
|
|
| Each field is automatically assigned a class based on it's Active status, and other properties?
|
|
|
|
|
|
| Some properties actually determine the object type (tag), while others are constructs of the system and could be defined as CSS classes.
|
|
|
|
|
|
| Each field is a Div tag, containing a div (or p) with the label and another div for the field value & contents?
|
|
|
|
|
|
| Contents are converted to a text-box for data entry & editing? or, keep as form objects (text box, drop-down menu, etc.). The latter is perhaps simpler & results in less drastic changes during character editing, but the former may allow more flexibility in presentation.
|
|
|
|
|
|
| Selecting a Field to move, includes the larger div, containing both the field contents and label.
|
|
|
|
|
|
| Field sizes, position, order
|
|
|
|
|
|
| Order is related more to Structure
|
|
|
|
|
|
| Images: backgrounds, borders, icons, etc.
|
|
|
|
|
|
| Could load a pdf or or other graphic of visual layout, and just place transparent fields with only values showing, over top. Simple, elegant, pretty-looking printable character sheet that updates as data is changed.
|
|
|
|
|
|
| May require dummy / alias fields to collect data for display differently than for use / calculation (e.g. 3e classes & levels).
|
|
|
|
|
|
| This is the mode to change the rules of the system, or how fields are related.
|
|
|
|
|
|
| Change Rules / Edit Modifier Objects
|
|
|
|
|
|
| Change Field positions and appearance, layout (?)
|
|
|
|
|
|
| Change & define Actions for fields
|
|
|
|
 |
|
|
| Reset Character Rules: Activate All Fields & Modifiers, then reapply in specified order (some objects may become inactive as a result of later modifiers).
|
|
|
|
|
|
| This is the mode to use during play, generation, or set-up.
|
|
|
|
|
|
| Make changes: edit field contents, change options.
|
|
|
|
|
|
| Perform Actions, Roll dice, use abilities, generate output of actions, etc.
|
|
|
|
|
|
| Mode used to print, or for a simple overview without editing.
|
|
|
|
|
|
| simple view, no interface objects for making changes.
|
|
|
|
|
|
| expanded boxes, or just omit scroll bars?
|
|
|
|
|
|
| Lock View: password protected, no editing possible (including switching to other modes, changing preset layouts, or moving page breaks, etc.
|
|
|
|
|
|
| Baseline Font size for entire sheet / document, A+, A-, Reset
|
|
|
|
|
|
| Or Width, with page break lines.
|
|
|
|
|
|
| Width in linear (cm) or relative (pt) dimensions?
|
|
|
|
|
|
| preset page sizes (Letter, Legal, A4).
|
|
|
|
|
|
| based on field properties: values, tags, etc.
|
|
|
|
|
|
| A search shifts the focus to the resulting object (in flow order)
|
|
|
|
|
|
| A filter hides all objects that do not satisfy the condition.
|
|
|
|
|
|
| Save custom searches & filters
|
|
|
|
|
|
| can this be done as buttons without extra interface components?
|
|
|
|
|
|
| Should this be separate from the character content data, or joined to it? Probably the latter.
|
|
|
|
|
|
| Layouts & Style (Independently)
|
|
|
|
 |
|
|
| Could multiple "Skins" be stored in the same Presentation File? Or would Presentation have to be a set of multiple files...?
|
|
|
|
|
|
| "Raw" view displays Field structure only (no layout) as a big list tree of fields, in order, with properties and nesting structure: see CharTool and other RPTools.
|
|
|
|
|
|
| Rules, Action files, entire Templates, etc.
|
|
|
|
|
|
| Random Auto-Fill (Character Generator)
|
|
|
|
|
|
| Specify as much as you want, and this randomly assigns values to remaining option fields.
|
|
|
|
|
|
| Filling Lists would be tricky, as the user may want to specify rules for this type of behaviour.
|
|
|
|
|
|
| Should this rather be defined by some sort of script in the Behaviour File? The Script could provide more "guidance" or override a more basic ruleset for filling the form in.
|
|
|
|
|
|
| Such a feature should not overwrite existing data (only fill in the blanks), although you also would not want this to add unwanted data to a "finished" character.
|
|
|
|
|
|
| Complex tasks, such as purchasing equipment, involve adding items to a list without an explicit tracker matching it. Rules would be needed to tell the script to stop adding to the list (i.e. total value of equipment is not to exceed a certain value)
|
|
|
|
|
|
| Interface Components: in windows, or resizeabe Panes / Areas (Frames?)
|
|
|
|
|
|
| Rules & Modifiers (full side)
|
|
|
|
|
|
| Display as a collapsible pane or tray attached to the side of the character, since this is essentially character-specific structure and data.
|
|
|
|
|
|
| in raw form, as text? (optional view mode)
|
|
|
|
 |
|
|
| displayed as a Table Tree of Modifier objects?
|
|
|
|
|
|
| All modifiers, indicating source, target, and modification (expressed as operator & value, rather than raw code).
|
|
|
|
 |
|
|
| An inactive object applies no modifiers, and effectively disappears from the structure.
|
|
|
|
 |
|
|
| An inactive modifier only interrupts the link between a single source & target. That source may still be associated with other modifiers to other targets (or theoretically even the same target, but different modifications).
|
|
|
|
 |
|
|
| Including those associated with fields / objects, and baseline rule sets (those with no source?).
|
|
|
|
|
|
| Even while inactive, modifiers appear in the list of Rules, and in Target's "Modifier Tree", but are clearly indicated as inactive: Active indicator in Rules Table, or separate list of inactive Modifiers in tree, with the option to activate the sources.
|
|
|
|
|
|
| Nevertheless, some modifiers may be blocked by other modifiers or conditions other than the source being inactive. Can these be indicated without cluttering the display interface?
|
|
|
|
 |
|
|
| The whole-system "modifier tree" would display all modifiers with the selected object as a target, AND associated modifiers that target those modifiers (and so on, as a cascade).
|
|
|
|
|
|
| Potential for a complex network of modifiers (or cascading tree).
|
|
|
|
|
|
| modifiers active on a target directly
|
|
|
|
|
|
| modifiers that target the sources of those direct modifiers
|
|
|
|
|
|
| modifiers that target the direct modifiers themselves (modifying a property of the modifier object: active status, value, type, or even Target or operator, but not Source or Name; condition?).
|
|
|
|
|
|
| Can the order/priority of rules also be indicated, as sub-entries, or a separate column? One would want related modifiers to display close to each other: related by target, or priority?
|
|
|
|
|
|
| Fields & main display / interface area
|
|
|
|
 |
|
|
| Inspector (corner, beside log, under rules; or as a popup window)
|
|
|
|
|
|
| Could be a separate floating window, or attached to the Output / Log pane, with tabs for different section.
|
|
|
|
|
|
| Description of field / modifier
|
|
|
|
|
|
| selected field's properties
|
|
|
|
|
|
| Output, Event log (bottom, under sheet)
|
|
|
|
|
|
| Preferrably a separate window, which collects output from all open characters (if a stand-alone application).
|
|
|
|
|
|
| Eventually also a chat window: unless output should be separated, with the option in defining Actions to send output to either the output log or chat log
|
|
|
|
|
|
| log changes to character?
|
|
|
|
|
|
| a List of available objects to add to selected List or Package in the Character Sheet.
|
|
|
|
|
|
| list of options (equipment / items to add, class packages available, etc.)?
|
|
|
|
|
|
| Loaded from Library Files, specified within the selected List object, or files can be loaded directly by the user, as desired (and may or may not be saved in the List object to be loaded again in the future).
|
|
|
|
|
|
| Searchable and accessible by the keyboard (Tab, Enter, shortcuts).
|
|
|
|
|
|
| Adding an Item may trigger an action, but can be skipped easily.
|
|
|
|
|
|
| e.g. purchasing equipment deducts the cost from your money. Or a simple "add" action does not trigger optional actions.
|
|
|
|
 |
|
|
| In the Inspector, Embedded in the Form beside the associated object, or as a separate pop-up window (ugh)?
|
|
|
|
|
|
| as a Table List, sorted manually (default as above).
|
|
|
|
|
|
| As mega-Rule table, but filtered with selected field as Target.
|
|
|
|
|
|
| Or, just apply this Behaviour to whatever object is selected in the main window: de-selecting everything reveals all Rules....
|
|
|
|
|
|
| With the Option to filter by selected object or not.
|
|
|
|
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}
;){kind=small}