Character Sheet Phase 3 (Savage)

Context: HL Kit … Authoring Examples … Savage Worlds Walk-Through 

Overview

In this phase of developing the character sheet, we'll begin work on the right column of the sheet. This side is a bit more complex than the left side, containing both detailed sections (e.g. powers, weapons, and armor) and some interesting relationships between the different sections.

Logos

At the top of the right column of the character are the logos for both HL and the game system. These are handled automatically in the Skeleton files and there is nothing we need to do. If we wanted to stack the logos instead of placing them side-by-side, we could do that by simply configuring the orientation within the Position script for the sheet. However, we're trying to keep things compact in this character sheet, so we'll stick with the default behavior.

Eliminate Portrait Handling

The first thing we need to do for the right column is eliminate the character portrait. The Skeleton files include the output of a character portrait at the top if a portrait is specified for the character. In the interest of squeezing all the important information into the one-page sheet, we'll remove it from the sheet.

Unlike the way we handled the "Health and Power" material previously, we won't completely delete the logic for handling character portraits. We'll likely want to include the portrait in a different character layout in the future, at which point we'll want to use the logic that's provided by the Skeleton files. For this sheet, we'll simply eliminate the reference to the portrait, thereby removing it from this particular sheet without actually deleting it from the data files.

All of the logic for the portrait display resides within the "oPortrait" template. In order to remove the portrait from the character sheet, we simply need to eliminate the reference to this template from the "oRightSide" layout. This consists of deleting the "templateref" and the line of code from the Position script that places the template. Once we do that, the portrait is no longer included in the character sheet.

Edges

The next thing we need to worry about on the right side is edges. At this point, you're probably wondering why we're concerned with edges on the right side, since we already output them on the left side. The reason is that a highly complex character might not be able to fit all the edges on the left side. If there are more than will actually fit in the space at the bottom of the left column, only those that fit will be output. If that occurs, we still need to output the rest. One option for handling the extra edges is to use the second "spill-over" page for that purpose. However, edges are very important and should ideally be shown on the main character sheet, so we should output any extras at the top of the right column.

Outputting any remaining edges is actually quite easy. When generating the character sheet, HL automatically keeps track of which picks are actually output to the sheet. Each pick is output only once, which eliminates the need for you to worry about which edges have been output and which ones still need to be output. By simply re-using the existing edges table on the right side, any edges that have not yet been output will be included.

If all of the edges are properly output on the left side, then the table of edges on the right will be empty. By using the auto-place mechanism, an empty table is completely omitted (automatically) when rendering the character sheet. So the behavior we want is handled for us automatically.

This means that all we need to do is reference the existing edges table from within the "oRightSide" layout. Doing that requires adding a "portalref" element for the table and placing the portal properly. The revised layout should look like the following.

<layout
  id="oRightSide">
  <portalref portal="oEdge2"/>
  <portalref portal="oGear"/>
  <position><![CDATA[
    ~position the various tables appropriately
    perform portal[oEdge2].autoplace
    perform portal[oGear].autoplace

    ~our layout height is the extent of the elements within
    height = autotop
    ]]></position>
  </layout>

Add a bunch of edges to the character so that it will run out of room and need to spill over to the next column, then preview the character again. Everything works as intended for edges, except we've uncovered a new problem. The table of edges on the left extends down to the bottom of the page instead of being limited to the top of the validation region. By default, the "oLeftSide" layout will extend to the bottom of the page. In order to impose the necessary limit, we need to set the bottom of the layout before we render it. This consists of adding a single line of code immediately prior to the "render" statement within the Position script of the sheet, so the block of code that configures and renders the left side layout should look like below.

~position the leftside layout in the upper left corner
layout[oLeftSide].width = colwidth
layout[oLeftSide].height = extent - layout[oLeftSide].top
perform layout[oLeftSide].render

If we wanted to be truly paranoid, we could add spill-over handling for hindrances. Theoretically, if a character has enough skills and hindrances, the list of hindrances could overrun the available space on the left side. However, the feasibility of such a character in practice is unrealistic, so we won't bother.

Arcane Powers

Moving downward on the right side, we have arcane powers next. Powers need to be handled a lot like weapons are handled in the provided Skeleton files. There are a number of fields that are best placed in columns within the table. As such, we'll want to use the same approach as with the weapons, wherein we use the same template as both a header and the contents of each item. This makes it possible to easily align the header elements with the contents of the table.

For the moment, though, we're just going to start with a normal table that does not possess a special header. The reason is that trying to setup everything for both the header and contents at the same time results in a more complex operation. When both are done at the same time, you have to get everything into place before you can begin testing and refining. By implementing everything in stages, we'll simplify the process for ourselves and make it possible to get the contents in good shape before we worry about the header.