Category Archives: tools & techniques

Technology for Writing Larps Collaboratively Online

This entry was posted in LARP, tools & techniques on by .

Sometimes you want to write a larp with other humans who are nowhere near your physical location.

I’ve previously posted about Larp Writing Software, but that was more of a roundup than an analysis of each tool. This post is a summary of tools I have used for working with others, had suggested to me specifically for online collaboration, or evaluated myself with remote collaboration in mind. 

If I missed something that you’ve used to write larps at a distance, drop me a comment below and I’ll add it. 

Brainstorming and Idea Management

There are many, many online tools for brainstorming, mind mapping, and managing large projects. In the past I’ve mostly used Google documents and spreadsheets in Google Drive, but those won’t let you do more than make lists or build your own spreadsheet tools. 

IdeaBoardz is the only free service I’ve found so far for making notecard / post-it walls collaboratively for brainstorming that doesn’t require a login. It can be accessed by url without any login for the board creator or editors. It doesn’t appear to have much in the way of export capabilities, but might be helpful for initial brainstorming of ideas that you later transcribe somewhere else. 

A friend suggested Trello to me for brainstorming and project management. It has a free version and offers relatively inexpensive paid plans. I haven’t tested this tool.

Collaborative Writing

Google Drive is the gold standard for concurrent online editing in real time smoothly and this is a killer feature when it comes to writing larps together. This is the primary reason that most of my games are written in Google Drive. 

Drive is free up to a relatively generous storage amount. Personally I have a paid Google account in the hopes that it will give them more reason to never kill Drive. But with Google you never know. Paid plans start at about $30 / year. Drive has complex sharing permissions, including the ability to share things by url with editors who are not logged into Google. 

Microsoft’s OneDrive allows for concurrent editing and has a web client for desktop machines. They only support the standard Microsoft file types (doc, Excel sheet, PowerPoint presentation, a “OneNote notebook”, some sort of form) and plain text documents. I haven’t used OneDrive to co-write a large project for several years, but some experiments with the help of a friend suggest that Microsoft’s native types have reasonable online editors that can handle multiple people at once. Editing text files requires explicit saving, so that won’t really work with multiple people concurrently. If you’re willing to use Microsoft’s native formats and their webpage this is a reasonable way to do collaborative writing and editing. I have not tested OneDrive’s app to see if it handles editing gracefully. 

OneDrive has a free version with several GB of storage. Paid plans start at about $2 / month. OneDrive has complex sharing permissions, including the ability to share things by url with people who aren’t logged into OneDrive. 

Dropbox has a local version that integrates with your file system, an online interface, and an app version for devices like tablets and phones. The file system version and the app do not handle concurrent editing gracefully. In the case of the file system version, your changes can stomp someone else’s and you will not be able to see each other’s work if you both have the file open at the same time (your file system and local editor software behaves as if the file is offline!). I find the app (iOS on an iPhone and iPad) nearly impossible to edit in, but maybe other app versions are be easier to use. The web page version allows you to edit one kind of document, word docs, using Microsoft’s “Word for web” (the same tool that OneDrive offers) and that handles concurrent editing gracefully. So if you’re ok with having .docx formatted sheets you could coordinate with other writers this way. 

Dropbox has a free version up to a few GB of saved documents, which is plenty to write multiple larps. Paid plans start at about $10 / month. Dropbox has security control to share viewing and editing of files, but sharing by url only allows for viewing, never editing. 

If everyone in your team is comfortable using source control like git, you can write a larp together that way. It wouldn’t be my first choice and I absolutely wouldn’t inflict this software on anyone who isn’t already comfortable with the tools involved. 

Both gitlab and github will let you have private repositories in their free plans if you’re concerned with your materials being publicly visible. 

Some online wikis can also handle editing concurrently (since they’re meant to be used by physically separated editors in the first place), but I’ve not tested the exact ones that are available online or for free. I haven’t worked on a larp via a wiki for many years. 

Many systems that can handle multiple editors (like source control or online wikis) don’t always handle collaborative editing gracefully. Often you can’t see other people’s work until they save it (check it in / push it / whatever) and different systems will have different “merging” behavior for handling the situation where two people are editing things in the same place at the same time. This can get frustrating and painful really fast. Make sure you know how you’ll need to use the tools to collaborate with co-writers before you commit to a more complex system. 

Talking to Your Co-writers

You’re going to want to talk to your co-writers. Some communications might be fine with email or text chat, but most people will want to have audio or video chat available at some point in the writing process. 

If you are working with a small team (5 or fewer writers) almost any audio or video chat program should serve your needs. If you want details on the systems I’ve looked at head over to my post about software for running larps online. 

The TLDR summary is: I would highly recommend Discord for text and voice chat and Zoom or Google Meet for video chat. I’ve been told that Discord has improved their video chat a lot since early 2020: so it may be more usable than it was when I last tried it. 

For anything other than the briefest, most casual chat you will probably need a full computer available rather than a phone or tablet. It’s difficult to take or look at notes and have a video conference on a phone. 

Here are some things to keep in mind when setting up for audio or video chat: 

  • For audio communication:
    • Use headphones if possible. They cut down on noise and while most modern systems can avoid causing audio echoing, it will still happen sometimes (especially if your environment is noisy).
    • Try to find a quiet space. Close doors to block out other people or animals and avoid large echoing rooms if you can. Turn off loud fans or air filters if possible, since background white noise can make it a lot harder for you to be understood. 
  • For video communication:
    • Have reasonable lighting. Avoid bright backlighting or sitting in a dark room. Even lighting from the front will make you easier to see clearly. 
    • Put the video display on whatever part of your screen is nearest to your camera. This way when you are looking at the other people in the video chat it will look to them like you are looking at them, rather than randomly off into the void. 
    • Avoid distractions behind you. If your space isn’t conducive to focusing on you in your video, hang a temporary curtain or sit in front of a wall. Avoid having a TV or other moving screen in your background at all costs. (Artificial backgrounds can help as a last resort, but they are often distracting in their own ways, especially when they fail to green-screen around you correctly.)

Communications Software for Running Online Larps (LAOGs)

This entry was posted in LARP, tools & techniques on by .

This was written in November of 2020 by Eva with help from Quinn. Some of these details may have changed since then.

This post was updated in late November of 2020 with more details based on feedback I got about the original post.

This post was updated again in February of 2022. Most notably the pricing and free offerings of some of these systems changed.

Services are listed roughly in order of the ones we are most familiar with to the ones we are least familiar with. If you have opinions and experience with ones we haven’t looked at please leave me a comment!

A quick accessibility note: I have been told that Microsoft Teams and Zoom are the most accessible for blind and deaf people. Google Meet is also somewhat accessible for the deaf. I have not tried to test the accessibility of most of these systems first hand.

Zoom

  • Breakout rooms let groups split apart from the central chat room into separate video chats.
    • There’s lag when people change rooms (a few seconds).
    • It’s easy to accidentally hang up when you’re trying to just leave a room.
    • Rooms can have time limits (both a timer when the room ends and a buffer after that for when people get kicked out). It shows a timer on the screen to remind players. Once set, the host can’t reset the timers for a room.  
  • There are several models for how people get in and out of breakout rooms.
    • In the default mode, only the host can move people to and from rooms.
    • If everyone involved has Zoom 5.3.0 or later, the host can set up breakout rooms to be open to participants to jump in or out as they like. This can let you set up video chat spaces analogous to a divided/large physical larp space. 
  • It’s trivial to change your display name as often as you want and into anything you want.
  • There’s a user option to hide non-video participants. (This can help with immersion and limit distractions, especially with the GM checking in silently on small rooms.)
  • Backgrounds are a double edged sword, they can be super cool, but can also be buggy, distracting, and weird. People with older hardware may not be able to use them at all.
  • Has global text chat and the ability to privately text chat with people who are in the same room as you. Has some options for host broadcasting to rooms and asking for “help” from the host.
    • Does not have per-room chat and you can’t direct message people who aren’t in your room.
    • The host can send messages into breakout rooms, and that appears over the screen rather than in text chat.
    • Breakout rooms also have a button of “request help” that will message the host. 
  • There are “raise your hand” and “applause” buttons that users can use to tag themselves with icons. 
  • Supports push to talk. Uses the spacebar to temporarily unmute if you’re muted and zoom has focus. This can help folks with bad audio take part without destroying your audio quality for everyone. 
  • Generally handles poor connections gracefully.
  • Has mobile support. 
  • Has gallery view and host can spotlight people. 
  • Has screen sharing (including sound sharing from your computer, easy to screw up the sound part). This can be somewhat buggy depending on what you’re sharing. It generally does not handle sharing videos very gracefully, but still images or slides work ok most of the time. 
  • Free up to 100 participants but limited to only 40 minutes in length. Paid plans start at about $150 a year. You can purchase a paid plan monthly and cancel at any time.

Google Meet

  • Has live, automatic closed captioning that each user can turn on or off for themselves. This is not infallible, but it is easily available and will usually at least get the gist of what’s happening across. 
  • Has gallery view. 
  • Has an associated global chat. 
  • Users can “pin” people to make them big on their own screen. Hosts can’t spotlight people or otherwise control your screen. 
  • Free version allows for up to 100 participants for up to an hour. Paid plans start at about $8 a month and allow meetings for up to 100 participants for up to 24 hours.
  • Paid plans also have access to some Breakout room functionality. (I haven’t tested the exact details of how this works.)
  • Can’t change your profile name easily. You will need to use access without logging in via a Private browser window. Even then you can only enter a name on entry to the chat (no changing it). 
  • Has mobile support.
  • Meet now claims to have significantly more accessibility support than it used to.

Hangouts

  • Hangouts now has basically no video chat. It redirects you to Google Meet if you try to make a video call with more than two people. Thanks Google. :/
  • You can invite people, but can’t schedule group meetings with it anymore. 
  • Very basic. No frills. 
  • Free and no time limit, but everyone needs to have a Google sign in. 
  • Provides audio/video/text chat.
  • Works fine for 2 to 10 people, may get a little tough to use with more than that.
  • Has mobile support. 

Discord

  • Mobile or computer support. 
  • It’s peer-to-peer, so when using video it quickly overwhelms people’s upload capacity. For most people you won’t be able to video chat with more than one or two other people without serious problems. Voice only connections tend to work much more reliably, even with many people. 
  • Has push to talk, but the setup is confusing. 
  • Can have multiple audio or text channels. Has permissions that can control who can see or go into which channel.  
  • Moderators can move users from one voice/video channel to another. 
  • You can easily change your display name. Also has a “nickname” which is server specific. 
  • Your avatar is account wide. 
  • Users have control of what channel they’re on and if they join voice chats and which one, etc. So you can use channels as analogs for physical spaces. 
  • Does not have any global audio/video chat. So moderators will need to message people privately, go into each space for announcements, or yank everyone back to a shared space to contact them all at once. 
  • Has mobile support. 
  • TOTALLY FREEEEEEEEE!

Gather.town

  • Easily handles many people. It’s free for up to 25 people. (Can pay to have up to 500, but it’s per user, so this can get expensive: https://gather.town/pricing)
  • Computer only, no mobile. 
  • Has a map that you move around on. When you’re closer to people you can see and hear them. Has private spaces (tables, booths, etc.) that can have limited people in them.
  • You have a little pixel avatar who moves around. Your range to see and hear others is around 10x the size of your avatars. Normally you can’t walk through others, but you can use a “ghost mode” to move through things if you get stuck. 
  • There is a virtual space. You at least have more tools for gauging how people are interacting before approaching. 
  • You can gather people up to do things like briefing. There are options for broadcasting to a crowd. 
  • Has global chat and per-user chat. 
  • Has a find feature that gives you a path to get to other people. 
  • Users can set and change their name on the fly. 
  • In a crowd it’s hard to use the text to see anything.
  • The avatars are super tiny and hard to identify as people. You can pick an avatar, but there’s not that many and it’s a little irritating to select then. 
  • By default it’s a view of the map big with a small ribbon of videos, but how many you see depends on how big your screen is. You can scroll, but it’s not graceful.
  • You can switch to a gallery view with 9 people at a time. 
  • Really large maps can be overwhelming and people can get lost. 
  • Has spotlighting for a moderator or some they put in the spotlight to present to others. 
  • Moderators can set up custom maps. This can be great for larp, but it is also complex and painful to set up. 
  • (Lots of cool media support, clearly designed for conferences.)
  • Has an “interaction distance” and users set it for themselves. (This could cause weird issues with who can hear who.)
  • For more details of how to use Gather.town as a user and facilitator see this awesome thing Quinn wrote.

Remo

  • Kind of expensive. ($270 per month for up to 1,620 guests, there used to be a 14 day free trial but that appears to be gone now : https://remo.co/conference-pricing/)
  • Has separate “tables” that people can go to. The host can label the tables with text. Tables have a limit of how many seats they have, but a host can exceed those limits to join any table. 
    • There is a hard limit of six people to a table (no table can be larger than that) and depending on the room layout you use there can be a mixture of different sized tables in the room. Each table has one or two hidden spots that will allow a host to join even when the table is full (you can exceed six people at a table this way).
    • The limited table sizes can cause problems with being able to access people in a game. Especially with two person tables, there are likely to be problems with players being unable to contact people they need to talk to. 
    • Each table has a whiteboard by default. The host can lock it or let people who go to the table modify it. You can put video or images on the whiteboard or draw/type on it.
  • There are only a few room layouts that control the sizes of the tables. Users can move around to the different tables freely. 
  • There are time limits to how long you can have the room open at all. (Pretty short, like 2.5 hours for the cheaper versions)
    • You can do a larp longer than the limit if you’re willing to do briefing and wrap in some other system (like Zoom or Google Meet or whatever).
  • Relatively robust. When video breaks, audio usually still works, and you can move around to make it refresh. 
  • No global audio or video. 
  • A host can send global text messages that pop up in a box in the middle of the screen (this is a different interface than the global chat). The pop up is very obvious but will disappear as soon as you click, so it’s easy to accidentally dismiss this before you’re able to read it. There’s no other host broadcast options at the moment.
  • It’s easy to see who is where, even when you’re not at the particular table with them.
  • Jumping from table to table is very abrupt. You can’t gauge how the conversation at the table is going before moving there.
  • Has global chat, chat inside a table, and per-user chat (direct message a single other person). People can use per-user chat to try to communicate before going to a table (can be clunky and slow, definitely a hack). 
  • Has a few views, like room map + bar of small videos or gallery view. 
  • Has a feature where you can “get” someone. The system will tell them you are trying to get them and give them the option of either joining your table or not. Have not tested what this will do if you try to get someone while you’re in a full table, but this is a useful feature for calling a GM during a game. You can also use it to alert other players that you want to talk to them if they’re someone inaccessible.
  • No mobile support.
  • You can create custom maps/floor plans that use your own image. There is an approval process you have to submit your work to and it will take time for them to look at it and approve it. This is being used for one of the games at ExtraCon. I got a preview of the map and it is super sweet.
  • (At the time of writing, I haven’t talked to anyone who tried to host something non-trivial here. I’ll try to update if I’m able to ask a friend about this.)

Microsoft Teams

  • Has a free version with video “meeting” functionality. 
  • I’ve been told this is the best system to use if you need to cope with disability access.
  • If you’re using this with a paid company account it can record to the cloud.
  • Shows your own video only as a thumbnail.
  • Has a classroom view you can use with more than 4 participants which positions everyone together on a common background that looks like a lecture hall.
  • As of writing I have not tested this out. 

Twitch

  • I have not evaluated Twitch, but it’s mostly meant for public broadcasting streaming, so it’s unclear if it’s even possible to have a private Twitch stream. 

SpatialChat

  • Free up to 3 rooms and 50 people
  • Video chat with a spatial component, similar to Gather.town, so people fade in and out as they move near/far.
  • Does not have a virtual map or avatars, just an open space that you move yourself around. People are represented by either their video or a circle with a letter in it (when they’re too far away to see their video).
  • If you want more than 4 users their paid plans start at about $50 a month.
  • Basically impossible to use if you (or your players) have visual impairment problems.

Jitsi

  • Free and open source video chatting.
  • Has a mobile version. 
  • Can do recorded data streams to YouTube.
  • The publically available Jitis is a non-commercial service, so there are limits to when they’ll be available or how much bandwidth they can share with you. You can theoretically install your own private Jitsi server if you want.
  • I haven’t evaluated the details of how it works.

StreamYard

  • This software was suggested by a friend for use when you want to make a stream of your game.
  • It’s free for about 15 hours of streaming a month and allows direct recording to YouTube (either public or private).

LARP Writing Software

This entry was posted in LARP, tools & techniques on by .

A quick survey of LARP writing tools I know about (including some I have never used). I put these in alphabetical order and added some that other gamers told me about. If you tell me about another one I’ll add it to the list. 🙂

Stuff designed by LARPers

Akkar: this is from some folks in Norway and from what I can gleen from their page it is a web service you can install on your own server. I have never used it.

http://akkar.org/?view=&lang=en

Créa’GN: I think it’s an online collaborative tool, but the whole site is in French, and regrettably I don’t read French. (It looks like the site may require a paid subscription for writers? I am having difficulty reading the page, so I’m not 100% sure on this.) I have never used this system.

http://www.creagn.com/

GameTeX: a LaTeX based system for writing LARPs. If you’ve spent any time writing academic papers you probably either love or hate LaTeX (it is very powerful but not very user-friendly).
Edit: You can now get a copy of GameTex from http://web.mit.edu/kenclary/Public/Guild/GameTeX/ or a newer fork on https://github.com/dwhalen/SGSTeX
You may also find this tutorial for getting it working on a Mac helpful:
https://metaparadox.dreamwidth.org/1214.html

Gender Swap: a tool for managing gender changing LARP characters to match casting needs, by me. This is not a full system, just a markup processing tool for gendering characters at casting time. It supports standard pronouns for male, female, they-neutral, and ze-neutral genders.
http://www.digitalchangeling.com/gender_swap_pg/

Larpwriter: looks like a web page based cloud system that can generate PDF sheets. I know nothing other than what’s written on their page.
http://www.larpwriter.com/en/

NIMS: This is a web page based LARP writing tool with either an online or offline version available. It used to be Russian language only but has recently had an English language release. I have never used NIMS.
http://trechkalov.com/index-en.html
A Tutorial for using the system: https://www.youtube.com/watch?v=yxGeTzGlCiw

Querki: another online cloud service based system by Justin du coeur. Alan saw a demo of this one at Intercon and was super impressed with it. I have never used this system.
https://www.querki.net/

Spindle: also a cloud service system, and what I know about it is pretty much what it says on their IndieGoGo page. (As a spinner who uses a drop spindle, I <3 their logo. 🙂 )
http://spindle.pl/
https://www.indiegogo.com/projects/spindle-a-simple-solution-for-writing-your-larp#/

Vellum: a collaborative writing tool developed by Nat Budin. It’s an online service based system. I have never used this system.
http://vellum.aegames.org/

Stuff for general collaborative writing

Any Wiki System: Any wiki system you like will probably work fine for collaborative online editing as well. I find wikis tedious for small to medium games but some people love them. I’m in the middle of working on a game with Kathleen Leeds De Smet and Katie Zenke via a private wiki.

Dropbox: a cloud storage system for files that can be used to share collaborative projects. When used for LARPs there is the caveat that the version of Dropbox that functions in your file system can’t really handle concurrent editing of a given document (I believe their web system can). The free version of their service offers more than enough space for most writers to store many games. I’ve used Dropbox to write several games collaboratively.
https://www.dropbox.com/

Google Drive: more cloud storage of collaboratively edited documents! Google Drive is great for letting multiple writers concurrently edit documents, but you are stuck with their document format (the exporting capabilities aren’t terrible, but once you export you don’t get to edit collaboratively any more). Managing file organization is a nightmare because they have no tools for anything more complicated that “copy this file.” It does have a nice editing history to let you review other author’s changes. I’ve used Google Drive to write games collaboratively.
https://drive.google.com

OneNote: a cloud storage system for notes that lets you share and collaborate with others. Katie Zenke tells me this works well for working on games alone or with other writers. I haven’t used OneNote.
https://www.onenote.com/

Scrivener: a writing tool intended for other forms of writing like novels, but can also be used for LARPs. Julia Ellingboe tells me that there are LARP specific templates available for Scrivener and their site confirms that it will hook up to various cloud services like Dropbox to allow for multi-writer collaboration. I’ve never used this software.
https://www.literatureandlatte.com/scrivener.php

Source Control Software: Those of us who are programmers will be familiar with various source control systems like Git or Subversion. To use them for collaboration you need all your writers to be comfortable using something a little more cryptic and technologically confusing. Some source control systems have only command line tools and others have relatively easy to use visual clients. Git is notable because of the existence of GitHub, which will allow you to have a centralized online place for writers to connect their copy of a git repository so you can share your writing easily. GitHub is free, but the things that you put there are (by default) visible to anyone on the web. You can give GitHub money to get a private place to put your stuff. I’ve used various source control systems at work and in my personal collaborative projects.

If you can think of any others I should add leave me a comment. 🙂

How I Cast Small LARPs

This entry was posted in LARP, RPG, tools & techniques on by .

This post was previously available on a private G+ circle.

 

I figured it might interest people to know the method I use to cast small LARPs with prewritten characters. The community I play in generally calls these Theater LARPs and / or Parlor LARPs*. This is something I’ve developed over several years with the help of Kathleen Leeds De Smet. She came up with the casting worksheet, which I can no longer imagine casting this kind of small game without.

The example questionnaire and casting worksheet come from our game Better Living Through Robotics, which was written at Peaky Midwest 2014 and inspired by the theme for Intercon O (Orbit). We’re currently preparing this game for distribution (by which I mean, I’ve been putting off the prep work I need to do for the last six months and Kathleen has been very patient with me). Hopefully it will be available soon. 🙂

I prefer to pre-cast games to give the players time to read their sheets and plan costumes. I try to get character materials to the players at least one to two weeks before the game is scheduled to run.

In order to figure out which characters to give to which players, I send out a casting questionnaire via email a month or so before the game. The questionnaire gives you an idea of what your players do and, more importantly, don’t want to play.

When I write questionnaires I usually focus on identifying what character traits players might find undesirable. Especially in games where some storylines deal with power dynamics or sexual taboos, I’m wary of giving players roles the aren’t able to embrace. Some stretching of the player’s mind can be good, but having a player shut down entirely because they can’t cope with their character is bad news. I put a lot of my effort into avoiding that kind of catastrophic failure.

Here is an example questionnaire.

For each part of the questionnaire, there are characters it’s most relevant for. For example some characters are written to come face to face with the stuff brought up in the Character Traits section. All characters could potentially be exposed to these themes, but they are more central for a few.

Player responses can also help you identify if a player just should not be in the game at all. Not all games are good for all players at all points in their lives. If I run into someone who has explicitly told me they can’t cope with the content I know will come up for everyone, I generally talk to them (phone or email) and make sure they will be ok in the game. I would rather people didn’t play if the game is likely to hurt them. If they still want to play with things that will push their limits I know to keep a close watch during the game to make sure they aren’t overwhelmed.

The gender and romance questions help with figuring out how you can match up romantic plots. I have been thinking about rewording these questions to be more inclusive, but haven’t gotten around to it. The goal is to let players explore the genders and romances that interest them and ideally make sure that everyone can embrace the roles they’re given enthusiastically. It’s no fun to play a romance plot with someone who shuts you out because they aren’t into it OOC.

I should also note, the example game has characters of non-fixed gender. Any character in the game can be cast as either male or female in any run of the game. I have a script that handles gendering the sheets once the game is cast. The script can also handle ze and they pronoun sets, but this particular game is only written for male and female characters.

Anyhow, once I have all the player responses to the questionnaire, I fill out a casting worksheet to figure out how to best give them things they will enjoy.

Here is an example casting worksheet.

I review each player’s questionnaire responses twice. In the first review I flag characters corresponding to anything the player marked as undesirable (for example 1 or 2 in the character traits) as a bad match for that player. In the second review I flag any of the remaining characters who correspond to things the player has marked as desirable (for example 4’s and 5’s in the character traits) as good matches for that player. After these two reviews I flag any remaining unmarked characters as ok for that player.

Once I’ve reviewed all the players questionnaires that way, it’s a lot easier to look at the rows and columns of the casting grid and see if some characters or players have limited matching possibilities. I won’t give players “bad” matches unless I know the player well and have some reason to believe that they would really like the character and simply misinterpreted the questionnaire (this is exceedingly rare!). I’ve only once ended up in a position where I couldn’t find a way to cast a game.

* The term Parlor LARP was coined by J Li to describe the Shifting Forest Storyworks games. It got awfully popular in some circles to label small games with 5 to 12 prewritten characters in a limited physical space like one or two rooms.

Tools for Tabletop: Narrating Descriptions

This entry was posted in RPG, tabletop, tools & techniques on by .

So the player characters are tromping through a giant mushroom forest this week… what do I say to them? I need to tell them about the forest, but what words should come out of my mouth? Stopping with, “You walk into a giant mushroom forest,” won’t convey the world I’ve built in my head at all.

Narration advice I’ve heard includes: “read more”, “play lots of games and emulate your favorite GMs”, and simply “practice.” These are great suggestions but they don’t work for everyone. The anxiety jitters I feel when I sit down to GM haven’t gone away despite doing all those things.

After a lot of struggling, I found more specific narration suggestions in the writing community. Much of this post is based on the content and structure of a post by N. Strauss. Similar ideas and variations of them are discussed, in different terms, in this article by Stephen King from 1980 (link may be unreliable). I also found useful tips on scene goals in this post by Chris Eboch.  I condensed and reframed their ideas to more directly apply to tabletop RPG narration.

Many of these techniques are for describing physical places or people and most generalize to describing anything else that’s physically perceptible: creatures, spell effects, plants, prophetic visions, etc. Don’t feel limited by the exact examples I picked.

Before a game I sit down and write short bullet lists of three to eight items for places and NPCs the players are likely to run into. When I narrate I incorporate the points from the lists. I sometimes create more than I need, but no single place or person takes long. The things that I prepare ahead of time are much more vivid than things I come up with at the table.

Use specific details in your descriptions.

Imagine I’m GMing and I say, “Your party reaches a small village”, what are you picturing? Form an image of the scene in your mind.

Suppose I said, “Your party reaches a small gnomish village. All the homes and shops are diminutive but sturdy and well built.” Is the picture in your mind’s eye a bit different now?

How about, “Your party reaches a small gnomish village just as the sun begins sinking beneath the horizon. The diminutive homes and shops are sturdy and well built but strangely quiet. Doors are closed, windows are shuttered, and you don’t see anyone in the streets.” Is this place giving you a slightly different impression? Would your plan for what to do next change based on these details?

Specific details help the players take in the world the way they would if they were really there. Details also help players figure out how to begin reacting to the world and investigating new places and people.

Choose the details carefully.

It’s easy to fall into the trap of thinking more details is more better, but a flood of irrelevant details will blot out the bigger picture and bore the monkeys out of your players. At some point they’ll tune out your “boxed text” or, worse yet, become actively disruptive in an attempt to make you stop talking.

Pick details that make the picture clear without overwhelming the players. If you’re worried about camouflaging something in the scene, like a trap trigger or hidden loot, make the environment more complex and interesting instead of padding the description with irrelevant details.

A competent trap builder would know better than to put an obvious pit trap in an otherwise featureless 10 by 10 room. Likewise, players don’t need to hear about the size and shape of every barrel in a storeroom if none of them are relevant to their quest or contain anything interesting.

Choose details that differentiate.

Just about every fantasy character has a race, so if you tell me a woman is an elf that doesn’t help me to picture her or know how to react to her. If you tell me she’s a thin elf in traveling clothing carrying a bow, I have more of an idea of who she is. There are still a lot of elves that could describe. If you also tell me she has a scar across her left eye, a medallion of the local neutral elven god around her neck, and an air of disdain about her when she looks at the non-elven party members, I have a much clearer impression. These details distinguish her from other elves the PCs will meet in their travels.

When you have to describe something, ask yourself how is this _____ different from all the other _____s that my party will run into?

Use details that suggest a bigger picture.

If you describe a tavern table as unpleasantly sticky, with a visible layer of grime that hasn’t been cleaned in years, I’m likely to assume the rest of the building is in a similarly disgusting and flea infested state. If you tell me that a cavern is scattered with fresh bones I’m likely to assume that a dangerous predator lives here… and could be coming back soon!

Keep the situation beyond the immediate scene in mind when you describe the surroundings. Include details that foreshadow or offer clues about things you want the players to know or guess.

This holds for characters and monsters as well. Scars, clothing, colors, patterns, and adornments can suggest their history and allegiances or foreshadow their future plans and loyalties.

Describe things the way the characters would perceive them.

Different player characters are likely to notice different things in the same situation. You can add a lot of flavor by giving a player additional description specific to their character’s history, unique skills, or physical position in the environment.

For example, a rogue may have a sharper eye on the details of security, like locks and guard patterns, or they may notice how easily NPCs could be bamboozled or pickpocketed. Someone who grew up locally might be quicker to pick out strange changes to local traditions. A shorter race like a halfling (or someone who’s been knocked to the floor with a well timed punch) will probably have an easier time seeing a paper pinned to the underside of a table. 

Don’t force the PC to mechanically test for this information. This isn’t hard for them to notice; you’re telling them about things they can see easily that others would have a more difficult time perceiving.

You can pass PC-specific description to a player in a note or verbally. If you start passing notes it’s up to the player if they want to share the information truthfully with the others. If you tell them verbally the other players will know, whether or not their characters find out. Each strategy has it’s strengths and some groups handle one or the other with more grace.

Incorporate all the senses in the description.

Picture a scene in your mind and imagine the visuals of what the characters would see there. If you also think about how it smells, what temperature it is, and what it sounds like it’ll feel more like a real place. Sounds, smells, and other tactile cues don’t need to be ominous or strange. A bakery might smell of cinnamon, or closing a door might dampen the noise from a party the characters are sneaking out of. The existence of the other senses will better connect your players to the moment and can give them hints to what’s happening around them.

This particular piece of advice is a bit trite, but used with the other techniques, it creates more immersive and vivid descriptions.

Tell players what they perceive, not how they feel about it.

When you GM it feels easy to describe things in terms of reactions or judgments. I can’t count the number of times GMs have told me non-player characters were “sweet” or “trustworthy” when my first reaction was they’ll more likely than not push me into a volcano if I turn my back on them. As a GM you don’t get to dictate how PCs feel about the world. Nine times out of ten if you try to tell them how to feel they’ll ignore you anyway.

Pushing value judgments also isn’t an effective way to describe things. “You see at a scary castle,” isn’t going to make your players feel fear. Instead choose specific details that are intended to make the castle sound ominous and uninviting.

“After hours of trudging up and down you round the curve of a last hill and get your first glimpse of the castle. It’s still about a half mile away, up the twisting, winding path on the mountainside. The castle’s foundation juts out from the rocks of the cliffside so that half of it sits over empty air. In the shadow of the mountain it’s hard to make out the exact shape of the castle walls, but you can pick out the dark roofs of the jagged tower tops silhouetted against the sky. The wind picks up and you can hear a faint whistling or howling from somewhere within the castle’s crumbling stones.”

If you describe a scary castle, the players will feel the fear on their own.

Phrase descriptions in terms of what the PCs perceive. Avoid describing things with value judgments (“nice”, “ugly”, “beautiful”, “kindly”) or feelings that imply a character’s reaction (“scary”, “infuriating”, “lovable”, “confusing”). To get a specific reaction or value judgment from the PCs, focus on describing details that would cause you to react that way or make that value judgement.

Note: There are some times when mechanics like magic dictate how a character feels. Those are an obvious exception here. It’s still important to give the players some agency. Yes, the mechanics may say their character must flee from the dragon in terror, but while terrorized and fleeing different characters are going to react differently. Tell the player the restrictions of the mechanic and let them narrate their own (re)actions under those restrictions.

Describe things with a purpose.

Narration is a powerful tool. It can help you to move the plot forward, create moods, give players big pieces of information, or subtle hints and nudges in new direction when they get confused. You can pack a lot into each scene.

In a tabletop game you don’t always know where the protagonists are headed. Sometimes the players expect a scene to be important, and it doesn’t match where you thought the plot was going, so you don’t have anything planned. You can still strive to make the most of whatever situation the party wanders off into.

You can use a scene to:

  • advance the current plot
  • advance the over-arching plot
  • give the characters important information
  • give the characters hints or rumors about the over-arching plot
  • reveal something about the PCs or NPCs
  • reveal something about the world
  • develop a theme or foreshadow a future event
  • set the mood

When you imagine a scene for the first time, pick one to four of these goals you want to accomplish in the scene. You’ll need to decide the specifics of the goals, like what future event you’d be foreshadowing. When you come up with your descriptions be sure to include at least one or two details that support each of the goals you chose and, if possible, a few details related to what the players are likely to want from the area.

Revealing things about the protagonists in tabletop games is slightly different than in books. It can be prompted by something the GM pulled from a character’s backstory and worked into the current plot. It can also be spontaneous and player driven. When I run long term games I compile lists of themes and elements players have built into their characters. Using these same themes and elements in the plot or incidentally in the world can give the players opportunities to build on their characters, without pulling the development out of their hands. 

Setting the mood in a scene is crucial in some genres and it’s different with a table full of players than a single reader. I try to slowly build up to mood changes over several scenes in the way that a good horror story builds up normality. For horror and unease specific mood, I’ve found that weather, light, and heat related descriptions can have a profound impact on how players feel about about a place. Often how uneasy my players are is directly proportional to how normal vs unnatural the weather and temperature is. For example, if the party enters a shop, it can also be dark, strangely cold and damp, or smelling of mouldy books.

Summary

Put your descriptions in terms of what the PCs perceive. Include specific details and pick enough of them to illustrate important things in the scene without going into all the irrelevant minutiae. Decide which details to use by asking how the specific thing you’re describing differs from similar ones the PCs have seen or will run into. Use descriptions including multiple types of sensory information (sight, sound, smell, touch, etc.). When possible offer individual PCs different details geared toward their personal view of the world. If you want the players to feel something or make a value judgment, focus on describing details that would cause you to feel those feelings or make that value judgement. 

Decide if there are situations or future events beyond the immediate scene you want to foreshadow. Pick one to four specific goals you’d like to accomplish in each scene.

Don’t worry if you only use some of these tips at any given time. A scene in a tabletop game doesn’t need to be a perfectly nuanced and polished masterpiece. The purpose of descriptions in RPGs is to convey the important details to the players, not write a book.

What about all that other narration that’s not description?

There’s a lot to narration that’s not description of the static physical state of things. Action narration, combat narration, and effectively role-playing NPCs are each their own cans of worms that I’m not going to open right now. Depending on my motivation I may write about more of these in the future. 🙂