Automatically Adding Picks to Actors

Context: HL Kit … Advanced Authoring Concepts 

Overview

When a new actor is created, it is a virtually empty container. Exactly one thing is automatically added to each actor. It's the "actor" thing that is automatically created for you by the Kit. Other than that, an actor is empty.

So what about all of the various details that are a fundamental part of every actor? Every actor clearly needs to possess all of the basic attributes for the game system (e.g. strength, intelligence, etc.). In most games, the set of skills is pre-set, so those should be part of each actor, too. Every game system has its own unique set of things that should be a basic part of each actor. However, the Kit has no way of knowing what those particular things are for each game system.

To deal with this, the Kit provides three separate mechanisms for specifying which things should be automatically added to every actor. Each mechanism works slightly differently and is intended for use with different types of things. Together, they should make it easy for you to pre-configure every actor with all of the picks that is needs. The topics below describe each of these mechanisms.

Bootstrapping Behaviors

Whenever you add a thing to a container automatically, the resulting pick is referred to as a "bootstrapped" pick. Correspondingly, the overall process is referred to as "bootstrapping", and there are a number of important implications associated with bootstrapping.

You can bootstrap picks from a variety of situations. The most common situation will be when you have one thing bootstrap another. This will occur when the game system has an assortment of abilities that are conferred by a variety of sources. For example, consider the "low-light vision" ability within the d20 System. This ability is conferred by multiple different races. You could separately implement this ability for each race, but it would be much easier to define the ability once and have each race simply bootstrap that ability.

When a pick is bootstrapped by another pick, the pick that does the bootstrapping is referred to as the "root" pick. The root pick has complete control control of the bootstrapped pick. If the root pick is deleted, the bootstrapped pick is also deleted. If the root pick goes non-live, so does the bootstrapped pick. The bootstrapped pick still has its own independent existence, but that state is wholly dependent upon the root pick as well.

This raises the question of what happens when the same thing is bootstrapped multiple times by different root picks. The answer depends on whether the thing is designated as being unique. If not, then separate, independent picks are added by each root, and their behaviors are not linked in any way. However, if the thing is designated as unique, then only one pick is ever added, and all of the bootstrap operations will reference the identical pick. As long as at least one of the root picks remains in existence, so will the bootstrapped pick.

There are a number of other situations in which bootstrapping of things can be performed. These situations are outlined below. In each of these cases, the dependency relationships outlined above do not apply.

• Things can be bootstrapped onto all actors when the actor is initially created.
• Things can be bootstrapped onto entities as part of the entity's definition. The bootstrapped picks are part of every gizmo created from that entity.
• Things can be bootstrapped onto entities when they are attached. The bootstrapped picks are only included on gizmos created by that thing.
• Things can be bootstrapped onto minions when they are attached. The bootstrapped picks are only included on minions created by that thing.

Adding Individual Things

Each thing that needs to be automatically added to each actor can be explicitly identified. This is accomplished via the "bootstrap" element within a structural file. This element allows you to specify the unique id of the specific thing to be added.

When you add a thing to a container via a "bootstrap" element, the resulting pick is referred to as a "bootstrapped" pick. Correspondingly, the overall process is referred to as "bootstrapping".

You can bootstrap picks from a variety of situations.

Adding Groups of Related Things

As mentioned above, each game has groups of things that should all be added to each actor. Attributes, skills, saving throws, and other traits are perfect examples. Adding these things individually would be both tedious and error prone. It would also make it more difficult for others to extend the data files by adding their own custom traits, because they would have to manually add any new things they defined.

As long as a group of things can be readily identified by tags they share in common, you have them all automatically added in a single operation. Since all related traits typically derive from the same component, and since every thing possesses a tag for each component it derives from, this requirement is usually a non-issue.

To specify a group of related things that should be added to every actor, use the "enmasse" element within a structural file. This element allows you to specify a tag expression that will identify the related things to be added.

You can also specify tags that will be automatically assigned to each added pick. While rarely needed, this can be useful when the same thing can be also added to the actor additional times by the user.

Pre-Selecting Things Within Tables and Choosers

The above mechanisms allow you to add things to an actor on a fixed basis. This is perfect for attributes and skills, but it doesn't solve all situations. Throughout the interface you design, there will be various tables and choosers where you'll want to pre-select information for the user. In this situations, the user is free to delete or replace the default selection, but one is still provided.

An obvious example is adding an empty character portrait on the Personal tab, since this visually prompts the user to select a portrait of his choice. Another possible situation is when you want to pre-select the contents of a chooser. For example, in the World of Darkness system, the vast majority of characters start out as standard humans, so it's appropriate to pre-select the characters size and speed traits as those of a human. The user is free to change the choices, but he doesn't have to always select them for each new character.

When you come upon a situation where you want to pre-select a thing into a table or chooser, you can use the "autoadd" element within a structural file. This element allows you to specify both the unique id of the thing to be added and the unique id of the portal it is added to.

Any pick that is automatically added to a portal is solely subject to the behaviors for that portal. As such, the pick may not has any Condition tag expression associated with it. In addition, all auto-tags and conditions (e.g. Secondary and Existence) that are normally dictated by the portal are also applied to the pick.