UX Documentation

The app's initial concept was intended as a lightweight, flavor-agnostic alternative to existing rules-editing options like The Homebrewery (which maintains a strong D&D flavor), while encouraging brevity and clarity in rules-writing based on personal experience with having to reference verbose rules as a Game Master.

This focus is reflected in the app being built around limiting the user's polishing options (most notably, not allowing images), encouraging them to focus on the raw rules themselves and ensure their writing is concise.

The short-form nature of rulesets enforced by this system was originally intended to be utilized by a batch-export feature for combining multiple rulesets into a single PDF file, however this was later scrapped due to difficulties in conforming to modern PDF specifications.

In keeping with the no-frills intention of the app, rulesets were originally represented using a single markdown file that users could paste content into for the sake of speeding up the creation of tables and blockquotes.

This proved to be insufficient for providing a truly streamlined editing experience, as the raw markdown syntax for tables and blockquotes specifically is tedious to edit manually.

To resolve this, the editor was pivoted from a single-file markdown editor to a block-based approach with dedicated editors for each block type, namely including text, tables and dice roll tables as their own blocks.

During development, user experience goals were kept at the forefront, and improvements were actively baked into the system design during its initial implementation.

Most notably, dice roll tables are given a different editor that automatically rebalances their rows and labels based on what dice type is being used, in addition to keeping a temporary cache of the table's largest size in order to prevent catastrophic loss of data in the event a user accidentally changed a d100 table to a d4 table.

This addresses two major pain points of table editing in traditional word processors: manually adjusting row count and ensuring the alternating background color for rows is maintained after resizing.

After implementing the mockups to test the app's base functionality, a secondary testing pass was made to identify pain points in the editing experience and shore up the editor's overall functionality.

Of the tweaks that resulted from this, many concerned the flow of focus across input elements, such as auto-focusing the text input when a table element is selected to facilitate Excel-style "click-and-type" editing, or automatically refocusing the editor's text area when pressing one of the buttons to paste a header into the text content.

System state was also made more visible during this update via the addition of toasts to all pages that communicate with the backend and dedicated styling rules for whether form inputs were valid.

Due to natural conversations being highly complex, the game's design focused primarily on the specific act of joke-telling, granting both structure and a concrete objective to the player's interactions. Comedy was also chosen due to promoting a win-win attitude in contrast to conversations based around persuasion, haggling or other zero-sum outcomes.

The game was also initially focused on incorporating a teaching aspect, using joke-telling interactions to give players hands-on experience with deciding where and when to use specific types of jokes. This was later dropped due to time constraints and due to the innate subjectivity of comedy as a subject.

Initial inspirations for this project included Potionomics for its abstraction of conversation into a deckbuilder format, The Secret of Monkey Island's Insult Swordfighting mechanics and Oh... Sir!! The Insult Simulator's keyword targeting.

An initial prototype of the core conversation mechanics was then created based on feedback from the paper prototype, focusing on providing feedback to players on a five-point scale and through the use of evaluation-related NPC reaction dialogue.

In contrast to conventional branching-path dialogue systems, Life Is Pain uses a reaction-based system where an NPC's dialogue is largely done in reaction to topics the player mentions and the quality of their joke choices. This grants conversations a more natural quality while allowing NPCs to react more dynamically to abnormal inputs.

Following the project's approval, the prototype was fleshed out with deck customization, integrating the deck with card-drawing and a basis for the overworld.

Modifier cards were also added, as their effects were based partially on turn order and thus required a separate system from the blue strategy cards.

Feedback from the approval process was also considered, and the project shifted its focus away from teaching and towards providing an entertaining, silly experience that retains the original vision of mechanical depth.

Subsequent user tests showed both the need for a tutorial and a desire to learn more about the game's characters, thus a tutorial area was created for the protagonist to talk to themself in the mirror before talking to anyone else, with the player only being allowed to leave once their own spirits were recovered.

For character building, the response system was modified to queue additional, non-joke-related dialogue lines as another means of learning more about characters and giving NPCs more agency in conversations.

The game is designed around cylindrical movement, which required unique visual effects to properly capture the continuous nature of its levels. Underneath this, however, the game uses a more standard 2D collision system before projecting objects onto a cylindrical play field based on their horizontal position relative to the player.

In this example, a representation of the actual collision mapping is shown in the top left, whereas the game’s interpretation is shown in the center.

Rather than using P5.js' standard 3D rendering tools, the project opted to use manual distortion of generic quadrilaterals to represent the blockers, using the position of a blocker on the cylinder to shear the quad into the correct shape. Later on, the use of manual distortion allowed for additional freedom to add effects, such as randomized sizing and lighting effects for blockers in the background being lit up by light from the center of the tower.

An initial prototype was developed to test the basic engine, after which another was created to add visual effects. exits, rolling and the eye. In this new prototype, the eye is cycle-based rather than exposure-based, exposing uncovered areas to danger on a set interval before allowing safe passage. This timing-based approach proved to be both challenging and uninteresting, thus it was changed to an exposure-based system in the final version. This version also added a darker tint to the background when behind a blocker to visually signal that the player was in cover.

The pixel filter used was promising, however the score text became difficult to read and thus the idea was scrapped in the final version.

The game initially featured a greater focus on combat, however its static, repetitive nature required a drip-feed of novel content that could not be delivered within the time constraints. As such, dialogue between the four AI units was added to fill time and maintain player engagement while building character for the player’s avatars.

To add character relations and history, the AI units were written like bickering siblings under the assumption they were trained simultaneously on the same data with the goal of collaborating in the future. This allowed the four to have an established group dynamic that could be leveraged for comedy, while adding the user as an outsider figure about whom the AIs are curious.

Due to the combat system being scrapped, the game’s focus shifted to embracing the inevitability of the player’s victory and using it as a source of comedy, with the player character’s quips both reaffirming their superiority while seeding the eventual narrative twist through playful advice based on specific enemies’ dialogue.

Likewise, enemies were written as distracted, unprepared, scared or clumsy in order to add more humor and make the player's effortless victory more plausible. Enemy sprites were made unique by taking the scrapped combat stances and iterating on them in both posing and attire to create a widely varied NPC cast while repurposing existing assets.

Despite attempts to work within Bitsy’s limitations, workarounds were required for the game’s two-stage dialogue and finale, both of which required duplication of assets to achieve their desired effects.

The finale specifically required assets to be flipped vertically in order to create a mirror-reflection effect on the water beneath the bridge, and cleverly placed scene transitions turned an otherwise choppy final segment into a split-second finish befitting the game's Kurosawa-esque affectations.