Glossary of Terms

From HLKitWiki
Jump to: navigation, search

Context: HL KitBasic Concepts and Terminology 

The Kit has an array of terminology that you'll need to become familiar with. Most of the fundamental terms are defined below. Other terms are defined as they are introduced within the documentation. The terms below are those that you will likely come into contact with in a variety of contexts during data file creation. Please familiarize yourself with all of these terms, as the rest of the Kit documentation assumes you are familiar with them.

This section provide merely a quickly summary of each term. You'll find more in-depth information on most of these terms in subsequent sections of this documentation.

unique id Just about everything within the data files is assigned a unique id (often shortened to id) that serves to uniquely identify that object throughout the data files. Each object can then be referenced by other objects based on that unique id.
hero A hero is the character that the user is creating and evolving within HL.
portfolio A portfolio represents the collection of heroes being actively created by the user. In many cases, a user will only be creating a single character, but the portfolio can encompass dependent's, henchmen, allies, an entire adventuring party, etc.
thing A thing encapsulates all of the characteristics of an object the end-user manipulates for a particular game system. These include classes, spells, weapons, skills, etc.
field Each thing can have an assortment of values associated with it. Each of these values is a field, with some fields being fixed and others changing dynamically in response to user actions during hero creation.
component All things can be grouped into sets of related behaviors (e.g. weapons, armor, spells, etc.). Each of these groupings is a component, with each component having a pre-defined set of fields that describe all instances of that component. Every thing is an instance one or more components.
component set A component set represents a collection of one or more components. Each component corresponds to a particular aspect of the game system, and component sets allow those components to be blended into useful combinations. For example, a game system might have separate components for armor and cyberwear, but some cyberwear might also be armor, in which case a component set could be defined for cyberarmor that blends the two components into a single set.
pick When a thing is added to a hero, an instance of that thing is created, and that instance is called a pick (because it will typically have been picked by the user). Since it is possible to add multiple instances of the same thing to a hero, and each instance can be configured differently, a separate term is needed for an added thing.
entity Some things are complex and highly customizable by the user (e.g. vehicles, magic weapons, etc.). When that occurs, an entity is used to describe the customizations that can be performed within a separate level.
gizmo Like picks, when an entity is added to a hero, an instance of that entity is created, and that instance is referred to as a gizmo. For example, multiple custom magic weapons can be added to the hero, each configured differently, with each being a distinct gizmo and all being based upon the same entity.
container Both heroes and gizmos hold picks. When no distinction is needed between a hero and a gizmo, they are generically referred to as a container.
portal Both on the screen and within character sheets, a portal represents a distinct visual mechanism for presenting the contents of a field or some other information to the user. Some portals will accept user input and others coordinate the presentation of large set of data through tables.
style The visual look of a game system will be standardized so that all portals of a given type will share common characteristics like color, font, etc. To eliminate the need for re-defining this information for every portal, a number of styles are defined and every portal then refers to a style for its characteristics.
template Portals are grouped into templates to describe how all of the information for a thing should be presented to the user. By defining labels and appropriate visual components to show the contents of fields, a template defines the way things are viewed by the user.
layout When presenting information to the user, templates and individual portals will need to be combined, and this is achieved through layouts.
panel On the screen, all information is organized for presentation to the user within panels, with a different tab panel corresponding to each tab across the top of the main window.
sheet A sheet corresponds to a character sheet being output for the hero, usually to the printer.
table Throughout the user-interface, the Kit uses tables to present a scrollable list of templates, wherein each item in the table presents the contents of a single thing or pick from a related set. Tables can sometimes support user-selection as well, in which case a separate selection table is used to choose from.
script The Kit provides a simple programming language through which you can define scripts that are allow you to implement the nuances of every game system.
phase Evaluation of scripts, rules, and other operations must be scheduled within the engine to occur in a controlled sequence. To this end, each game system defines a set of phases that break up the sequence into logical chunks.
priority Within each phase, priorities are assigned that control the sequence within that phase.
eval script Whenever the selection of a thing causes chain reactions to occur within the hero (e.g. a magic item that increases the wielder's strength), an eval script is written and attached that performs the necessary actions.
eval rule Every game system has an assortment of constraints that govern hero construction, such as minimum and maximum limits, allowed combinations of abilities, etc. To enforce these constraints, eval rules allow these requirements to be validated.
task Each eval script and eval rule is scheduled as an individual task within the HL engine for processing.
procedure A procedure is a fragment of a script that is defined separately and can be re-used from within multiple different scripts. For example, if a game system has multiple pieces of equipment that trigger the same basic set of adjustments to the hero, a procedure could be used to put all the logic in one spot and re-use it.
tag Each individual characteristic of a thing is identified via a tag associated with that thing. Each tag represents an individual facet of a thing, such as the level of a spell, whether a weapon is ranged or not, etc.
tag group While individual tags identify a specific characteristic of a thing, a tag group identifies a collection of related tags. For example, spells in the d20 System game system each belong to a particular "spell level", and each spell could be assigned the tag "1", "2", "3", etc. from the tag group "spelllevel".
tag expression Things will often have many different tags assigned to them. To identify the things that meet a select set of requirements, various tags will be tested for via a Boolean expression referred to as a tag expression (or tagexpr for short).
version The term version refers to the version of a set of data files (or possibly the Hero Lab product). In order to keep track of updates to data files, a version number is assigned to the data files, which is used both by the end-user and by HL to track when changes are made.
element Since the Kit uses XML for its underlying file structures, and the term element has an established meaning within XML, this term is used to reference objects that are implemented as XML elements within data files.
attribute Similar to the use of the term element, the term attribute has an established meaning within XML, so this term is used to reference anything that is implemented as XML attributes within data files.
bootstrap There are times when one thing or entity needs to automatically add additional things to the container, such as the special abilities conferred for a particular race. These automatically added things are considered to be bootstrapped by the object that adds them.
live Both structural elements (e.g. picks and gizmos) and visual elements (e.g. panels and layouts) are considered to be either live or non-live, depending on whether they satisfy various requirements. When live, an object behaves normally. When non-live, an object behaves as if it does not exist (i.e. was never added to the container or is never shown to the user).
linkage Logical associations between one thing and another can be established via linkages. This allows a script to be written for a component that is then inherited by all derived things, but with each individual thing defining a potentially different thing as its associated linkage.
dossier An ordered collection of character sheets is referred to as a dossier.