Character Data Model & Navigation Flow

Initial Thoughts

As a user, I would like a character that I can extend freely.

By standard fifth edition rules, we have a predefined set of attributes from skills to how many hit points and hit die a character has. However, in homebrew campaigns, we can be more flexible. For example, skills like stealth fall under Dexterity, but under homebrew rules, what if stealth belonged elsewhere, or in a new category altogether? What if there were other skills that we wanted to define?

Let's take gambling, for instance. Typically, it is up to the GM to classify how gambling fits for skill checks. Is the character simply just partaking in a game of cards? Perhaps an intelligence roll considering tool proficiencies like gaming sets or playing cards. Or perhaps the character is actually trying to tell a story to distract their opponents while they slip in a card to cheat. This could involve Charisma for a performance skill check (storytelling) and Dexterity for a sleight of hand skill check (slipping in a card unnoticed). While this may suffice in a standard scenario, perhaps a homebrew campaign would like to expand on gambling as its own system. Perhaps a new set of skills, or a unique category would be needed.

Defining the Data Model

The data model should be minimal, and then be expandable to consider customizing every aspect for homebrew campaigns. A user should be able to globally define new skills, tools, spells, and so on from either a screen directly associated with defining them or as part of the initial creation process. For instance, a user could define a custom tool from the Tool Management screen. When they decide to build a custom class and need to select which tools the class is proficient with, then they could define it right there. The screens should be reusable with varying contexts.

Redefining Navigation

A Tool Creation screen does not care whether the user is creating a tool directly or was in the middle of defining a class. It only cares to build the desired tool, store it globally, and then bring the context back to the next screen. Screens should be standalone in these cases.

Rethinking Character Creation

The character creation process should be no different. The first time a user creates a character, it should stick immediately after the first selection.

For example, let's suppose we're building a Dragonborn Fighter. The user would select Dragonborn on the Character Race screen and Fighter on the Character Class screen. This requires having to maintain some form of state. With H = Home, A = Action, S = Screen, we have H -> A(Create New Character) -> S1 -> S2 -> ... -> H. We essentially build up the state of this new character until completed and the activity screen stack is wiped and returned to the Home Screen.

Instead, let's have a central review page: H -> A(Create New Character) -> Review Page -> A(Select Option) -> Option Configuration Screen -> A(Confirm Selection / Go Back) -> Review Page -> ... -> H.

Benefits

• We don't deal with a longstanding state here. We create a new character slot at A(Create New Character). We delete the slot if the user backs out with 0 customization. Otherwise, we continue to update the character template we've set up with the options the user configures.
• The user knows what options are available upfront. They can back out and pick up where they left off at a later time. The central review page becomes important in this design. It should be front and center, rather than at the end of a longstanding set of screens.
• We avoid managing unnecessary data. We only rely on keys. The selection screen only cares about the resources needed to build the UI (e.g. character class images) and determining the minimal details to bring back to the character slot. A "fighter" key is all we need to look up Fighter class details in the associated map. Anything else should be kept in the global store, especially given that details can change. We can even introduce version control for said details if we expect them to change significantly, e.g. Homebrew definitions.
• We avoid polluting the activity stack. We use 1 screen for the review, and ideally 1 for the customization. Class selection can be done in 1 screen, but screens like Ability Scores have multiple ways to set scores. We could use a little bit of state to redraw the same screen, and going back would void the changes to the ability scores. Alternatively, we could use a modal to separate the preference selections from the results.

Current Character Screens:

• Race
• Class
• Background
• Profile (e.g. Name, Level/XP, Alignment, etc.)
• Ability Scores (via random roll, point buy, standard set, or manual entry)
• Skills
• Languages
• Hit Points