Road to Freedom
Play the Game here.
My Role: Creative lead, Producer
Tools: Twine, Pixel Studio, Procreate, Visual Studio Code
(The final project was completed in Unity.)
The road to Canada is treacherous, but your freedom is worth the hardship—if you can make it.
You’ve planned, you’ve mapped, you’ve said goodbyes to your fellow slaves. Now it’s time to leave your Tennessee plantation and head north through Ohio to Detroit, and from there, to the free lands of Canada. But many obstacles await you on the road, from hunger to wild animals to dangerous rivers—and most of all, the slave catchers close on your trail. It’s a difficult journey ahead, but you’d pay any price for freedom.
The Game: Road to Freedom follows an Oregon Trail-like game loop. The player travels between three towns, finishing in Detroit, where they can escape to Canada by ferry. On the trail, in the towns, and in Detroit itself, the player faces challenges such as natural barriers, hostile encounters, hunger, and exhaustion that are solved either by the choices they make or by checks relating to a core set of traits. They must manage hunger, medicine, and money while staying ahead of steadily advancing slave catchers. The gameplay is intentionally brutal to mimic the experience of slave escapees in a hostile world.
Objectives:
Educate players about the challenges escaping slaves faced
Create a historically accurate depiction of 1850s Ohio under the Fugitive Slave Act
Implement difficult choices in the game loop that realistically represents the hard choices slaves in the same situation would have had to face
My Role
I served as the creative lead and sole writer for Road to Freedom, a monthlong project for a game design class during my junior year of college. I was responsible for:
Research. Because this is an educational game, it required historical accuracy. I drew from sources such as slave narratives, maps, old illustrations, and history books.
All events that the player could encounter. This included trail events, town events, and city events. Nearly all had at least one choice and one skill check the player would have to face, leading to positive or negative consequences for their character.
Designing towns and locations. The three towns the player moved through had to be generally historically accurate in their position on the escape path, their use on the Underground Railroad, and the sorts of businesses the player could expect to find within.
Production work. I often acted as organizer for the group. Working with the programmers, I provided a reality check for how many game events were feasible for a project of their size and my time, gave feedback and advice on streamlining their main json file, and took over designing artistic assets so that the coders could focus on exorcizing bugs rather than on learning Procreate or Pixel Studio.
Game Events
You can read the Twine .html file with all my events here. I ultimately created 236 individual content fragments in five major categories (Plantation, Trail, City, Town, and Ending events).
-
Branching narratives are difficult to organize. My first attempt was done in Google Docs, and I quickly lost track of all the threads amid hordes of bullet points. A branching pattern simply doesn’t fit on a linear page. I settled on Twine to visualize and arrange my events before I transferred them to the (linearly structured) json file that would eventually be entered into Unity.
The first problem after organizing the events was designing the json to begin with in a way that would be most streamlined for the programmers. The prototype was messy and required entering the same lengthy variables in several different places. Working together, we came up with a shorthand for marking whether an event had a skill or resource check, parameters for keeping track of what resource was in question, how it was affected by the event, what skill was being tested, and so on. This new json, while it required some memorization, was much more efficient to fill out than the first.
-
Another challenge I faced was creating event tradeoffs. These were important to balancing the game and making choices matter. Often, this came as a time tradeoff, which is a difficult calculus for the player because of the slave catchers on their tail.
Common tradeoffs include:
Gain money/lose time
Take the long way and lose time/take the short way and risk injury
Lose money/gain health, food, or medicine
Lose time/decrease exhaustion
-
During this project, I was required to balance my extracurricular help (I was not part of the class) with the game with four other main classes. Completing my writing within the short time frame of our sprints was brutal, and my team and I agreed that in hindsight, this ambitious project should have required at least one other writer. One of the programmers agreed to write the regular meal and sleep trail events (about 5 events total in that category), but I was in charge of the rest.
Nonetheless, with many late nights and creative scheduling, I was able to complete the 34 trail events, 10 city events, 14 town events, 4 plantation events, and 3 ending events to the best of my ability. Because these were almost all branching, choice-based encounters, with most branching in at least two directions, with success/fail on skill or resource checks resulting with different outcomes and therefore requiring double or more than double the amount of writing, I ended up doing 236 individual pieces of writing in total. Phew.
-
As a white person, I was distinctly aware of my ignorance in this sensitive and racialized suspect. Had I had the option, I would’ve like to consult with a Black sensitivity reader to ensure that my depiction of a Black, enslaved character was fair and respectful to American descendants of slaves. I was as careful as I could, avoiding racial slurs (specifically the n-word) even in situations where it might realistically be used.
Similarly, the gender of the player character is not specified, so I used as gender-neutral language as I could. Instead of “man” or “woman,” NPCs referred to the character as a “traveler,” a “stranger,” or, in one case, a “young’un.”
-
Before the player sets off on their escape, they have the option to speak to a friend on their plantation, sleep to charge up on health, buy supplies, or try to get a pass from the plantation owner. There are no time loss tradeoffs because they haven’t escaped yet.
Once they leave, they cannot return to the plantation unless the slave catchers seize them, restarting the game.
-
Trail encounters were randomized as the player walked down the road. This was the most numerous set of events in the game to ensure the player faced diverse challenges and avoided confronting repeats.
Based on my research into slave narratives, I organized challenges on the trail into a few major categories:
Natural obstacles like rivers, cliffs, bad weather, etc.
Food loss
Antagonists like slave catchers, police, suspicious townsfolk, etc.
Bridges and crossings
The trail was also home to resources and opportunities:
Chances to help people and gain money
Natural resources like food, game, etc.
Stops to purchase supplies
There were also a series of regular events such as nightfall and meals.
-
Like plantation events, the player can decide whether to engage with locations in the town. For example, the player can choose to work at the local lumber mill for a few hours to get money to spend on an inn that night. (Of course, this requires the “time for money” tradeoff.)
Challenge: Historical accuracy. The first step in creating town events was choosing the towns. This required me to consult some historical maps that traced common slave routes and Underground Railroad hotspots in Ohio. Then, based on what locations we wanted each of the towns to have, I narrowed down the options; the lumber mill, for example, would need to be based in a town that historically processed lumber.
I decided on Troy, Wapakoneta, and Bowling Green.
All three towns included:
- A place to work
- A general store
- An inn
The church in the third town is the only place the player can get expensive, forged free papers, which are critical to winning the game.
-
Detroit serves as a final, brutal gauntlet of events that the player must navigate to reach the ferry and escape. Like trail events, these are randomized. By design, they involve either negative or neutral outcomes—no gain—and consist of either threats (like muggers) or barriers (like traffic jams).
-
If the player reaches the ferry with both the money to pay for a ticket and forged free papers, they successfully board and escape to Canada. If they lack both or are missing one or the other, the slave catchers take them, and the game restarts. If they collapse out of exhaustion, hunger, or injury on the trail or in the city, the game also ends with capture.
This difficult and unforgiving game loop was intentional, and we imagined the game taking several runs to successfully complete. From each attempt, the player would learn how to navigate challenges and scenarios more successfully, strengthening their chances of escape each time.
Challenge: game memory between runs. We at first envisioned that certain events would be affected by the player having faced them on a previous escape attempt. For example, an NPC they spoke to might remember them and offer further assistance or respond with further suspicion. However, this functionality proved too complex to encode.
Challenge: disagreement over sudden death events. Early in the project, I proposed that there could be a few sudden death events, where if the player failed a check, they were captured regardless of how good their stats and resources were. My reasoning was that a) this would simulate the precarious nature of interactions on the trail and the ever-looming threat of being cut short, and b) it would provide more variety and unpredictability in event consequences (rather than always losing health or money). The programming team disagreed. We compromised: they gave me the flexibility to make a greater number of checks more difficult/punishing and trusted me to maintain mechanical game balance despite this.
-
I also stepped up to create the cover image for Road to Freedom, then went beyond that to create moving animations for the landscape and for the player walking across it.
Brainstorming
A professor in the history department served as our “client” who dictated the feel and shape of the game. Because he was teaching a class on slavery in Ohio, he instructed us to create an educational game on the same subject in the vein of Oregon Trail or Death Road to Canada.
In our first team meeting, we designed the player character, who would have points distributed across a set of core skills represented by a number. When the player encounters obstacles, these numbers were “rolled” against as if with dice. We imagined the core skills as:
Body
Strength
Speed
Survival
Mind
Knowledge
Medicine
Speech
Soul
Vitality
Acting
Luck
Based on these attributes, made a few preset professions that the player could choose from (e.g., farmer, butler, chef), each with a different skill distribution.
I imagined that the game loop would move between progression, encountering an event, making a choice, dealing with the results, and progressing again. The programmers and I agreed to write the events in a json file format to make them easy to implement in the code.
Research
The accuracy and atmosphere of the game were left entirely up to me as the programmers set about creating the mechanics, stats, and interface. To get a bird’s eye view of the historical context the game would be set in, I read the first few chapters of Gateway to Freedom: The Hidden History of the Underground Railroad by Eric Foner.
Next, I browsed North American Slave Narratives on the online archive Documenting the American South, taking notes on common occurrences and challenges that runaways faced. on the trail. From these, I began to make a loose list of the sorts of events the player would encounter so that I could compile these into events.
Initial Demo
The feedback on our initial demo mostly involved the programming side of the game, but test players also commented that reading long blocks of text for each event made them skip over it. Too much text leads to people not reading it.
The programming team suggested I seriously pare down my writing to a bare-bones description, a “watered-down Dungeon Master’s description of what’s going on.” In other words, I’d have to simply trash much of the descriptive work that I’d already done, flattening it to something like “A bear attacks. What do you do?”
I pushed back and put my foot down. I argued that cutting all the description would harm the game more than help it. People are playing Road to Freedom not just for the mechanics, but for a period-accurate depiction of what it’s like to be a runaway slave in the 1850s. That was the educational part. Descriptions are critical to the atmosphere and scene-setting. I’d already put a lot of work into researching and writing these events to be accurate and interesting.
Yet there was no getting around the fact that this was valuable feedback, and something needed to change.
Compromise: After talking to the Unity team and a few of my creative writing friends who agreed to play the game and give more detailed feedback, the programmers and I reached a happy medium. Instead of completely cutting out much of my description, I would pare down the less important events to under 600 characters, space them out into more easily digestible paragraphs rather than large blocks of text, and highlight important words in cyan.
Legend of Zelda highlighting key text elements.
Reflections
Road to Freedom was my first insight into how brutal sprints can be—and it forced me to confront how much work I can realistically take on for a project like this. I appreciate being confronted with my personal limitations and given the chance to find ways around them. Similarly, I learned the importance of compromise when advocating for my work.
All that said, Road to Freedom was fun in its intensity, and I took full advantage of the opportunity to deep-dive into a historical period and the challenge of incorporating accuracy into writing. It gave me the opportunity to practice a new kind of character voice in dialogue, one that sounds accurate to the 1850s without being confusing for a modern reader. This was also my first chance to step into a production role, which I thoroughly enjoyed.
Unfortunately, the animations I made did not feature in the final game; the programmers didn’t have time to include them. My cover image did, though, as did all my event writing (very gratifying!).