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“.

Functional Programming Is Not Weird

Recently I read a blog post titled “Functional Programming Is Not Popular Because It Is Weird“. I strongly disagree with the assessment and Twitter was too short for an answer, hence this blog post :-)

The blog post says that “Writing functional code is often backwards and can feel more like solving puzzles than like explaining a process to the computer”. I don’t agree at all, and I think this is simply a result of seeing functional programming in imperative programming terms. The first thing that comes to mind is that programming should not feel like “explaining a process” to the computer. Why should it? Imperative programming is centred around the process, the how. Functional programming is more focused on the what (which indeed is backwards compared to imperative, but I don’t think it’s backwards for humans).

Second, I think the recipe example is terrible and doesn’t show anything about the two styles of programming. The point of reading a program is not to be able to follow it step by step and produce the correct result (the computer does that), it’s about understanding the intent. Food recipes are about mixing things and obtaining the result. Programming is not about mixing things. In fact, the easier to separate and recombine they are, the better. This is very unlike a recipe.

Third, there is the “Imperative languages have this huge benefit of having implicit state. Both humans and machines are really good at implicit state attached to time”. Hahaha, what? State is the source of many, many problems in programming. Avoiding state, or at least separating the state-juggling bits, generally makes for better programs. Humans are terrible at keeping state in their minds, or understanding how a certain state was reached, or realising what produced changes in the state. To give an more concrete example of this: the post claims that “you know that after finishing the first instruction the oven is preheated, the pans are greased and we have mixed a batter”. No, you don’t. In a real program, you would be reading the source code for the second point, and it wouldn’t be obvious what the current state is at that moment. You would have to read, understand and play in your head the whole first point (and remember that, in real programs, there would be many ways to reach point 2, yikes!). And when anyone changed the first point, suddenly your understanding of the second point would be wrong, and you wouldn’t even know because the second point’s source code hasn’t changed. That is one of the reasons why state is generally best avoided.

The C++ example using templates as a functional language I’ll just skip as I don’t think is relevant at all for real functional programming. But right after, the author claims “I spend too much time trying to figure out how to say things as opposed to figuring out what to say”. I can relate to this while I was learning functional programming, but that’s entirely normal: you are, in a way, re-learning how to program. Many of your instincts and mental tools aren’t valid any more, and in some sense you have to start over. It’s frustrating, but the fact that it’s hard means that you’re being forced to think in a different, and in my view better, way.

Finally, at the end there’s “if functional programming languages want to become popular, they have to be less about puzzle solving”. If it wasn’t hard for imperative programmers to learn it, it wouldn’t be a different style, it would simply be a different syntax. No point in learning it! The reason why it feels like “puzzle solving” is because it’s different, not because it’s hard.

Now, I’m not saying functional programming is the best tool for every single problem, but most gripes imperative programmers have about functional programming are about “it’s different”, whether they realise it or not. Don’t be afraid to learn functional programming when it seems hard: that’s the whole point, you are learning a different way to solve problems!

Music Explorer

Lately I’ve worked on several small projects, mostly to learn new technologies. The newest one is music-related: a piano that shows scales and chords “in context”, to learn and explore music theory. The idea came about because my first instrument was the guitar, and music theory is pretty hard to make sense of when you’re playing the instrument. It’s just too hard to remember all the notes you’re playing, let alone realise when two chords in the same song are repeating notes because those notes might be played in different positions (eg. one chord might use E on the open sixth string, and another might use E on the second fret of the fourth string).

I remembered that when I started playing around with a piano, and I could figure out how to play a couple of chords, it was painfully obvious that they were repeating notes because they are in the same positions. In the same way, it felt much more natural and easier to figure out on a piano which chords fitted a scale, so I decided to write Music Explorer, and ended up even buying to host it. I don’t have a particularly grand plan for it, but I’ll probably add at least some small improvements here and there.

If you are interested in the technical side of it, Music Explorer is written in JavaScript (EcmaScript 6, to be more exact). I learned to use React with JavaScript, Browserify, Sass/SCSS, Ramda, AVA, the fantastic JavaScript music library teoria and a bit more CSS while writing this so it was definitely a useful learning experience for me. The full source code lives in GitHub and it’s licensed under the MIT license so you can go have a look!

Pet projects

I’ve been writing several pet projects in the last months. I wrote them mostly to learn new languages, techniques or libraries, and I’m unsure as to how much I’ll use them at all. Not that it matters. All three are related to role-playing games. In case you’re interested:

  • Character suite: a program to help create characters for RPGs. It’s designed to make it easy to add new rule systems for new games. It’s written in Clojure and ClojureScript, and with it I learned devcards, macros, Clojure’s core.async, figwheel and PDF generation with PDFBox. The code is messy in parts, but I learned a lot and I have a usable result, which is the important thing.
  • Nim-DR: a tiny command-line program to roll dice, including adding aliases for rolls (eg. alias “pc” for “1d100”). It doesn’t even support mixing kinds of dice, or adding numbers to the result. I mostly wrote it to get a taste of Nim. While I’m not a big fan of statically typed languages, the type inference really helped, and I liked what I saw. I may try more experiments in Nim in the future.
  • Map discoverer: a program to uncover a map bit by bit. You can use it online. I wrote it to learn ES6, the new JavaScript standard, and a bit about the HTML5 canvas element. I used Babel to translate ES6 to regular JavaScript (I could have used Node 4, but Babel supports much more ES6) and as a reference to learn the new bits. I really liked ES6: it still feels like JavaScript, but it improves things here and there. I just wished let didn’t allow re-assignment of variables.

While writing the last one I even learned about the pointer-events CSS property, which allows you to mark an element as not receiving events like mouseclick, mousemove, etc. Very useful!