Cast members are the denizens of the world, encompassing NPCs, monsters, spirits, drones, or anything else that gets created via Hero Lab Online. The basics of cast members have been covered in other articles. This time, we delve a little deeper into various aspects of cast members to help get the most out of them.

Cast Member Properties

Every cast member has a few properties that have important implications within the campaign and influence behaviors within Campaign Theater.

Global or Script/Local

There are two classifications for cast members: global to the entire campaign and local to a script. Where and how a cast member is created dictates whether it is global or not. The implications of this distinction are significant and are therefore detailed in a completely separate section below.

Uniqueness

Every cast member has a uniqueness property that indicates whether there is only one of this cast member in the entire campaign or possibly many. If there can be multiple identical instances of a cast member, it's obviously not unique. At the other end, any character that is worth giving a name is a unique cast member. Characters without names may also be unique cast members, such as the lieutenant the PCs interact with at the fort, or the detective that questions them, or the street urchin they pay for useful information. It really depends on more subtle factors for those examples, and that's something that must be assessed on a case-by-case basis.

The fundamental implication of uniqueness is whether there can be more than one, which manifests in a number of situations:

• Uniqueness dictates whether a quantity can be assigned to the cast member when it appears in a scene.
• Uniqueness impacts whether a cast member can be manually added to the stage more than once. For example, a unique cast member can appear in two different scenes. If both of those scenes are enacted at the same time, the unique cast member will not be added by the second script, as it's already on the stage.
• Only non-unique cast members will have jersey numbers assigned when they are placed on the stage. This is done even if a single instance of the cast member is added, since it's always possible to add it again.

Note: Global cast members are assumed to be unique unless specified otherwise.

Persistence

When a cast member is placed on the stage, a proxy is created instead of using the real cast member. Changes are then accrued on the proxy as the scene plays out. Only when a scene is resolved will those accrued changes potentially be saved back into the actor. What determines this behavior is the persistence property, which works as follows:

• PCs are always considered persistent and saved
• Global cast members default to non-persistent¹
• Script-based cast members are always non-persistent and have the accrued changes discarded

Stickiness

Whenever a scene is resolved, the stage is automatically cleaned up in preparation for the next scene. As part of this cleanup, various cast members are removed from the stage, while others are retained. Whether a given cast member is retained is dictated by its stickiness property, which behaves as follows:

• PCs are always considered sticky and retained on the stage
• Global cast members default to sticky²
• Script-based cast members are never sticky and always cleared from the stage

Allegiance

Every cast member has an allegiance towards the PCs, which influences how it behaves regarding them. There are three allegiance designations:

• Ally - Friendly towards the PCs and is inclined to assist them in some manner
• Enemy - An established enemy of the PCs that will seek to thwart or harm them in some manner
• Neutral - Ambivalent towards the PCs

If a cast member doesn't know or care about the PCs personally, such as a wild animal, the allegiance can be used to identify the general attitude the cast member has towards the PCs when they meet. So a wild animal might be an enemy if it's hungry and stalking the PCs as prey, or neutral if it's just minding its own business, or could even be an ally in certain circumstances.

Note: All cast members are assumed to be Neutral unless specified otherwise.

Status

Most campaign elements have a status property, and cast members are one of them. An element's status indicates its level of involvement within the campaign and has one of these four behaviors:

• Active - Fully visible and available for use
• Retired - No longer needed on a regular basis and therefore hidden from normal view; Can only be viewed (not editable)
• Trashed - No longer wanted and marked for deletion when the trash is emptied
• Deleted - Deleted from the system and no longer accessible in any way

All cast members start out with the Active status and must be explicitly downgraded or upgraded by the GM.

Global Versus Script Cast Members

The question of whether a given cast member should be created as global or local to a specific script is an important one. The goal behind placing cast members directly within scripts is to avoid cluttering the list of global cast members with creatures and characters that are only used in one scene. That way, the pool of supporting cast is kept much more manageable, especially as a campaign grows over time.

The gotcha is that the decision isn't always clear. Some cast members are obvious, such as the primary villain throughout a story arc. Or key allies that the PCs will work with on multiple occasions. At the other end of the spectrum, the five goblin guards that are meant to be dispatched quickly are clearly local to the scene and therefore the script. Many, however, will end up in the grey zone.

To help with the determination, the following questions can be used to assess the handling for a particular cast member.

Will the cast member appear in multiple scenes?

If the answer is yes, the cast member should typically be created as global and then linked into the scene scripts where it appears. By making it global, it only needs to be created once, and any changes made to it will be automatically incorporated into each scene where it appears.

This rule can even be extended to unmodified creatures pulled from the Vault. Making a single copy from the Vault and then re-using it across many scenes affords the option of going back and customizing the creature in one central location. For example, a stock Goblin comes with a standard weapon that will appear on every goblin in every scene where it is used. If you decide the goblin tribe uses a different weapon, all the scenes where the stock goblin is used must be modified. If a link is instead used to a global cast member, the change can be made in one place and it propagates everywhere.

Note: To use this technique, remember that the global cast member must be designated as non-unique so that quantities of it can be added to any scene.

Does the cast member actually appear in a single scene where only the scene recurs within the story?

This is an important exception to the previous question. It arises when there is a character the PCs will interact with multiple times but always in the same context. An example might be the merchant that the PCs will be buying and selling gear from/to throughout a story arc. The merchant is always encountered within his shop, along with the same security each time. In this case, the cast member may have a unique name, but it only exists within a single scene. As such, the cast member can be created within the script, and the scene itself is what gets re-used during the campaign.

Is the cast member a mook that is expected to be dispatched (usually killed) within the scene?

Cast members that fit this description are excellent candidates for keeping local to the script. The exception here is the situation outlined above, where a global cast member can be used to enable customizations across all instances of the mook.

Is this a customized mook that will be used with the same customizations in other scenes?

This is a corollary of the first question posed above. It applies when the mook has customizations, and those same customizations are desired in other scenes. In this situation, it's always best to create the mook as a re-usable global cast member that contains those customizations and is linked to the various scripts where it appears. This approach has the added benefit of allowing those customizations to be tweaked in one place after the cast member has been linked to scripts.

Personal equivalent of Vault

The concept here is to establish a pool of re-usable, global cast members as a personalized version of the Vault. Optionally customized versions of characters and creatures from the Vault can be prepared in advance. When actually needed, they can then be used in any scene by just linking them in. This is a handy technique for managing tailored mooks like cultists, city watch, bandits, security guards, bar patrons, beggars, and the like. It's also handy for cherry-picking a collection of monsters for re-use in the same way.

Different Types of Cast Members

Cast members can be created with a variety of types and behaviors. The exact list depends on the game system. An overview of the character types supported for each game system is outlined in the sections below, along with notes on how/when to utilize them.

Starfinder Cast Types

Pathfinder-Specific Types

Shadowrun-Specific Types

Stand-In PCs

The Stand-In PC is a special type of cast member that can only be created from the "PCs and Players" tab. However, it's discussed here briefly because of its importance as a cast member type in certain campaigns.

The core purpose of a Stand-In PC is to establish essentially a placeholder when a player doesn't use Hero Lab. By introducing a "stand-in" for that player's PC, a simplified version of the character can be tracked everywhere within in the campaign. The benefits are two-fold. Important details about the PC can be recorded where they can be readily referenced by the GM during play. Additionally, the PC shows up on the stage along with everyone else so that the initiative order can be easily managed and everyone can monitor basics like the health of the PC.

For more details, see Running a Game Where Not All Players Use HLO.

Putting Cast Members to Use

Once a global cast member is created, there are typically two options available to put it into use within the campaign:

• A cast member can be manually added to the stage in certain situations where it wasn't expected to be needed.
• The cast member can be linked into the scripts where it appears. For example, a major villain and his lieutenant can be linked to the script for the big battle where the PCs will encounter them together.

Let's take a look at a concrete example of how cast members (global and local) might be leveraged in a commonly occurring scene. The goal is to setup a scene for Pathfinder with a goblin leader (a warchanter) and his retinue of six goblins warriors.

Both of these creatures is available from the Vault, so the most expedient way to implement this is with a pair of local cast members within the script. Once the scene is created, add a new cast member from the Vault and select the leader. Then add the warrior and set the quantity to six.

Let's say the goblin leader is a recurring foe that is expected to escape, so the PCs will have to deal with him again in a later scene. In this situation, the leader should be created as a global cast member outside the scene, and it can then be linked to each scene where it appears. The first of those scripts would also directly include his disposable goblin minions, just like was done above (instead of being linked).

Goblin warriors are usually equipped with a dogslicer as their weapon. What if we wanted these goblins to hail from the infamous "spear-chucker goblins" clan? And what if there were multiple scenes with these goblins? We could manually revise each goblin that gets added to each script, but that quickly gets quite tedious. So we instead create the "Goblin Spear-Chucker" as a global cast member. We do that by importing the Goblin Warrior from the Vault as a global cast member, then editing it to change its name and swap out the weapon. We also need to make sure to mark it as non-unique.

Now that we've got our Goblin Spear-Chucker cast member, we can revise the script for the initial scene. The old Goblin Warrior can be deleted and replaced with a link to the Goblin Spear-Chucker. We now have a scene that is comprised of two linked, global cast members. If we go back and edit the global cast member, those changes will be automatically incorporated into the goblins in the script.

Organizing Global Cast Members

The number of recurring cast members in a campaign can vary widely and can easily become large as a campaign evolves over time. To make it easier to manage all these cast member, Hero Lab allows the creation of folders.

The folders in Hero Lab work similarly to the folder system on whatever computer you're used to using. There is a "root" folder that's pre-created and contains everything. New folders can be created in a nested manner to establish a hierarchy or tree structure.

When determining what folders to create, the most important thing to consider is what type of structure would make the cast members in your campaign more easily accessible. One possible approach might be regional, organizing the cast by the region they appear within. Another approach might be grouping cast members based on how challenging they are. Still another approach might be temporal, with cast member organized based on when they were involved in the story's timeline. If the campaign is large enough, perhaps a combination of these approaches would work well. Or maybe an entirely different approach is warranted. Whatever you decide, it needs to be a structure that works well for you, and these ideas are just food for thought.

One thing to keep in mind with cast members is retirement and the Retired status. Every cast member starts out with an Active status and is visible everywhere. In a long running campaign, most cast members from the opening story arc are usually irrelevant in later arcs. To assist with this, cast members that are no longer of interest to the unfolding story can be retired. When retired, a cast member is hidden from view by default. This makes retirement a convenient tool to hide cast that are no longer relevant, retaining them only for historical reference.

Note: If necessary, a retired cast member can be recommissioned and returned to the Active status again.

Other Tips

Occasionally, a cast member's true nature will need to be concealed from the players. By default, a cast member's basic nature (e.g. human or goblin) will be shown on the stage and visible to the players, and that's helpful in most cases, especially when there isn't a good portrait available for the actor. However, this behavior is a problem when the cast member is a vampire masquerading as normal human or a doppelganger transformed into an elf. The solution is to fill in the "Appears As" override field on the Profile tab within the cast member. When specified, the value entered in the "Appears As" field will be displayed on the stage instead of the actual creature type, allowing you to provide whatever you want portrayed as the nature.

Caveats

1. At the time of this writing, persistence is not yet customizable, so global cast members are always non-persistent for now.

2. Like persistence, stickiness is a not yet settable, so global cast members are currently always sticky.