Turning an Operator-Dependent Spreadsheet into a Shared Web Application

A Useful Workflow with a Difficult Handoff

Our tracking process progressed from paper to a magnetic whiteboard and then to a five-tab Excel workflow I created and initially operated. The spreadsheet helped prepare the participants in a battle, put them in turn order, track their changing condition, mark whose turn it was, and provide a separate display for players at the table or joining remotely.

The spreadsheet was deliberately flexible. It handled the established parts of the workflow while allowing me to manage exceptions manually during play. That gave the group time to work through the mechanics and its rule interpretations before I encoded more automation in the website.

Earlier workflow · First-edition Excel workbook

Excel made preparation easier, but the process still depended on its operator. When I stepped away from gameplay, other group members maintained and operated the workbook without changing its formulas or workflow. Its working tabs still had to be prepared for each battle, the active file moved between operators, and continuing an unfinished battle could require retrieving the prior operator's copy.

We sometimes retained an encounter by copying the active sheet and pasting its values into another tab, but those were manual snapshots rather than shared history. The handoff made the workbook's maintenance burden clearer. I had not added VBA automation because I was already planning to move that supporting work into the website.

Preserving the Useful Mechanics

I built the Initiative section of PC Relics to centralize preparation and the current battle state while keeping the operating model familiar.

That meant preserving the parts of the workflow the group already understood:

• one ordered list of player characters and opponents;
• a clear current turn;
• a way to record what happened during a turn and update a participant's condition; and
• separate operator and player views.

The goal was not to replace a spreadsheet for its own sake. It was to preserve what users already understood while changing where the working state lived.

The first web version moved the active workflow from local files into shared application records. From there, feedback from actual play guided the next changes.

Connecting Preparation and Active Play

Initiative brings preparation and active play into one workspace. A persistent roster keeps the participants visible while the available controls change from preparation to the active battle.

Before play, the Dungeon Master selects the participating characters, adds opponents, and enters each participant's initiative value, the number that determines turn order. When he starts the encounter, the application sorts the eligible participants, identifies the first turn, and publishes the initial player display.

During play, the Dungeon Master records the action and any damage or healing, then advances the turn. The application updates the affected participants, selects the next eligible turn, and refreshes the state available to players. If someone was missed during preparation, the Dungeon Master can add that participant without rebuilding the encounter.

The player display was designed as a separate view, not a copy of the Dungeon Master's workspace. It publishes only the information intended for players and refreshes as the encounter changes. Whether at the table or joining remotely, everyone can follow the same battle without access to the operator's controls or private encounter details.

Current workflow · PC Relics Initiative

Player-facing view · Rock Lizards encounter

Building for Continuity

Moving the workflow into a persistent application addressed the file problem directly. Encounter state no longer lived only in one operator's workbook. The application could retain the current round and turn, participant changes, recorded actions, and player-facing views between sessions.

Continuity also became a design concern of its own. The working Initiative implementation added encounter history, the ability to reopen a completed encounter without discarding its state, a way to return an active encounter to its prepared starting point, and an undo for the most recent action.

Those additions matter because a working system is more than its ideal path. During a live session, someone can be left out of the initial order, an action can be entered incorrectly, a battle can stop midstream, or the operator can navigate in a way the first version did not anticipate. The system had to support the real workflow, including recovery, without replacing familiar mechanics every time a new edge case appeared.

Live play also shaped the interface. Early feedback showed that some actions required too much entry, some information occupied space without helping the current turn, and groups of similar opponents needed a more compact presentation. The changes that followed simplified preparation and action entry, refined the player display, and made better use of the shared screen.

The working Initiative section automates this established flow, but it does not attempt to encode every rule or exception. A separate enhancement is adding capabilities the group previously handled through workarounds. That effort remains distinct from the working version described here.

The Result

Initiative remains recognizably descended from the spreadsheet. That continuity was intentional. The difference is that the working state is now centralized, the operator and player views are connected, and an unfinished encounter does not depend on passing around the right local file.

The Dungeon Master now handles the complete Initiative workflow independently. A process that once depended on a small group of specialist operators became a familiar system its intended operator can run himself.

Encounter history also gives the Dungeon Master a way to return to completed encounters rather than treating each session as disposable state. After an update made previous encounters easier to review, Todd's response was simple:

“Perfect. It's easier if I need to check what happened in a previous encounter. I'm loving this thing!”
Todd Kittredge, Dungeon Master

What This Project Demonstrates

This project reflects the systems work I value most: understand why an existing process succeeds, preserve the mechanics that make it usable, separate information for different audiences, centralize the state that needs continuity, and improve the working system through live use.

The transferable lesson is not about tabletop rules. It is about moving a proven manual workflow toward automation without discarding the knowledge embedded in the process or asking users to relearn what already works.