Tips for writing story-centric RPG scenarios

Inspired by similar articles I have read, I decided to give my two cents on writing scenarios for role-playing games. While I’m far from being an expert in the matter, let alone a half-decent writer, I have written several scenarios that seem to have clicked with some people. These are my principles when writing story-centric scenarios (beware spoilers of most of my scenarios, don’t read if you intend to play them!):

  1. Remember the story is not linear: don’t write as if you were writing a short story. In a way, writing a scenario is writing down your (obsessively detailed) research for a short story. Focus on the mood, possible scenes, characters, general plot, and clues, and improvise the story from there. Example: Gone Girls has a list of characters and possible scenes and locations, but no order is implied, or even that all scenes will happen. Characters are described with their goals and knowledge, and several possible endings are described for reference.
  2. Have a theme/topic for the story: something like family, prejudices, the cost of freedom, or loyalty. A story theme will help you focus while writing, and it will give the scenario a certain consistency. It will also give you ideas for possible scenes or for plot elements, when used literally or metaphorically. And don’t worry if you think the players won’t catch the metaphors: they still give the scenario a certain feel and focus. Example: Suffragettes is about class warfare from a feminist point of view. One of the metaphors is that the protagonists are fighting the patriarchy. And thus, the antagonists are middle- to high-class people who worship a deity they call “Father”, based on Father Dagon.
  3. Know the important NPCs well enough: you should know how your NPCs (non-player characters; anyone who isn’t the protagonists) will react to different situations. It helps to write down a couple of likely situations. Example: Suffragettes (page 5) has a relatively in-depth description of what Florence knows and how she will react in different situations.
  4. Make/get maps of the most important locations: they are handy for consistency, especially if it’s possible there will be an action scene in them. Example: The Cultists has a full map of the prison, even if the players are very unlikely to see it all.
  5. Make a timeline of events: if there are certain things that will happen regardless of what the characters do, make a timeline. Example: Gone Girls has a timeline of events both leading to the beginning of the story, and happening as the story develops.
  6. Treat the scenario as resources and ideas when improvising: in the end, you will have to make up a bunch of the stuff on the spot, and also it’s satisfying to change or make up new elements to adapt the story to whatever the players found interesting, or to incorporate ideas the players give you as the story develops. Example: once, when telling Gone Girls, the idea of making Edward Clarke invincible came up, along with the idea of making him being able to manipulate opponents to the extent of making them kill themselves. This was never part of the original story but made sense that one time and made the ending more dramatic.
  7. Show, don’t tell! Instead of telling the players about certain important things (eg. some character is a racist, some character is lazy, a room is a mess), setup a situation to make that point. Not only is more memorable, but it gives nuance and extra information. Saying “Tom is lazy” is generic and vague, but seeing how Tom still has boxes from when he moved in, a mess of cables all over the floor, and a pile of dirty dishes in the sink, says just how lazy he is, and in which situations. Example: in Suffragettes (page 9), Elise Samson is not simply described as “poor” or “homeless”. Instead, there’s a short sequence in which this is explained through a situation.

And that’s it! I hope you find this list useful. As a bonus tip, if you are writing horror (interactive or not) I recommend you read my summary of the book “Writing Monsters”, and maybe read the actual book, too.

New horror scenario: The Cultists

Finally Arcon is over and I can publish my latest scenario. Luckily, it was one of the three winners (second place) and I bought Fiasco companion with my gift card. It had nine players, which we split into three groups that played simultaneously thanks to the help of two extra narrators.

The scenario is called “The Cultists” and it’s a Lovecraftian horror story about a group of Christians that know each other from church, and are captured by a group of cultists. They are put in what seems to be an abandoned jail, together with 20 or so more prisoners. The protagonists have no idea why they are kept there, or what the cultists want or intend to do. As days pass, more and more gruesome things happen to the prisoners. The main themes of the scenario are truth, and whether it’s useful to be right if you live with people who are wrong and cannot be convinced otherwise. It’s written for Call of Cthulhu but it almost doesn’t depend on any rules so you can play it with whatever system you like. As most of my material, it’s written for adult players.

This scenario completes what I jokingly refer to as the “SJW trilogy”, a collection of three horror scenarios related to social issues: “Gone Girls” (about racism and prejudices), “Suffragettes” (about class warfare, esp. in the context of feminism) and “The Cultists” (about having “crazy” people in power). As always, you have them available in the scenario section of my RPG resources page.

Edit: update links to point to

A year of Elm

It hasn’t quite been one year since I wrote the first post on Elm, but it’s not that far off and the title was clearer that way. In this time I have written three programs in Elm, each one more complex than the last:

  1. Client for the catalogs generated by cataloger. My RPG resources catalog is an example of the result.
  2. Prexxer, a “Dress-up” application to combine sprites and create characters. You can see the code on GitHub.
  3. NARROWS, a storytelling system halfway between online role-playing games and improvised Choose Your Own Adventure books.

The first one was useful to get to know (and love) Elm, and of course to get my RPG resources catalog online. With the second I learned about Elm ports (the interface to interact with JavaScript) and got a bit more comfortable with Elm. With the last one, the only one that has a back-end (written in ES6, though; Elm is only for front-end), I learned how to structure big applications in Elm, how to use the excellent ProseMirror, and how to use much more complex Elm ports.

What I like about Elm

  • It’s a simple language with few concepts, easy to learn and understand. After my initial (small) struggles, I have mostly loved it since.
  • The Elm Architecture is really nice and simple, and it’s nice that it’s integrated into the environment. It’s like having a framework for free with the language.
  • Everything immutable: the easy way is the right way.
  • Nice, clear, useful compiler error messages.
  • Generally nice toolchain.
  • Static types help you a lot, mostly without being annoying.
  • Newer major versions of the language simplify things further and make things clearer and less error prone (I’ve been through two major updates).

What I don’t like about Elm

  • The compiler seems slow and often seems to compile older versions of the code. This might be my own fault, as I have a custom Brunch configuration with an Elm plugin and I don’t even understand Brunch all that well. In comparison, the TypeScript compiler was amazing.
  • Some complex types and interfaces, notably the modules for HTTP requests and JSON parsing. The former improved a lot in the new version, Elm 0.18.
  • Newer major versions of the language break compatibility and you have to rewrite parts of your application, which is really annoying… but also worth it.
  • I’m not that fond of currying. Sometimes I feel like it makes some compilation error messages harder to understand.


I’m really happy I gave Elm a try almost a year ago. Although I’m looking forward to going back to ClojureScript for some project, I really, really enjoy Elm, and it has almost become my defacto front-end language/framework.

Book summary: Writing Monsters

This is my (partial) summary for the book “Writing Monsters” by Philip Athans. It’s a book with advice and tips for fiction authors on writing effective monsters for your stories. Instead of following the book structure, I’m going to try to summarise a selection of its ideas.

Predictability is the enemy of horror

This is by far the most important idea in the book, and many of the tips stem from this principle. I have marked in italics everything connected to this.

What is a monster?

Uniquely strange creature that we instinctively fear. A distortion in appearance, behaviour or thought. Characteristics:

  • Monsters have a disturbing capacity for violence.
  • They are amoral and beyond our control: cannot negotiate with them, don’t seek or respect our opinion.
  • They turn us into prey, sometimes isolating us and/or taking our weapons.

Note that shape, appearance (hideous to beautiful) and size (giant to microscopic) don’t matter!

A strange, terrifying creature might not be a monster once its behaviour is understood.

Uses of monsters

  • Villains: Monsters don’t have to be villains, and villains don’t have to be monsters. If a character is both, build the villain facet first.
  • As transformation: We’re afraid of what we can’t control, including ourselves and other people (werewolves, Jekyll & Mr. Hyde, etc). Our psychological well-being is as important as the physical, maybe more, because otherwise we’re expelled from society and civilisation.
  • As “natural disasters”: They bring the best and worst in people. Useful to explore honesty, loyalty, vanity, etc., not just good/bad.
  • As obstacles: Simply what stands between the protagonists and some goal. Note that “defeating” a monster might mean understanding it, helping/rescuing it, or sending it home.

Defining Your Monster

When defining your monster, define its offence (why it’s dangerous), defence (why it’s hard to get rid of it) and utility (features that gives it “colour”, like Blair Witch Project making stick figures and putting victims in a corner). Make rules for it, even if they’re never fully explained to the reader. You can use a monster form as a reference.

Archetypes like vampires, zombies, dragons, etc., are useful, but you need to define your own twist to them, see eg. 30 days of night and 28 days later. Otherwise, they’re unoriginal and, worst of all, predictable.

Describing Your Monster

Show, don’t tell! Describe the visceral experiences of the protagonists/victims (eg. use of “shuddering” instead of “being afraid” in Lovecraft’s Dagon excerpt on p. 142), the monster’s effects on people, and its possible intentions. Not knowing what the monster is, or not seeing it, is effective.

Think of all the senses. Limiting one, or all but one, can be effective. We don’t have to be turned away by appearance, smell, etc: sometimes predators use good smell to attract prey.

Revealing Your Monster

Monsters should be revealed in three stages:

  1. Initial contact: Announces there is something. It’s fast (uses few words) and dramatic.
  2. Build-up: Reveals aspects of it, takes the most space: increasing the threat, leaves reader wondering where does it stop. Reveal no more than necessary (our imagination makes them scarier), use “red shirts” (side characters who die) to show the danger.
  3. Final encounter: Play with expectations and wait as long as possible to show the monster. Don’t actually show the monster until the end.


There’s much more to the book than what I’ve written here: I just included the parts that were more interesting for me personally. I have to admit that I was a bit disappointed with the book: it seemed messy, some of the ideas and examples I didn’t find enlightening or useful, and some ideas were repeated several times (didn’t feel like reinforcement, just messy writing/structuring). Maybe I had too high expectations.

That said, the book was interesting and useful, at least for a n00b like me. So I recommend it, just not wholeheartedly.

Book summary: 2k to 10k

This is my summary of the book “2k to 10k: Writing Faster, Writing Better, and Writing More of What You Love” by Rachel Aaron. It’s a very short e-book (also available as audio book) with tips for writers. It’s only $0.99 so definitely worth the money and the time if you’re looking for some writing advice and tips.

The book is divided in two parts: the daily process and the background work that allows for efficient writing. The second part is somewhat more subjective and personal and might not apply equally well for everybody.

Part one: Process

Many (competent, even!) writers equate writing quickly with being a hack. The author obviously doesn’t agree, and thinks that the secret of her method is that is removes dead times and waits. The method is based on three requirements. Improving any of the three is a win, but all three is the best.

  • Knowledge: The most important of all three. Know what you’re writing before you do it. No macro plot stuff, but exchanges in an argument or very rough descriptions. Five minutes is about enough to cover all the writing for a day.
  • Time: Record your word output per session for a while and figure out patterns. Do you write better/more when you write for at least two or three hours? At home? At the coffee shop? Without internet? In the morning or evening? Once you figure it out, try to make all of your writing sessions be like that.
  • Enthusiasm: Write stuff that keeps you enthusiastic. If you didn’t enjoy writing it, it’s likely that readers won’t have fun reading it. When planning the writing for the day, try to play the scenes in your head. If there’s any scene that you are not excited about, change it or drop it. Similarly, if you struggle to write one day, reflect on what you’re writing and figure out if you need to change anything. The process should be enjoyable.

Part two: Tips for Plotting, Characters, Editing

Plotting in 5 steps

To decide which book to write, choose an idea from the pool if ideas you have in your notebook, blog, or wherever. Signs to tell if an idea is worth the time/effort required for a novel: you cannot stop thinking about it; it writes itself (related to the previous point); you can see the finished product; and you can easily explain why others would want to read it.

  1. Get Down What You Already Know. Characters, situations, magical systems, settings. Scrivener mentioned as the best thing ever.
  2. The Basics. Start filling out the gaps from the first step, enough to figure out the bare bones of characters (main characters, antagonists and power players), plot (end and beginning, in that order, plus twists, scenes and climaxes you already know of; also the kind of story this will be), and setting (magic system if applicable, basic political system, general feel of places: technology level, culture, power).
  3. Filling In The Holes. You already have the plot beginning, some interesting middle points, and the end. Tips for when you get stuck in page 28. This step is finished when you can write the whole plot, start to finish, without skipped scenes.
  4. Building a Firm Foundation. Make a time line, draw a map, write out who knows what and when, memorise everyone’s particulars, write out a scene list, do a word count estimation, and do a boredom check (go through the whole plot: if some scene is hard to visualise or feels slow, figure out why).
  5. Start Writing! Remember that no matter how carefully you have plotted, the story and/or characters will probably change dramatically.

Characters Who Write Their Own Stories

Characters with agency (that can make decisions that change the direction of the plot) write their own stories. They will help getting from a point in the plot to the next. Examples in pages 36 and 37. Basic character sheet consists of name, age, physical description, what they like, what they hate, and what they want more than anything. It’s filled during step 2 above. The rest of the character development happens as the novel is written, like a braid: this gives easier and better results.

The Story Architect

Most stories follow a three-act structure (Act I, put your characters in a tree; Act II, light the tree on fire; Act III, get your characters out of the tree). Act II is normally the longest. Act III is the climax, the big event. It has a lot of tension, and it shouldn’t be too long because the tension will fade. Don’t forget the resolution at the end: readers need a closure for the characters, enjoy their victory. Does not mean having to end the book happily: the point is tension relief.

The Two Bird Minimum

Scenes should do three things: advance the story, reveal new information and pull the reader forward. Sometimes combining several scenes into one can be interesting and add tension, plus makes the story leaner.

Editing for People Who Hate Editing

Many people dread editing and think they cannot do it, but it’s just a skill that can be improved. Tips on approach:

  1. Change the Way You Think about Editing. The final destination of editing is reader experience: polishing the text so it doesn’t just contain the story, but it’s nice to read, too.
  2. Editing Tools. Three tools to identify the problems the text has: updated scene map (tip: mark types of scenes, like love, main plot, and secondary plot, and make sure their distribution throughout the next is not too uneven), time line (includes important things other characters were doing “off screen”; helps find timing problems, when action too loose or tight, lagging tension, etc), and the to-do list (list of problems you have found).
  3. Actually Editing. Take the to-do list and start fixing. Always biggest/hairiest problems first, never first page to last. Then do a read-through, making a new to-do list (typos and small things can be fixed on the spot), and possibly more read-throughs if the to-do list was big. Finally, read one more time, but from the reader’s POV (tip: use a reading device, not the computer used to write the manuscript). At this point you can involve other people, never before. Remember that involving other people means more rounds of editing. At least three more rounds is normal.


Here you have a pretty compact summary of the book, mostly useful for reference and to get a sense of what the book covers. Note that I skipped the chapter with advice for new writers and some other minor stuff, though. If you like this, go support the author (seriously, it’s just one dollah).

First impressions of Elm

For my next pet project I decided to learn Elm. Elm is a functional language similar to Haskell, that compiles to JavaScript. These are my first impressions so take them with a grain of salt.


Elm’s syntax is similar to Haskell’s. I had tried to learn Haskell a long time ago but failed miserably because I couldn’t understand the types. I did not find Elm’s syntax to be a problem, and it was nice and simple, especially compared to Elixir, the last language I had learned. However, I think it was the first time in my life that I wished I had had a small syntax description or guide before diving too deep into the language. For me there were two confusing things:

  1. Sometimes I saw a bunch of words that were separated by spaces or by commas, and it took me a bit of time to realise that function arguments are separated by spaces, but elements in a list or similar are separated by commas.
  2. Compound types that have more than one word, like List Int. That one is easy to figure out of course, but when I saw Html Msg I had no idea what it meant. I’m still not completely sure, in fact.

The first point in particular has an implication: if you use the result of a function call as an argument for second function you must enclose the first function call in parentheses. This all seems super obvious in retrospect, but when staring at code that uses a DSL-like library to generate HTML in a language you’re starting to learn… well, it would have helped to have the first point spelled-out. Example:

    ul []
     ( (tagView sectionPage)
        (ModelUtils.getSectionTags section))

Here we have a call to the function ul that has two arguments: an empty list and another list, namely the result of the call to Note how the whole must be enclosed in parentheses: otherwise, it would be interpreted as a call to ul with four arguments, not two. In the same way, both arguments to must be enclosed in parentheses, too.


Elm Architecture

Although strictly speaking you don’t have to use it, the Elm Architecture is a fundamental part of Elm. It’s the high-level pattern for application architecture when writing Single-Page Applications in Elm, the main usecase for the language. The pattern is very similar to redux and friends in React, but it’s nicer and more natural in a functional, statically-typed language like Elm.

In short, it means separating your application in sub-applications that have a model, a React-style view produced from the model, a set of messages the view can send, and an update function that receives messages and changes the model. Besides, Elm supports commands and subscriptions, which gives a nice, clean interface for WebSockets and other things.


Although I’ve been looking forward to going back to ClojureScript, and in particular learn and play with Om Next, Elm is certainly a worthy contender and totally worth checking out, especially if you’re using React and you want to go one step further.

I admit I did get frustrated now and then with the static types, and at first a bit with the syntax (see the two points above) and the indentation. However, all in all I enjoyed learning and using Elm a lot, and it feels very clean, productive, and just nice to program in.

The application I wrote was very small, though, and I didn’t quite get to explore patterns in how to split an application in several sub-applications. I did read a bit about it but didn’t get to use anything fancy.

And if you want to see what I built, head over for the site, or for the code.

New horror RPG scenario

I finally had time to take all my notes for the last scenario I wrote and format them properly in a nice PDF so people can read it and enjoy it.

It’s a horror scenario set in 1914 London, where the protagonists are suffragettes (the radical branch of the suffragist movement). The themes are oppression, feminism and class warfare, but you can play as a random horror/investigation scenario without caring about the underlying themes. In any case, this scenario is for adults, so please don’t play it with younger players without first reworking and adapting it.

I have added a list of resources at the end of the text. It’s obviously not everything I read or took ideas from when I wrote it, but it’s a pretty good starting point that will help narrators retell this story with more context and depth.

This is the first, and so far only, scenario I have run with Lyre, and I think it worked fairly well. Without further ado, enjoy Suffragettes.

First impressions of Elixir + Phoenix

I had been curious about Elixir for some time. After all, the promise of having the best of Erlang with a more palatable syntax was very attractive indeed.

A couple of days ago I finally finished a small project in Elixir using the Phoenix web framework, which is a sort of “Elixir on Rails”. These are my first impressions of both Elixir as a language and Phoenix as a framework. Take all this with a grain of salt: most of it is pretty subjective, and it’s from the perspective of a total Elixir/Erlang noob.


I used Introducing Elixir for learning, which turned out to be a bad choice because it can feel like an intro to functional programming using Elixir, not so much an in-depth book about Elixir for someone who knows functional programming. In fact, the book preface says:

If you’re already familiar with functional languages, you may find the pacing of this gentle introduction hopelessly slow. Definitely feel welcome to jump to another book or online documentation that moves faster if you get bored.

Elixir is a bit of a mindfuck for me in that it looks like Ruby, but it’s not object-oriented at all. The language also seems to value convenience a bit too much for my taste (sacrificing simplicity or consistency). In particular, I find the extra, convenience syntax for symbols in maps extremely annoying:

%{"blah" => 1}  # string as a map key
%{blah: 1}      # symbol as a map key (instead of %{:blah => 1})

Another case of different syntax options is the if statement. These two are equivalent:

if x > 10 do :large else :small end
if x > 10, do: :large, else: :small

I seem to recall this has something to do with macros, but all that syntax sugar feels weird. And all those colons, sometimes before, sometimes after a word, look ugly and confusing to me.

I have other, smaller peeves, but they’re subjective or unimportant. However, they strengthened the impression that I didn’t like the syntax.

In conclusion, the syntax reminded me of ES2015: syntax and exceptions for convenience, which makes it feel inconsistent, complex, and hard to remember. It constantly reminded me of the fat arrow function in ES2015.


Phoenix came with its own, related mindfuck: it looks like Rails and often feels like it, but there aren’t classes. That confused me a couple of times, but I guess it’s just a matter of getting used to it.

I think I liked it generally, and it felt productive, but I also felt that there was too much magic and generated code. Not as bad as with how I remember Rails (from many years ago), but enough to make me feel uncomfortable. Also, take into account that my project was a perfect fit for the framework: a small, mostly CRUD application.

I did get to try both tasks and channels, which were really cool, for example with the automatic reconnect in channels (they are implemented using WebSockets) without having to write any special code.


It was interesting to learn Elixir, but I’m curious about Erlang now. As in, I like the concepts behind Elixir (which are mostly Erlang concepts) and I’m not in love with Elixir’s syntax, so if I had to build a system that needed that kind of scalability and reliability I would consider Erlang.

TypeScript and new pet project

Around two months ago I started a new pet project. As always, I built it partly to solve a problem, and partly to learn some new language or technology. The problem I wanted to solve was showing images and maps to players when playing table-top role-playing games (and, while at it, manage my music from the same place). The language and technology were TypeScript and to a lesser extent ES2015. As always, I learned some things I didn’t quite expect or plan, like HTML drag-and-drop, Riot, a bit more Flexbox, and some more canvas image processing. The result is the first public version of Lyre, my program to help storytellers integrate music and images into their stories (especially useful for semi-improvised or interactive stories).

But the reason for this post is to talk a little bit about the technology. I admit that I haven’t really studied TypeScript thoroughly (I mostly learned bits and pieces while programming), but I think I like it to the point that it might become my front-end language of choice when I cannot use ClojureScript or similar.

So, what’s so great about it? Essentially, it’s ES2015 with optional types. The bad thing is that it needs special incantations to be able to use regular JavaScript modules, and in most cases you don’t have types defined for non-TS modules so you end up with type any for everything. The good thing is that it’s extremely familiar for people who know ES2015, because it’s almost the same, and that of course you can specify types wherever you want to. I am not the biggest fan of static types, but after trying it I think I really like the idea of optional types. Moreover, types in TypeScript are relatively open and feel like they fit very well in the JavaScript ecosystem. Two examples:

  1. Apart from enums, you can create union types that eg. are as simple as a choice between two strings, like type Mode = "off" | "on".
  2. Interfaces can be used to specify the properties, not just methods, that should be available in an object. Among other things, it’s possible to specify that an object should have certain specified properties plus any number of extra properties as long as their values are of a given type.

They have other interesting features, like union and intersection types, type guards for functions, decorators, generics and others things. I haven’t really used most of those, but I realised that I liked TypeScript when I was writing some JavaScript and found myself missing the optional types.

For actual editing I’m of course using Emacs, in this case with TIDE. Although the refactoring capabilities are very limited, the rest worked quite well and I’m very happy with it.

The other bigger thing I learned was Riot. Which, sadly, I didn’t like as much: I found it very confusing at times (what does this point to in the templates? it seems to depend on the nesting level of the ifs or loops), ended up with lots of rebinding of methods so they could be safely passed around in templates, and generally felt that I spent too much time fighting with it rather than writing my application. Now, some of these problems might have been caused by Riot-TS and not Riot itself, but still the experience wasn’t that great and I don’t expect to use it again in the future. Again, bear in mind that I mostly tried to learn on the go, so maybe I was doing everything wrong :-)

In conclusion, I love these projects because I end up with something useful and because I always learn a bunch of things. In this case in particular, I even learned a language that positively surprised me, even if I’m not a big fan of static typing. Again, if you want to have a look at the result, you can learn about Lyre and download the code from GitHub.

Narrative games and social change

One of the reasons I like role-playing games is that they can be used to train empathy and think about the actions of others, and thus our own. I think imagining what others would do in a given situation is a healthy exercise that can make us understand people, including ourselves, a bit better.

Perhaps my favourite game is Call of Cthulhu, a game normally set in the 1920s. I find that decade fascinating, partly because it so clearly highlights the prejudices normal, well-meaning people had/have. We are tied to our circumstances and all that. One of the things about the 20s that fascinate me so much is the KKK. I read a fair amount of information about them while preparing a scenario about racism and prejudice, and it shocked me how childish they were, and how big they were at some point.

Some time later, thanks to the film Suffragette, I started reading about the suffragettes, the radical, violent branch of the suffragists. The fight for women’s voting rights might sound like a dull topic, but boy was I in for a surprise. I read about the smart stunts they pulled and about how they learned jiu-jitsu to defend themselves from the police, and I was just blown away by how amazing these women were. So much so that I decided to do a little homage, in this case in the shape of a (work in progress) scenario about feminism and oppression set in early 1914. As the one linked above, it’s not completely historical, but it’s close enough that one can learn a thing or two and think a little about how things were then, and how they’re now.

After I’m done with the second one I’m planning to write a third scenario about social change, most likely about mental illnesses, but only time will tell.

EDIT: The scenario is finished. You can read about it and download it in the post “New horror RPG scenario“.