Character Sheet Design (Savage): Difference between revisions
(One intermediate revision by the same user not shown) | |||
Line 36: | Line 36: | ||
Once our sketch is complete, we can take a final look at it to see if there are any problems. We'll take this opportunity to walk through the design here before we start implementing the changes. | Once our sketch is complete, we can take a final look at it to see if there are any problems. We'll take this opportunity to walk through the design here before we start implementing the changes. | ||
Our goal is to fit everything onto a single page, just like all the character sheets provided on the publisher's website, and we'll use portrait orientation for the sheet. Since the Kit makes it relatively easy, we'll also provide a second spill-over sheet, just in case a particular character is too complex to fit on one page. We'll use the two-column format that is already provided for us by the Skeleton files in the interest of getting something working quickly. | |||
Down the left column, we'll show the following sections, in this sequence: basic information, attributes, derived trait, skills, racial abilities, hindrances, and edges. In some case, not all the edges will fit, so we'll wrap those to the top of the second column, if necessary. The second column will contain powers, weapons, armor, gear, injuries, and a place to track the character's condition and power points. | |||
Since we're using a two-column format, there are quite a few sections where we won't be able to use the space very efficiently. For example, attributes, derived traits, skills, and gear definitely don't need a full half-page of width. Consequently, we're going to use a two-column table for those sections, which ought to work nicely. The gotcha with this approach is with skills, since we also need to handle Knowledge skills, for which the domain needs to be shown. That won't fit within a two-column table. So we'll have a separate table of Knowledge skills that uses one column beneath the regular skills in a two-column table. That should keep things both compact and clear. | |||
The other odd cases are the injuries table and character condition tracking. The injuries table can be short and sweet, and the condition tracking can be squeezed into various places. So we'll use a narrow table for injuries at the bottom of the right column and put the condition tracking details to the right of the injuries. | |||
We've got a basic plan mapped out, so we're now ready to start implementing our character sheet. |
Latest revision as of 17:42, 16 January 2009
Context: HL Kit … Authoring Examples … Savage Worlds Walk-Through
Overview
It's finally time to shift our focus to a character sheet. With HL, you are not limited to a single character sheet. You can create various designs, with a one-page sheet that is highly compact, another that is a detailed portfolio, and yet another that is a two-page balance of the previous two (that users can print out two-sided). For the purposes of the walk-through, we're only going to create a single character sheet, but the process will be basically the same for any character sheet you choose to create.
Choosing the Layout
There are two important factors you need to consider when designing the layout of your character sheet. First, most game systems have a "standard" character sheet that comes in the rulebook or is made available on the publisher's website. Providing a character sheet that is similar to the standard format is generally a good thing, since it provides the user with a familiar reference. The user instinctively knows where to look for information, since it's in the same place he's used to finding it.
The second factor to consider is that the standard character sheet provided by the publisher is designed for use throughout the life a character and that will work for all types of characters. As such, it includes lots of space that will be unused for various character types, and it also includes information that will actually make the character sheet more distracting for the user.
Let's look at Savage Worlds for some examples. The character sheet in the back of the book has sections for hindrances, edges, skills, and powers. However, if you create a character with no powers, that powers section is irrelevant. Same for hindrances. If you create a character that emphasizes skills instead of edges, you may run out of space for skills, and all the space for edges is wasted.
Each attribute and skill entry on the character sheet shows all of the different die types. This makes it easy for a player to mark the appropriate die type for each. However, your data files already know the proper die type to use and can show just that die type. Showing all the different die types provides no useful information to the user and clutters up the character sheet with additional "noise".
Clearly, the second factor is directly contrary to the first one here. Your task is to find an appropriate balance between these two competing priorities. There is no "right" answer, so you'll just have to use your best judgement.
There is a third factor that you should also keep in mind. Since HL has all of the calculated information for the character, you can readily include those calculated results on the character sheet. You can also include details about abilities, weapons, etc. Many character sheets provided by publishers only provide a place to enter the names of items, with little room for the details. So there may be times when it's more useful to include information that the standard character sheet omits. Since you obviously play the game, think of the information you want to have available to you. Also, remember back to the first time you played the game, since new players often find it helpful to see information that an expert has already memorized.
In the case of Savage Worlds, the design task become even more complex. While there is a single character sheet in the back of the rulebook, there are a dozen more character sheets provided on the publisher's website. Each of these sheets provides all the core material, but there are a wide variety of layouts used. As such, there really isn't a "standard" sheet that we can use as a guideline. We'll just have to figure something out that seems to work well.
Designing the Sheet
The first two things we need to decide are the number of pages our character sheet will contain and whether we'll be using a portrait or landscape orientation for our sheets. All of the character sheets provided by the publisher are a single page, but they also preclude the inclusion of lots of helpful information that can be useful during game play due to the compact format.
At this point, it's generally best to pull out a few blank sheets of paper and start sketching until you settle on what you think is best. You can draw rectangles where various tables of information will appear on the sheet to give yourself a good idea of how everything will be laid out. Be sure to try a few different ideas, just to be sure that the one you pick is your favorite.
When sketching, keep one important detail in mind. Character sheets in HL are adaptive, which means that tables will size themselves based on the information that needs to be output. The best way to leverage this adaptive behavior is to have your character sheet flow in columns. That way, if the information in one table is short, the next table will follow immediately below it. If a table is long, then the following table may get pushed into the next column. The use of two or three columns is best for portrait orientation, while three or four columns are best for landscape orientation.
Another factor to keep in mind is how much time and effort you want to invest in implementing your character sheet. The Skeleton files provide a framework for a character sheet that will often work reasonably well for most game systems. The provided sheet strives to put all the information on a single page in a two-column format using portrait orientation. If not all the information fits on the first page, a second "spillover" page is output that contains whatever information remains to be output. You can see how this looks by loading the Sample game system, creating a character, and then previewing the character sheet.
One option to consider is using the provided framework for an initial character sheet that you can develop quickly, after which you can go back and create a second character sheet that is more in line with what you think is ideal. Given that this is our first character sheet, we'll adopt this approach. We can then sketch out our design on a sheet of blank paper and get the implementation underway.
Reviewing The Design Sketch
Once our sketch is complete, we can take a final look at it to see if there are any problems. We'll take this opportunity to walk through the design here before we start implementing the changes.
Our goal is to fit everything onto a single page, just like all the character sheets provided on the publisher's website, and we'll use portrait orientation for the sheet. Since the Kit makes it relatively easy, we'll also provide a second spill-over sheet, just in case a particular character is too complex to fit on one page. We'll use the two-column format that is already provided for us by the Skeleton files in the interest of getting something working quickly.
Down the left column, we'll show the following sections, in this sequence: basic information, attributes, derived trait, skills, racial abilities, hindrances, and edges. In some case, not all the edges will fit, so we'll wrap those to the top of the second column, if necessary. The second column will contain powers, weapons, armor, gear, injuries, and a place to track the character's condition and power points.
Since we're using a two-column format, there are quite a few sections where we won't be able to use the space very efficiently. For example, attributes, derived traits, skills, and gear definitely don't need a full half-page of width. Consequently, we're going to use a two-column table for those sections, which ought to work nicely. The gotcha with this approach is with skills, since we also need to handle Knowledge skills, for which the domain needs to be shown. That won't fit within a two-column table. So we'll have a separate table of Knowledge skills that uses one column beneath the regular skills in a two-column table. That should keep things both compact and clear.
The other odd cases are the injuries table and character condition tracking. The injuries table can be short and sweet, and the condition tracking can be squeezed into various places. So we'll use a narrow table for injuries at the bottom of the right column and put the condition tracking details to the right of the injuries.
We've got a basic plan mapped out, so we're now ready to start implementing our character sheet.