How to Write a Quest-Based RPG

Image by jw432 from Pixabay

My previous article, Fun & Grief: Completionism in Games, was about the urge some players have to complete a game—take all the quests and see everything. Moreover, it was published along with a little companion game, which was a fun attempt to illustrate the point.

Screenshot from one of the game's side quests.

The game is a very simplified text-based RPG, in a generic fantasy setting. I wrote it on Arcweave—and you can play it on your browser, here. It features a main quest, 7 side quests, and a final screen that tells you which ones you pursued and which ones you missed.

For those interested in other people’s creative process, this post is a short account of how I made that little game.

Prep work

Research and brainstorming

I had a notion of what a side quest (probably) is and I could (probably) sit down and come up with a handful of ideas.

Still, I am not that experienced in RPGs. Experienced players and DMs from all around the world must have already come up with tons of great side quest ideas. All I needed to do was read their lists and shamelessly steal from them.

A couple of years ago, Nerdarchy published this great list of RPG side quest ideas, while Boccob’s Blog has several such lists, as well.

After reading some of those epic lists and steal… em… taking notes, there came the moment for pen and paper. I did a couple of brainstorming sessions on a little notebook and came up with a list, like this one:

Some sounded more interesting, some sounded more tedious and complicated. The next step was to sort out which ones to use.

Choosing main and side quests

Definitely stealing from Stephen Hand’s Moonrunner, I decided that the main quest would be about tracking down some villain and handing them over to the authorities.

In regard to the side quests, I already had a list, but not every side quest ended up being from the list. A lot of them popped up after I started structuring the beast.

Writing

To write, I used Arcweave, my tool of choice when it comes to designing interactive stories. I can quickly set up key plot points with broad strokes and then dive deeper and write scenes, without losing the bigger picture.

When I started adding my first elements and connections, I still had no content.

Structure first

The first diagram I did was of a very general plot flow. I arbitrarily declared that the plot would have 5 or 6 main steps and named them “MQ1,” “MQ2,” etc—"MQ" standing in for “Main Quest.”

Of course this didn’t mean much, but it was a much better way to start, than looking at an empty page.

Then, also completely arbitrarily, I added some side quests here and there, naming them “SQ1,” “SQ2,” etc. I still had no idea what they would be. I only wanted to have an overview of the size and the form.

I also knew I wanted a couple of the side quests to be related—for example SQ5 to be available only if you have completed SQ2. (Although this didn’t end up being a case.)

The first plot flow diagram looked like this. This is obviously not a functional flow chart—it doesn’t have two-way connections (so you can’t return from a side quest), let alone specific content—but it was more inspiring than staring at a blank board.

Placeholders are magical things. While waiting for the idea to join you, you keep a seat for it. It felt like laying down a row of empty plates, to be filled with a variety of delicacies. I just didn’t know what the food would be, yet.

Writing the quests

I liked the idea of starting the plot in a city. I had just recently finished Sorcery!2 with its unforgettable city of Kharé—and Moonrunner took place in a city, as well. Both very well-written and inspiring stories.

Of course, I knew I wasn’t going to expand the story to a full game, neither did I want the whole plot to stay in a city. Still, it felt cool to start in a busy place, before going through the wilderness of Rocky Valley.

The diagram of the pickpocket sequence. Arcweave allows breaking down the plot in multiple diagrams—called boards. This means each scene or side quest can have its own board, without cluttering the main story’s flowchart.

The first side quest I wrote was the pickpocket sequence. Once I finished writing it, I felt I needed a plan.

I took one step away from the diagram, opened a plain text file, and forced myself to fill in some gaps:

MARKET OF LAM'IA (MQ1)
----------------------

MAIN GOAL:
Get to the Chaotic Neutral Tavern.

OPTIONAL STUFF:
* help a merchant carry wheat. REWARD: str + gold.
* someone picks your pocket. Do you pursue?

CHAOTIC NEUTRAL TAVERN (MQ2)
----------------------------

MAIN GOAL:
Talk to the person called The Shadow.

OPTIONAL STUFF:
* beat local drinking champion in contest. REWARD: money.
* take part in a brawl. REWARD: ???
* do nothing and quietly drink your ale.

...

What I needed to keep in mind is that every scene had to have a clear objective for the player. Moreover, all those scene objectives had to be parts of the overall goal of finding and catching the villain.

To stick with this, I tricked my intellect into filling in this boring report—there is nothing fancy about a plain text file and that’s where its power lies. The report had the strict format of “LOCATION/MAIN GOAL/OPTIONAL STUFF” and left no room for shying away from the necessary points I wanted to nail down:

After delivering myself this report, I could go back to having fun with Arcweave diagrams and start writing the game scene by scene.

Breaking it down to multiple boards

One of the things I love about Arcweave is the option to break the story down in multiple boards. You can then access those from the list on the sidebar, as in the classic folder structure found in various apps.

Keeping each side quest on its own board, I could easily jump back and forth during the writing process.

This helps expand the whole story in as many chapters as you like, while keeping its parts easy to read and access.

As each side quest expanded in multiple elements, I moved it to its own board and used jumpers to access it from the Main.

To pass the story flow from one board to another, Arcweave uses jumpers. In this screenshot from the project, two jumpers send the flow to two elements on the “dialogue Druid” board.

Finishing touches

Final screen

To track which quests the player pursued—and which of them successfully—I created an integer variable for each quest.

By using one variable per side quest, the game knows which of them the player completes, fails, or skips.

All those variables have an initial value of 0, which means the player hasn’t taken the quest.

If the player takes the quest, the value ends up becoming either 1 (if they have succeeded) or -1 (if they have failed). In other words, if the player has taken a quest, the relevant variable’s absolute value will be 1.

Adding all the variables' absolute values, I get the number of the quests the player has gone after: quest_sum = abs(quest_1) + abs(quest_2) + ...

The final screen is basically one long Arcweave element that performs a series of "if" checks and renders the appropriate content.

Then, all I had to do was write a list of if statements, covering the results for each quest, rendering “SUCCESS” or “FAILURE” accordingly.

By checking each quest's variable, the game prints a message of SUCCESS or FAILURE for it.

And this is how it looks on Arcweave’s play mode:

Should I get the game to rank the player as casual or a completionist? "During the course of tracking down the villain, you pursued 2 side quests. YOU ARE A LITTLE CASUAL, AREN'T YOU?"

Images

Finally, let’s not forget about the wonderful art that I was lucky enough to find for the game.

Image by upklyak on Freepik.

All the images on the game are from Freepik and they are free to download and use—as long as one credits the source.

Which one should always do, anyway.

For the credits, I created a special page that is accessible at the very beginning and the very end of the game’s play through.

Aftermath

Writing process

Creating this game didn’t take more than a week of part-time work. It was great fun to write and it certainly didn’t aspire to be anything more than what it is—a little treat for the readers of my article on completionism.

I once again had the opportunity to test the tools I use and the process I have come to follow, which I describe in my post on writing interactive fiction. No story is the same with any other, but after staring at a blank page until your eyes need recalibrating, you realise a little methodology wouldn’t hurt.

And as for the tools, yep, they still work: mostly good old fashioned pencil and paper (for the messy part of the work) and Arcweave for the polishing and testing.

Trying it on for size

I must admit that—for an article’s companion game—it turned out to be a little longer to play than I wanted. Especially if you take on several of the side quests, the time you can spend playing it is considerably more than 5 minutes.

I did some editing, but I didn’t want to cut it down.

First of all, I didn’t want to reduce the number of the side quests. The whole point of this game is to offer multiple options, which the player can honour or ignore.

Neither did I feel like cutting down each scene’s narration. If I had forced it into a smaller size, I would have taken away the feeling of reading a story and would have created a feeling of reading a shopping list, like:

Something tells me this wouldn’t have been so much fun.

But don’t take my word for it. Go and play the game yourself and tell me what you think.

Giannis is a writer and story consultant focusing on subjects of narrative structure, theory, and technique. He is content writer in Arcweave.