Do you remember what happened a minute ago? Of course you do! Do you remember what happened three weeks ago? Maybe not the small details, right? Welcome to the continuity problem - the disconnect between the players and their characters caused by the gaps between game sessions.

As I’ve mentioned before, sometimes it’s a challenge for my group to play on a regular schedule. We strive to play ever other week, or every third at worst, but sometimes life intervenes and the gaps between games get longer. Meanwhile, in the campaign world, no time at all has passed.

Our characters remember what happened in the previous session perfectly, since it was only a moment ago. But the players and the GM aren’t so lucky. We’ve been dealing with work, school, family, and relationships every day between sessions, and our memories of what happened last time have gotten a little fuzzy. Did we already fight the goblins? Did we find the secret door, and the treasure chest it concealed? Will we remember that Miss Peterson wore lavender perfume when we find a lavender-scented handkerchief next to the body of Mr. Potter?

It may not be a big deal if the party fights the goblins again. And if they never recover the gold behind the secret door it won’t be a huge setback either. But if the chest also had the mystic key that operates the elevator to the next level of the dungeon it’s a bit of a problem. And if the party doesn’t suspect that Miss Peterson is the killer it could be a huge problem. It’s situations like this that make continuity matter.

What do we do?

To begin with, let’s understand that there are different levels to the problem. First, we have to keep track of basic things, like which parts of the adventure we’ve already been through. Second, we have to keep track of what things of value the party has gained. Depending on the game, that could mean many things - magic items, money, clues, friendships, or mystic keys, just to name a few. Finally, the GM has to keep track of how the NPC’s react to what the PC’s have done so far. Did any of the goblins survive? Where did they go? Was that handkerchief dropped by Miss Peterson, or was it planted by the real killer?

It’s also important to remember that the problem grows worse with the passage of time. If the party met Miss Peterson last session they have at least a fighting chance of remembering her. If it was three sessions ago (a couple months in real time) the odds go down. And if it was a fifteen sessions ago, it’s going to be pretty unlikely that anyone will make the connection.

Now that we understand the problem we can look at how to fix it. The obvious answer to all these issues is to take notes each session that we can refer to later. It’s very helpful if one of the players can be convinced to take notes of what the characters have done, so that the GM doesn’t have to divert her attention from conducting the game to do so. Similarly, the players can keep a list of all the items, clues, etc. that they find, again relieving the GM of that burden. Alas, the GM needs to keep their own notes of what’s happening beyond the view of the PC’s.

How detailed those notes need to be depends a lot on the nature of the campaign. For a Call of Cthulhu campaign you may need pretty extensive notes. If you’re in a mega-dungeon you may be able to get by with a lot less. The GM notes don’t need to cover everything that’s in the player notes, just what happened that they didn’t know about.

Now that you have notes, you need a way to share them. This can be as simple as sending them out by email, but some folks like to empty out their inbox pretty regularly, so you may want something more permanent. You could set up a blog for the purpose, or a wiki, or use a campaign management tool like Obsidian Portal. Any of these could be a good place to put the party loot/clue/document list too. And now the players (and the GM, who might need it just as badly as the players) will have a way to refresh their memory of what happened the last time (and even the sessions prior).

You could, of course, keep the notes within Fantasy Grounds. The problem is, unless the GM has FG running the players can’t access the notes. It is a great way to keep the GM-only notes, though.

If you know the game will be on an unusually long hiatus, you may find it helpful to put together a summary of the major plot points that have happened so far. That allows your players to recall the important events without having to wade through all the individual session logs. I did this when we restarted the campaign, and again when we took a break to run an introductory campaign for a new player. In both cases the players seemed to appreciate it, and the second recap helped them connect a number of facts they had learned over the course of a couple years into a cohesive view of what was really going on. That, in turn, prompted them to take some actions they might not have otherwise taken, and really altered the direction of the campaign.

The final tool I use for continuity is the recap. At the beginning of each session I do a super-quick review of the action from the previous session. It’s usually something simple like this.

“Last time around you stole Afestan’s diary, copied it, replaced it, and then read the copy. From reading it you learned that he had been plotting with Cassandra, who was his lover, to kill his cousin the King, along with all the King’s children. That would make him the legitimate heir to the throne. So, what do you do next?”

That’s all for this time. I hope you found this useful. If you have any tips for helping maintain continuity in a campaign, or if you have any questions about what I’ve said, please be sure to comment. As always, thanks for reading!

The 1st Edition of AD&D had tons of variations on polearms. To be fair, history has seen a lot of different versions of sharp-thing-on-a-stick, but it seemed like AD&D tried to come up with statistics for every single one of them.

The other day I was watching a video, and for some reason it made me think of that.



So I just had to make my own lyrics...

Ain't no Glaive Gonna Hold My Guisarme Down

There ain't no glaive, gonna hold my guisarme down
There ain't no glaive, gonna hold my guisarme down
When I hear that polearm sound
I'm gonna get up off the ground
Ain't no glaive, gonna hold my guisarme down

Well I fought an orc with a ranseur,
And one with a big bardiche
I killed the one with the halberd 'cause he ain't got no reach

There ain't no glaive, gonna hold my guisarme down
There ain't no glaive, gonna hold my guisarme down
When I hear that polearm sound
I'm gonna get up off the ground
Ain't no glaive, gonna hold my guisarme down

Well look down the dungeon hallway
What do you think I see?
A guy with a bec de corbin, a-coming after me

There ain't no glaive, gonna hold my guisarme down
There ain't no glaive, gonna hold my guisarme down
When I hear that polearm sound
I'm gonna get up off the ground
Ain't no glaive, gonna hold my guisarme down

Well meet me mister meet me,
Meet me in the middle of the yard
And if my poleaxe fails me, I'll hit you with a fork-fauchard

There ain't no glaive, gonna hold my guisarme down
There ain't no glaive, gonna hold my guisarme down
When I hear that polearm sound
I'm gonna get up off the ground
Ain't no glaive, gonna hold my guisarme down

Or, The Tom Sawyer Principle

It takes a lot of work to run an RPG campaign. And all of it falls on the shoulders of the GM. There’s nobody else the GM could even call on for help – or is there? Let’s look at a little concept I call The Tom Sawyer Principle.

Did you ever read The Adventures of Tom Sawyer by Mark Twain? Early in the book, Tom skips school. As punishment, his Aunt Polly makes him paint a huge fence on Saturday, which is everyone else’s day off. Tom sets to work, but soon a friend comes along to tease Tom about having to work on Saturday. Tom sees an opportunity, and acts like there’s nothing in the world he’d rather be doing. “Like it? Well, I don’t see why I oughtn’t to like it. Does a boy get a chance to whitewash a fence every day?”

Tom continues to paint the fence in the most careful, absorbed way possible, as though it were truly a labor of love. The other boy gets interested in watching him work, and eventually asks if he can try it. Tom plays hard to get, and eventually gets the boy to trade an apple for the chance to join in on the fun. Soon all the boys in town are vying for a chance to do some of the painting. In the end, the fence gets three coats of paint, and not only does Tom avoid doing the work himself, he gets a pile of items in trade from the boys for letting them do the work instead.

So how does this apply to running an RPG? Well, as you know, running a campaign involves a lot of work between sessions as well as a great deal of concentration during actual play. If you’re running an adventure path, you’ll need to keep track of what the party has done, where they have explored, what clues and loot they have found, and who they have met. If you run a homebrew campaign, you’ll also have to design adventures, create NPC’s, make maps, and furnish all the myriad small details that make the campaign world seem to come to life. In the meantime, your career, your education, your family, your love life, and any other hobbies you may have all require some of your time as well. What’s a poor GM to do?

My answer to this dilemma is to hand off some of the work to my players. Not all the work can be delegated, of course. The players cannot design their own adventures, or decide how NPC’s will react to the party’s actions. But there’s a lot of work available in the campaign that doesn’t involve secrets the players must not be allowed to know.

For example, one of the players could take notes on the party’s progress during the game, removing one source of distraction from the GM. Another can keep track of the treasure, clues, or whatever is of value in the game you’re playing. A third can create and maintain an online repository for all this information. If a character is from a town for which there are no details, ask that player flesh the place out. If the party barbarian is from some far-off tribe, ask their player write up some details about the tribe.

Selling It

Tom Sawyer got his friends to paint the fence by convincing them that painting was fun. Luckily for us, we have a somewhat easier job - we have to convince our players that helping out on an RPG is fun. And if they’re playing RPG’s, that shouldn’t be too much of a stretch. We have another advantage too: Tom didn’t actually think painting was fun, so he had to convince his friends of something he didn’t believe. We really do enjoy working on RPG’s, so our enthusiasm doesn’t have to be faked.

Still, it’s unlikely that your players will just volunteer out of the blue to do something. You’ll need to get them started. I found that the key was to present it in a way that wasn’t about me. They started taking notes about what happened each session so that they could remember what happened. When I ask a player what his character’s hometown is like, he isn’t developing my campaign. He’s developing his character. Keeping track of the treasure helps them decide how to split it up. Having a website with all that information means they can look at it in their spare time, so their game time is spent slaying monsters instead of bookkeeping. All of that work helps you as well, but that’s not the selling point.

Rewards

I’m a bit on the fence about whether it’s good to offer incentives to players who wish to help out this way. The players will already be rewarded by getting to exercise their creativity. The whole group will benefit from having organized notes, lists of loot, and so forth. Those that participated will have the pride of accomplishment for helping make a better game for everyone, and the gratitude of all. For my players that has been enough. They have never asked for further rewards, and I have never offered any. But some GM’s do give rewards, and the results can be superb. For example, have a look at the session logs written on this site http://shockandbloodloss.blogspot.com/. Their GM offered to give each player’s PC 100 experience points for each session log they wrote. In return he got some great session logs, each written from the perspective of an individual character.

In spite of that example, I’m still not a fan of giving in-game rewards. If you’re handing out experience, loot, connections, or other in-game incentives, the characters of those who participate will become more powerful at a faster rate than those who do not. That could too easily make those players who don’t participate feel like second-class citizens. Some people don’t have the time to become involved, or they simply don’t enjoy doing those sorts of tasks. Whatever their reasons, choosing to not participate ought to be perfectly acceptable. This is recreation, after all, and nobody should have to spend their recreation time doing something they don’t enjoy just to keep up with the rest of the party.

Whether you give out any other rewards or not, it’s critical that you give them your heartfelt thanks. Thank them for their session logs and loot lists every game. Mention the website they built, and how helpful it is. Talk about how cool their ideas were for their character’s hometown. In short, make their work feel worthwhile and appreciated, and they’re far more likely to help again.

I hope you find these ideas interesting and helpful. I’d love to hear what you think. Have you found ways for your players to help make the game better? Leave some comments below, so we can all learn a little more. Thanks for reading!

When my group started playing D&D via Fantasy Grounds, several of my players were keen to resume the old campaign rather than starting a new one. That campaign had featured several long-term storylines, and the party had gotten fairly involved in one of them. This had apparently left quite an impression on the players, and they were eager to see that story to its conclusion. I was more than happy to acquiesce to their desire, since I had always been curious about how the storyline would be resolved as well.

Fortunately for me, I had written fairly detailed notes about the plot, and I had kept a journal of the adventures, where I recorded all the important details of what transpired each game session. These resources, plus my own memories of what I had intended allowed me to pick up where we left off.

But eighteen years had passed since we had played. Campaign time was frozen, but real life had gone on at its usual pace. My players remembered that there was a big storyline, and they remembered some disconnected bits of it, but they didn’t remember all the details, nor how the details related to one another. Their characters, however, still held the details fresh in their minds. So the challenge was bridging the gap between the memories of the players and the memories of their characters.

I also needed to create some basic campaign references for the players. This included basic campaign setting information like the calendar, the climate, and general maps of the area, along with information on the pantheon of deities unique to the setting. Since I observed a few house rules about allowable classes, training, and multiclass characters I needed a place to have them written down for everyone to consult as well.

Finally, I needed to have rule references available in-game. This, at least, was covered: the ruleset included the reference material from the 3.5 SRD. As I looked over these reference modules I realized that this format would be perfect for my campaign information and house rules as well. I did some reading on the FG forum, and learned the basics of renaming, unzipping, and editing modules, and set to work.

There were a number of false starts and headaches, since at the time there weren’t any instructions on how to create a reference module. I must give a huge ‘Thank You” to Griogre and Xorn from the FG forums for helping me out when I got stuck. Eventually, I succeeded, and I had a nice reference available for my players (and myself).

Next, I had to tackle the issue of character knowledge. Once again I created a reference module for the information. I had two sections: the first section detailed events and plot threads, and the second detailed NPC’s the characters knew (or knew of). This module also turned out well, and the players found it to be extremely helpful in bringing themselves back up to speed on the events of the campaign to date. We called it "The Little Black Book", and the players consulted it often.

I’m not going to go into any detail on the nuts and bolts of how I created these references. There is now a terrific manual here which explains the process in detail. My only additional advice would be to try to find an existing reference module that is similar to what you want, and use it as the basis for your own module.

Even if you don’t run an entirely homebrew campaign some reference modules can be handy. Most GM’s end up using a few house rules at least, and having them written down can save a lot of argument. You may also, as I did, end up making a reference module of spells that various characters had researched during the course of play, and which, of course, don’t show up in any reference. Finally, you may want to have stats available for monsters not included in the SRD (I’m looking at you, Mind Flayer!), and it’s handy to have them in a reference module so you can re-use them later.

I hope you found this information helpful. As always, if you have questions or observations please don’t hesitate to leave a comment below. Thanks for reading!

Awhile back the party did a wintertime scouting mission to the Howling Hills, part of the realm of the Lich Queen. The party’s bard wrote a song about it.

Scouting In A Winter Wonderland
(To the tune of Walking In A Winter Wonderland)

Sleigh bells ring, are you listening?
An undead horse, bones a-glistening
A horrible sight, we're frightened tonight
Scouting in a winter wonderland

Through the hills we are creeping
While our foes, they are sleeping
We're sneaking around, hope we don't get found
Scouting in a winter wonderland

In the meadow we can kill some goblins
With our fireballs we will cut them down
Gather up all of their swords and javelins
Then we can sell their weapons back in town

Later on, we'll conspire
As we set forts afire
We're counting our gold, with tales to be told,
Scouting in a winter wonderland

The fighter meets with a giant
Now the cleric's got a client
He's raised from the dead, with lumps on his head
Scouting in a winter wonderland

Near a bridge we find some sheets of paper
Wanted posters with all of our names
They do not approve of all our capers
But I'd guess you'd say that we've found fame

Later on, We'll conspire
To set more forts afire
We're counting our gold, with tales to be told,
Scouting in a winter wonderland


Here's the wanted poster in question.

Attachment 16977

I hope you enjoyed this, and thanks for reading!

In my last post I talked a bit about how I use a database of NPC’s in my campaign. Today we’ll delve into the details. We’ll talk a little about the platform and the software, then we’ll get into what information needs to be included. We’ll finish up by talking a little more about other ways to use it.

Throughout this discussion I will refer to our collection of NPC data as a “database”, even though we may or may not really be using relational database software to store the information. Conceptually it will still be a database of sorts.

Hardware

First, let’s look at the hardware. For a campaign run in Fantasy Grounds, it seems obvious to keep the database on the GM’s computer. But if screen space is at a premium it may make some sense to put your database onto a tablet or phone. If you’re running a traditional tabletop game, you’ll definitely want to think about how much computer hardware you want to deal with at the table.

Software

Next we need to think about the software. When I first created a database of NPC’s it really was just that - a relational database. The software I used to build it became obsolete long ago, but modern DBMS (database management system) packages like MS Access or MySQL would certainly work. However, it takes a fair bit of technical skill to get going with these, and for this task they are like hunting squirrels with a howitzer - a bigger tool than the job demands. If you want to learn to use such tools this application might be a fine way to start, but if you just want to get on with the gaming there are easier ways.

The next option is dedicated RPG campaign management software such as Obsidian Portal or RealmWorks. I really have only taken the most cursory looks at these, but they both seem like they would be worth checking out. If any reader can comment further on these or similar tools I’d love to hear about it. Leave a message in the comments!

My personal choice is the homely old spreadsheet. I already had the software and knew how to use it, and I was actually able to coax it into importing my old database data, which was a big advantage for me. A spreadsheet allows me to search, filter, and sort the data, which is about all I really need, and even with hundreds of records I can do all of it quickly.

Storage

The obvious choice for storing the data is on the device where you’ll use it, whether that’s the PC you use to run FG, or the tablet you carry to your tabletop game, or whatever. But it may be worthwhile to consider putting it on the cloud, particularly if you plan to use a phone, tablet, or other easily lost or stolen device to access it. The quantity of data probably won’t be huge, but as you grow accustomed to using it you’ll probably find the loss of it pretty painful.

Whatever storage medium you use make sure you make backups. Yes, that includes the cloud. There have been cases where cloud providers have gone out of business, or had their systems seized by the government, cutting off all access to the data.

Now what?

Now that we have all that sorted we can get on with the job. So let’s look at what sort of information about our NPC’s we want to have handy. My spreadsheet is for a D&D game, so my choices reflect that to some extent, but I’ll try to point out some things useful for other games too.

• The NPC’s name obviously has to be recorded. I should also mention again that one of the ways I use this database is to keep a running list of names that I haven’t used yet, so that when I need to come up with a name quickly I will have names appropriate to the campaign setting. So to start with, many of the records will only have a name, and nothing else. I’ll fill in the rest of it once the name is attached to someone.
• Next, we’ll need some basic information: race (if there are races besides “human” in your game), class (if that makes sense in the system you play), alignment (again, if that’s a thing in your game), and a flag to mark anyone who’s dead.
• I also have an “in use” flag that I can filter on, in case I only want to see in use (or available) names, and that I can use in my sort criteria when I sort the order in which records are displayed.
• Profession can be a useful field, even in a class-driven game like D&D. For example, the local herbalist (profession) may actually be a low-level druid (class), and knowing both could be helpful.
• Faction or organization is another useful field. It’s nice to be able to sort out all the members of S.P.E.C.T.R.E, or all the orcs that are part of the Blood Rune Tribe.
• Location is a field I use a lot. Some NPC’s, like spies or caravan guards, may be on the move a lot, but most NPC’s have professions or responsibilities that keep them in one locale most of the time. You could put something like “transient” for the location of folks who move around a lot.
• Finally, I have a large freeform text field. This lets me put in stuff like “Proprietor of Marna’s Pleasure Palace” or “wife of Alvenal the gate guard” or “Lord of Rock Rapids. Has a 1000 GP bounty on the party’s heads because they burgled his manor”.

What Isn’t There

I don’t use the database to keep details of the NPC’s statistics, possessions, spells, and so forth. Nor, for the most part, do I record their appearance, speech patterns, or personality quirks here. That’s all in FG anyway, and there’s no point in duplicating effort. The only exception is if I don’t have separate statistics for the individual. For example, if the characters question some random orc I might record more detail in the database since my only record in FG for them will be the generic “Orc, 1st level warrior”. If you’re using the database in a tabletop game, it might make more sense to have game-mechanic type details recorded, but I have never done so personally. If you do go that route, you may have reached the point where a more sophisticated tool like RealmWorks starts to have a real advantage over a spreadsheet.

Putting it to Work

Most of the time I have the whole spreadsheet sorted into a default view. I sort first by in-use (used before unused), then by location, then by living vs. dead (living first), then by faction, then by name alphabetically. But if I need to know something else, like the names of all the living halflings in Pegasus Falls, it’s easy to re-sort the data or filter it to show that.

If I need to flesh out a minor NPC on the fly, I just scroll down to the unused names, find one that I like the sound of, and fill in the details: “Aleval, human, CN, warrior, used, alive, Pegasus Falls, town guard, 3rd assistant gate guard - day shift, willing to take a bribe”. Save, re-run the sort, and now I have a permanent record of him.

During prep time, I use the database as a source of names, just as I would in a session. I also try to take a few minutes to make sure that I have kept track of changes to existing NPC’s from the last session (from alive to dead, for example), and to make a backup copy. Finally, I periodically add more names to the unused list so that I have some options available and I don’t end up having to name an elven princess Grond just because it was the last available name on the list.

The Elephant In the Room

At this point you might be asking “Wait, you already have the NPC’s in Fantasy Grounds, why do you need a spreadsheet too?” That’s a fair question. I can certainly filter my NPC’s by category, and I can search for their names. But FG doesn’t let me filter by other criteria (faction, for example), nor does its search feature let me search for anything but their names. If I want to search for “jeweler” I’m out of luck, unless I named the NPC “Gorton the Jeweler”. In short, a separate database gives me capabilities that FG lacks.

What about the other tabs?

One thing I miss about playing on a tabletop is the GM screen. I always had all sorts of useful tables on the screen, like maximum Spot distance by terrain type, miss locations for grenade-like missiles, Matrix for Clerics affecting the Undead, and so forth. One day it occurred to me that I could set up extra tabs on the spreadsheet to hold information like that. I tried it, and it worked out really well. I even went so far as to shade alternate lines of the tables, just like on the old GM screens, so that it was easy to read them quickly during a game. It turned out to be really handy.

My game uses D&D 3.5 rules, so this list would need to be modified for other systems, but here’s the tabs I added.

• Spot, listen, and hide modifiers, including maximum spot distance by terrain type.
• Grenade-like missiles
• Track modifiers
• Turning undead tables
• Weapon damage modifiers by size
• Concentration check DC’s
• Aura strengths of detect magic and detect evil spells

I hope this gives you some ideas for your own game. Please leave any comments or questions about this post, or anything else you’d like to discuss, below. And as always, thanks for reading!

Very early on in my DM days (1980) I realized that I was terrible at making up fantasy names on the spot. It often happened that a PC would unexpectedly strike up a conversation with some blacksmith’s apprentice or farmer’s wife, and all of a sudden I would need a name for an NPC for whom I had no details whatsoever. Every time, my mind would freeze up and all I could come up with were painfully normal names.

Me: “Uh, the apprentice’s name is, uh, um, Fred”
Player: “Fred? Really?”
Me: “Uh, well, it’s pronounced ‘Fred’ but it’s spelled, um, er, P-H-R-E-A-D”
Player: “Suuuure.”

So I decided I should make a list of possible NPC names. When I needed a name in mid-session I could just pick one off the list and carry on. So I began to cast around for good fantasy names. I used the names of minor characters from novels, took more major names from fiction and changed a vowel or two to make a new name, cherry-picked the few good ones generated by computerized random name generators, and even browsed baby naming books for inspiration. Soon I had hundreds of names to pick from at a moment’s notice. I wrote then into a spiral notebook so I could keep it handy at the table.

As often happens, though, the new solution lead to a new problem: the players tended to remember these NPC’s and want to go back and see them again the next time they were in town. After all, I knew these NPC’s names, so they must be important somehow, right? So now I needed to be able to remember them too. I began to write notes next to the names as I used them, so I would remember that Theron was the apprentice and Elonora was the farmer’s wife. The notes were sketchy, it was true, and not in a consistent format, but a paper-based filing system to track it in detail seemed too daunting. I added on to the list from time to time, and used it every session.

Fast-forward to 1987. I scored my first computer and found a good source for shareware software. Like a man with a new hammer looking for nails to drive, I cast about for ways to make this wonder of technology useful, until my eyes fell on the well-thumbed names list. Soon I had a database built in PC-File (a shareware database management system) to track my NPC’s. I worked out a format of data I wanted to have available, and created reports that would sort them by location, list only unused names and so forth, and print the results on the dot-matrix printer at work. This was a definite improvement.

Technology has moved on, of course. Currently I use a simple spreadsheet to track my NPC’s, rather than a full-blown database. But the concept remains the same: track the NPC’s digitally, and view them in customizable formats that are useful both at the table and between sessions.

Advantages of digital NPC notes

Building such a database, especially for an existing campaign, is a bit of a task, but it helps you out in many ways..

•  First, it keeps you consistent. It’s hard for me to remember if Thanikris is the jeweler from Grimpen and Thanarin is the stablemaster in Pegasus Falls, or is it the other way around? But computers remember it perfectly.
•  Second, it allows you to project the illusion of having an amazing level of detail in your world without actually having to make it up beforehand. If the party finds out the name of the gate guard, well and good - pick a name off the list and record it. Three sessions later they may talk to him again, and learn the names of his wife and children too. Again, pick some names, make up a few details and record them. You know that you just picked those names off the list when the player asked, but it looks like you had that at your fingertips all along.
•  Third, I have found it builds player engagement in my setting. When all the NPC’s the players engage have names, and seem to have some life apart from when they’re talking to PC’s, the players started seeing them as people rather than props, and this lead to them being more engaged with the setting as a whole.
•  Fourth, having these records in a digital format means you can sort and filter the data. Only want to see living people in Pegasus Falls, sorted by faction? Maybe you just want a list of names that haven’t been used? It’s easy to do with a computer.
•  Finally, you can also search it. So once you have your list of living people in Pegasus Falls, you can search for “guard” to find that gate guard, then search his name to find his wife and kids.

I hope you find that helpful. Next time around I will discuss software choices, and how to structure the information. Thanks for reading!

As I mentioned in one of my early posts I got Fantasy Grounds in order to restart my old AD&D campaign from 1990. Happily, I was able to recruit enough previous players and old friends to get started. We did a bit of testing, got VOIP chat working, and I got some tokens and maps made up. The characters were converted to D&D 3.5, and enough NPC’s were converted to get us started. I had written up some handouts about the campaign setting, and the basics of combat in 3.5, and sent them out to the players. I even had an adventure set up. We were finally ready to play!

But...

All but one of the characters had been converted from 1st edition AD&D to D&D 3.5. Anyone familiar with both systems will understand that not everything translates smoothly between the versions. Since only one player in my group had ever played 3.5, I had done most of the conversions for them. I did the best I could, of course, but I was concerned that what I had created might not be quite in tune with the vision the player had for their character. Some of these characters seemed to be highly cherished, so I was feeling the pressure.

Then too, I had a lot less experience running a 3.5 game than I had with 1st edition. While I had run literally hundreds of sessions of 1st edition, I had run a whopping one, that’s O-N-E session of 3.5. So I expected it to be a learning experience for me. And only one, that's O-N-E player in the group had ever played D&D 3.5. All but one of them had played 1st edition extensively, but it had been a very long time for most of them, and they were completely new to the intricacies of flanking, action types and attacks of opportunity. So I expected it to be a teaching experience for my wife and I, and a learning experience for everyone else.

Finally, all of us were new to FG, so we expected to fumble around a bit with it as we learned the ropes.

All in all, I was concerned that the early sessions would go badly. Perhaps a cherished character would get killed through sheer inexperience on the part of myself or the players. Perhaps characters would be found to be ineffective due to a poor build, or simply so unlike the old version that the player was unhappy.

Mostly, I knew this would be the one chance to ever get that old, cherished campaign back on its feet. And I didn't want to blow it. Clearly, what we needed was a way to work the bugs out of the converted characters, teach everyone the basics of this version of D&D, and learn to use the software, all without having any long-term negative consequences to the campaign.

At this point I remembered the holodeck from Star Trek: The Next Generation - a place that seemed real, but a place were mistakes weren’t permanent. Perfect!

So, I created a holodeck adventure, and we tested it out. It worked out really well. A couple players tweaked their characters a bit, and both the players and I made some pretty serious errors, including one that got a character killed for no really good reason. We all learned a lot about D&D 3.5, and we all learned a ton about using FG well. Looking back on it I’d say it was totally worth it to do those sessions, even though they didn’t do a thing for the storyline.

The other day I was perusing the Monster Manual for a suitable foe for the party, and my eye wandered across the listing for "Elder Fire Elemental". But for whatever reason, my brain read it as "Elderly Fire Elemental", which made me giggle. The idea kept bouncing around in my skull for a couple days, so I knew I had to write it down.

So without further ado, here it is. Enjoy!

Fire Elemental, Elderly
Huge Elemental
Hit Dice: 24d8 (108 hp)
Initiative: +4
Speed: 5 ft. (1 square)
Armor Class: 16 (-2 size, +8 natural)
touch 8, flat-footed 16
Base Attack/Grapple: +14/+28
Attack: Cane +22 melee (2d6+4 plus 2d8 fire)
Full Attack: Cane +22/+17 (2d6+4 plus 2d8 fire)
Space/Reach: 15 ft./10 ft.
Special Attacks: Burn, Stinking Cloud
Special Qualities: Damage reduction 10/-,
darkvision 60ft., elemental traits,
immunity to fire,
vulnerability to cold,
forgetfulness
Saves: Fort +10, Ref +19, Will +11
Abilities: Str 14, Dex 21, Con 10,
Int 7, Wis 12, Cha 12
Skills: Listen -10, Spot -10
Feats: Alertness, Blind-Fight, Combat
Reflexes, Dodge, Improved Initiative(B)
Great Fortitude, Iron Will, Mobility,
Spring Attack, Weapon Finesse(B),
Weapon Focus (cane)
Environment: Elemental Plane of Fire
Organization: Solitary, pair, or entire busload (4d10)
Challenge Rating: 10
Treasure: None
Alignment: Usually neutral
Advancement: None
Level Adjustment: --

A mass of silver-tinged flame shuffles across the ground, seeming to flicker and spark from a stooped, cane-wielding, humanoid-shaped central conflagration. Like a living inferno, the fire-creature’s burning stagger of heat and flame brings it slowly closer.

Time leaves its mark on all creatures, even fire elementals. Though they may have been fast and agile in their prime, elderly fire elementals no longer are. But even in their twilight years their merest touch is sufficient to set many materials aflame.

An elderly fire elemental cannot enter water or any other nonflammable liquid. A body of water is an impassable barrier unless the elemental can step or jump over it (the latter is unlikely to be attempted).

Elderly fire elementals speak Ignan, and often do so. Most of their commentary consists of a litany of physical ailments and recountings of the antics of their grandchildren. Their voices sound like the crackle and hiss of a great fire.

Combat
An elderly fire elemental is a fierce opponent that attacks its enemies directly and savagely. It takes joy in burning the creatures and objects of the Material Plane to ashes.

Burn (Ex): An elderly fire elemental’s cane attack deals bludgeoning damage plus fire damage from the elemental’s flaming body. Those hit by an elderly fire elemental’s slam attack also must succeed on a Reflex save or catch on fire. The flame burns for 1d4 rounds. The save DC for an elderly fire elemental is 22. A burning creature can take a move action to put out the flame. The save DC is Constitution-based. Creatures hitting an elderly fire elemental with natural weapons or unarmed attacks take fire damage as though hit by the elemental’s attack, and also catch on fire unless they succeed on a Reflex save.

Stinking Cloud (Ex): Each round of combat, there is a 25% chance the Elderly Fire Elemental will cast the equivalent of a Stinking Cloud spell as a free action, centered on one of its own squares. The effective caster level of this effect is 12th, and the save DC is 21. This save DC is Constitution-based. Note that elderly fire elementals are immune to the effects of their own Stinking Clouds, but not to those cast by others.

Forgetfulness (Ex): Each round there is a 10% chance the Elderly Fire Elemental will forget what his is doing and just shout “Hey, you kids, get off my lawn!” in Ignan.

Skills: Elderly fire elementals are a bit hard of hearing, and most wear bifocals.

Elderly fire elementals stand about 30 ft. tall (they claim they were 40 ft. when they were younger). They weigh about 12 pounds, and their weight is closely monitored by their physician.

My, how the time flies! But I’m back, and I’m going to cover one final aspect of mapping - making maps in smaller scales than the typical 5' per square of a D&D battle map.

By “smaller scale” I mean a map of a larger area. Map scale is expressed as a ratio. For instance, a 1"=5' D&D battlemap would be a 1:60 scale (1 inch on the map equals 60 inches on the ground). A map at the scale of 1" equals 1 mile (63360 inches) would be 1:63360. Since 1/60 is a larger fraction than 1/63360, we would say the first map is a larger scale than the second. So a map of a bigger area is a smaller scale map, and vice-versa.

All that discussion of scale makes perfect sense when you look at paper maps. But the purely digital maps we use in Fantasy Grounds make the whole concept a bit fluid. We can zoom in or out, and we can resize the display window, so the whole notion of distance per inch of map loses meaning. What restores the meaning is the grid that we overlay. If we put a 50 pixel per square grid over the map, and declare that this is the equivalent of a one inch grid pattern, we now have a scale to the map that’s independent of the degree to which we zoom in or out, or to the size of the display window we use to show a portion of the map.

Grids in FG can be either square or hexagonal. Hex grids came to prominence in the 1960's, when they began to be used in wargames. Their advantage over square grids is that they allow direct counting of distance in six directions rather than four. So there’s no need to create some sort of “fudge factor” for diagonal movement, like you see in D&D 3.5 or Pathfinder. I happen to run a D&D 3.5 campaign, so I use a square grid for battles, but for overland maps I tend to use hexes. Not only is it more convenient to calculate movement that way, but it also signals to the players that they’re looking at a smaller-scale map.

So for the rest of this discussion, I will express scale in terms of distance per hex.

The reason you’d want a smaller scale, of course, is that maps become cumbersomely large if you try to show a large area at a large scale. Then too, that level of detail often isn’t useful. Even Tolkien didn’t map every 5' square between The Shire and Mordor. And some RPG’s make little to no use of tactical maps and miniatures, allowing map scale to be driven by questions of convenient size rather than some definite standard.

In fact, once you break loose from the needs of a tactical battle map, the options for map scale are wide open. What scale you choose for a particular map will just depend on how much area you need to show, and how you plan to use the map. A map of an entire world, to be used as a political reference will be best at a rather different scale than a map of the city of Rock Ridge and its surrounding area, intended for use in planning a siege.

I’ll give you some examples of map scales that I use regularly.

For maps of really large areas (kingdoms) I’m mostly concerned with figuring out overland movement. So I use a scale of ten miles to the hex. A party on foot can get about two hexes per day by road, and on horseback they can get about three.

For moderately large areas (a city and the farms and villages that surround it) I use a scale of 3.33 miles to the hex. This means that I can also overlay the 10-mile hexes, which helps me keep the placement of features consistent between the various scale maps as I draw them.

For smaller areas, (the immediate vicinity of a town or fortress) I use a scale of 100 feet to the hex. This scale shows individual buildings, minor terrain features like fences and small stands of trees, and yet allows me to cover several square miles on the map.

As I increase the scale (i.e. show smaller areas in the same space) I also increase the detail. At the 10-mile hex scale I show major trade routes and cities, but not minor roads or villages. At the 3.33 mile level I show minor roads and villages, but not footpaths or individual farms. At the 100 foot level I show footpaths and farms, perhaps even individual buildings.

You’re of course free to pick scales that work for you. A modern-era game may use much smaller-scale maps for overland movement, for example, since the characters may be able to cover a lot more distance in a day with modern transport technology.

You could use a map without a grid, just with a traditional distance scale on the legend, like you would see on a real-world map, or on the maps you see in literature. It certainly looks more “normal” than a hexagonal grid, and, in my eye at least, better. So I tried a gridless map, briefly, but in practice it didn’t work out so well. My group often resizes maps to conserve screen space, then zooms in to see part of the map in detail. But if the part of the map we were looking at didn’t include the distance scale it became impossible to determine how far one point on the map was from another. We quickly decided that practicality overruled aesthetics in this case, and reverted to a map with a hex grid.

I suppose if you were so inclined you could create maps without a hex overlay, and just apply the grid in FG as needed.

So what works for you? Do you use grid overlays for small-scale maps? What scales do you prefer for overland travel maps? What else do you have to say about maps? Leave a comment below!

Thanks for reading!

I know last time I promised to talk about how mapping has changed through the years, but I changed my mind. I had nearly completed the article about old-school mapping, but after I re-read it I realized that it wasn’t going to be terribly helpful to most people. Sure, it’s fun to talk about the old days, but if you weren’t a gamer back in the 1970's it just sounds like the blathering of an Old One. So rather than forcing my younger readers to make a Sanity check, I decided to talk about something more timeless, and hopefully more useful - mapping outdoor spaces. Today we’re just going to discuss tactical maps for outdoor fights, and my next post will cover mapping larger areas for other purposes.

In most RPG’s the characters spend a fair amount of time outdoors, whether they’re exploring some unknown planet or simply walking to the pub. And that means there’s the potential for an outdoor fight. It may be a battle with wandering marauders, or an ambush by the cultists the characters are investigating, or just a hungry manticore looking for dinner. Whatever the reason, eventually you’ll need an outdoor map.

Broadly speaking, a battle map of an outdoor space isn’t that different from a battle map of a dungeon or a tavern. The scale will be the same, and there will be features to the landscape that restrict movement, and that provide tactical limitations and opportunities. But the features are very different from an indoor environment, and deserve some discussion. Also, while a dungeon or a building has definite boundaries, an outdoor map generally doesn’t. This forces you to consider just how big you need to make your battle map. My earlier discussion of map size (here) might help guide you on this.

The sorts of features on an outdoor map will obviously vary depending on the terrain. In a forest, the features will include trees, shrubs, downed trees and logs, water courses, quicksand, trails, and perhaps large rocks. In a desert you may have large cactus, mesquite bushes, clumps of prickly pear, sand dunes, and so on. In mountains, you will have trees (diminishing in size and number as elevation rises), shrubs, loose rocks, boulders and ice. Swamps will have many of the same features as forest, plus areas that are completely underwater.

All of these features can be generalized into a few categories, though some features could be listed in more than one category.

First, there are features that restrict movement. This could be anything from vegetation that is difficult to pass through, like cactus or a briar patch, to mud, loose rock or ice that makes for difficult footing. These sort of features still allow limited movement, but are likely to slow a character down considerably, and may present a chance of minor injury.

Next up are features that block movement. These could include cliffs, the trunks of really big trees, major bodies of water, or man-made features like fences or retaining walls. While someone might be able to climb a tree or a wall, or swim across a river, doing so will make them very vulnerable to attack, and probably prevent them from making attacks for a little while.

Then there are facilitators of movement, like roads, trails and bridges. These generally allow movement without penalty, which can be quite helpful, but by encouraging everyone to stay in a predictable place they also facilitate ambushes.

Cover and concealment are also important tactical features. By cover, I mean features that are solid enough to stop an attack, like a boulder or a tree trunk. By concealment, I mean features that would not stop an attack, but do keep an attacker from seeing someone hiding behind the feature. This would include things like bushes. Whether a feature is cover or concealment depends somewhat on what weapons are being used. A tree trunk is definitely cover against a crossbow, but against a plasma rifle it may only be concealment, or it may only provide cover against the first shot.

Any natural terrain type is also likely to have elevation changes, and these can be important tactical features as well. A gentle slope may not matter much, but a steep slope or a cliff can make a huge difference in how a fight would proceed. Most game systems provide some sort of bonus to the holders of the high ground, or a penalty to their opponents. In addition, very steep areas serve to channel movement by making travel in certain directions slow, difficult, or dangerous. Opponents grappling on the edge of a cliff can try to throw one another off, which should make the fight memorable.

I use contour lines, like the ones you would find on a topographic map, to indicate the presence cliffs and slopes on my maps. There’s a good explanation of contour lines on Wikipedia https://en.wikipedia.org/wiki/Contour_line if you aren’t familiar with them. For a battle map I normally keep the contour intervals at 1 foot per line, or perhaps at 5 foot per line for really steep terrain.

The lack of a ceiling, along with terrain features that put combatants on different levels, makes an outdoor battle rather likely to become three-dimensional. Whether the combatants are using magic, a jet pack, their own wings, or simply climbing a tree, there’s a lot of ways that some of the participants can end up above everyone else. That isn’t something you see often in a dungeon crawl, and it can give an outdoor fight an interesting twist.

Keeping track of which creatures are up in trees, climbing cliffs or flying was sometimes a bit of a chore in a face-to-face games, but it’s easy to deal with in Fantasy Grounds. By simply adding an effect to the combat tracker of “up a tree” or “flying” or whatever to the appropriate combatants, you’ll get a reminder on their turn that they’re not on the same level as everyone else. If there’s a mechanical advantage (like D&D 3.5's +2 to hit for being on higher ground) you can automatically apply that with an effect as well.

If you actually plan to have a battle in an outdoor location you may want to create a custom map just for that locale. But I also find it helpful to have some more generic outdoor maps. These are handy for random encounters, but they’re also nice to have in case the party decides to do something unexpected, like ambush some mooks in order to get intelligence on the villain’s fortress, or pursue the villain as he flees with his ill-gotten gains.

These “stock footage” maps don’t have to feature stunning artwork, but they should cover a lot of area. My campaign area is largely forested plains and hills, with some farmland, so I have maps of forest with and without roads, trails, and streams, maps of barren hill terrain and a couple maps of farmer’s fields with fences and paths. I have maps of some generic cityscapes as well. In addition, since my setting is in a far-northern climate with significant snowfall, I keep summer and winter versions of most maps. That sounds like a lot of maps, and maybe it is, but I was able to create them a few at a time, as needed, over the course of several years, which took some of the sting out of it.

Another trick I devised to keep the maps fresh was to take one I had used previously and simply rotate it ninety degrees using a graphics program. If any of my players have ever noticed I did that they haven’t said anything.

I’ll leave you with an example of one of my generic maps. This one shows a hillside with rocks, bushes, a path, and contour lines showing elevation. If you look very closely in the upper left corner you will see two black dots to be used to set the grid in FG. As I say, it isn’t great art, but it’s handy to have simple maps like this on hand for impromptu battles.

Attachment 15024

I hope you found this helpful. Next time around I’ll cover mapping larger areas. Hopefully after that I can get back to the story of how our group got back to playing using FG. Until next time, keep your dice hot and thanks for reading!

This is a continuation of the previous post about map size. It turns out blog size is important too, and the full post exceeded the allowable size, so I had to split it. You can see part one here...

Map Area

The other factor that influences the size of a map file is the size of the area your map covers. You’ve probably already figured out that, if all other factors are equal, a map that’s 50 squares on a side is four times as large as one that’s 25 squares on a side. So how big do you need a map to be?

Clearly, the map needs to be big enough to depict the encounter area. When that’s a wizard’s tower, or a small house, that may be a fairly small area. A dungeon level might be quite a bit bigger, but at least you know the map won’t have to be bigger than the dungeon. But what if the encounter area is outdoors? You obviously can’t make a battle map of the entire kingdom, but how big is big enough?

In my opinion the map has to be big enough that it doesn’t provide an artificial restriction on the player’s choices. For example, one of the characters in my campaign is a ranger with the Far Shot feat, which means that short range for him, using a composite longbow, is 165 feet (33 squares), instead of the normal 110 feet (22 squares). That should let him out-range his opponents, giving him an advantage. If the distance from the edge of the map to the nearest enemy is less than 23 squares, the advantage of the Far Shot feat has been negated. Now, I may not need to let him use that advantage every battle, but to me it would feel unfair if he didn’t get to take advantage of it once in awhile.

Finding the Balance Point

Clearly, the desire to keep the image file size small is at odds with both the desire to map a large area, and the desire to produce photo-realistic maps. Every GM will need to find their own balance of these factors, but I do have a few suggestions to help you out.

First, ask yourself if any of your players is on a slow or dodgy internet connection. If so, you’re going to have to lean heavily toward small files. Remember that if just one player can’t see the map, the combat is going to grind to a halt for everybody until they can.

Second, ask yourself if the characters in your campaign benefit from a big map. If your wizard specializes in summoning and nobody uses ranged weapons much it may not be important to have a big map since the battle can’t be properly joined until they get close to the enemy. On the other hand, if the party weapons specialist gets a new sniper rifle, throw him a bone and put him on a big map where he can use that rifle to good advantage. We want our players to get invested in their characters, but to do that there has to be a promise of a dividend.

Finally, ask yourself how important it is to you and your group to have a pretty map. Not everyone has the same standards for this, but you need to know what yours are.

Once you have answered these questions you can start balancing the factors. If you need small files that cover large areas, you can sacrifice stunning visuals. If you need the eye candy but you don’t need to depict large areas you can indulge your artistic side with only a slight nod to file size. If you’re playing a face-to-face game with FG on a big TV, you can go as wild as you’d like with file size knowing you don’t have to worry about file transmission problems.

My Choice

I have pretty well settled on a scale of 30 pixels to the square, and a map size (for outdoor maps, at least) of 90 squares to the side, for a 2700x2700 pixel map. Indoor maps depend on the size of the structure of course, but I keep the 30 pixel per square scale. A couple of my players live in rural areas with less than spectacular internet speeds, and another player insists on using wifi, so I keep file size under a megabyte when possible (almost all the time). My players have never lamented the lack of artistry in my maps (at least to my face), but they are quite willing to complain bitterly about a slow download, so I’m totally willing to sacrifice detail and color depth to keep the file small. As a bonus, it takes less time to draw the map since I don’t include so much detail, and I can use my prep time to improve other aspects of the adventure, which the players may appreciate more.

Whew! That went a bit long, and I apologize for that, but hopefully someone will find it useful. The sad thing is, I still haven’t said all I think I need to say about mapping. So next time around I’ll discuss how mapping has changed in the 35+ years I have been gaming.

Thanks for reading!

Today’s entry isn’t specifically about my group’s journey from a physical tabletop, to long hiatus, to a virtual tabletop with Fantasy Grounds. But my last post about tokens raised some points about scaling that I wanted to explore further. This will be a long post, so get something to drink, settle into a comfy chair and let’s get started.

If you frequent the Fantasy Grounds forum, you’ll see people discuss map size from time to time. Usually the discussion centers around the size of the file, i.e. how many kilobytes of storage the map consumes. The consensus seems to be that the file should be less than one megabyte, and preferably less than 500 kilobytes or so. My experience bears out that this is a good idea, though if you have a fast internet connection and remember to pre-load the image you can take some slight liberties with that.

But there are two other connotations to “map size” that also bear some thought. First is the scale: how many pixels to the square? Secondly, how many squares should the map depict? Both of these considerations have an impact on file size, and both have other implications as well. Let’s take a look at each of these considerations in turn.

I’m going to couch my post in terms of a tactical map, as used in D&D. This would have a scale of 1 inch = 5 feet if printed on paper. Some systems may use different scales, or different grids (one 30mm hex = 2 meters, for example), but the same principles will still apply. They will also apply to your campaign world maps, images of important NPC’s, and player handouts. So if you’re not into dungeon delving please try to ignore the D&D bias and read on, because what I have to say should still be useful to you.

File size

First, let’s look at the question of file size. Why should the file have to be small? There’s a couple factors at work there. Unfortunately the explanation gets a bit technical, but I’ll try to keep it fairly simple. No doubt someone with more networking savvy than I would have a better explanation, but hopefully this will make sense to non-IT folks.

First, for most people’s internet service, the upload speed (the speed at which a file can be sent from their computer to another computer on the internet) is only a small fraction of the download speed (the speed at which a file can be sent from another computer on the internet to their computer). For example, my upload speed is around 5.5 MBPS (megabits per second), but my download speed is 55 MBPS, so I can download files at ten times the speed I can upload one. For most users, this is fine, since the traffic is mostly going from the web servers to their computer, and not the other way around. But in the case of FG, the GM’s computer is the web server, so the upload speed becomes important.

Furthermore, when I share a file with my six players, I’m sending the file not once but six times. So you can multiply the file size by the number of players to see how much data you’re sending. In my case if I share a 1 meg file I’m really sending 6 megabytes of data.

So you might think that would mean it would take about 9 seconds to send that file (8 bits per byte times 1 megabyte times 6, divided by 5.5 megabits per second). But that isn’t really how data transmission works. What really happens is that my computer contacts one of the player’s computers, they each establish identities and so forth (a process called handshaking) and then sends one packet of data. It then handshakes with another computer to send the same packet, and so forth. The receiving computer checks the packet it got to determine if it got garbled, and if it did it requests a retransmission, in which case my computer has to send the same packet again. All other things being equal, the more packets I have to send, the more will be garbled, and have to be resent, perhaps more than once, which reinforces the argument for smaller files. All this handshaking eats up some of the bandwidth, and while my computer is waiting for a response from one of the player’s computers it isn’t transmitting anything at all, so more time is lost.

Meanwhile, there are other users of my upload speed as well: my VOIP software has to upload my speech to the other players, and background tasks on my computer may be sending queries to their vendors to see if there are software updates to download. And any other computers, phones, tablets, etc. that are using my internet connection are using some of the bandwidth too. Since my wife is one of my players, and she’s got her own VOIP connection, some of my (err... our) upload speed goes to that as well.

The end result is that the upload speed you experience will only a fraction of the theoretical upload speed of your connection. So a file that might theoretically be sent in 9 seconds might take several minutes in actual practice, and the players will be staring at a blank map until the upload finishes, which of course is wasted gaming time. Small is beautiful when it comes to the file size for your map.

Map Scale

By map scale, I’m referring to how many pixels it takes to make a square on the map. Naturally, the more pixels you use, the more detail you can show, but the larger the file size. And because you’re dealing with an area, if you double the width (in pixels) of a square you quadruple the file size.

Of course, you also gain four times as many pixels with which you can depict the contents of that square. And here we being to delve into questions of preference. Some people seem to strive for nearly photo-realistic maps, where you can see the individual leaves on the trees, and whether the silverware has been properly placed on the banquet table. If that describes you, then more pixels per square is your best bet.

Other people, (myself included) take the view that fine details are more likely to serve as a distraction than an enhancement. A discussion mid-battle about whether a tree is an oak or a maple, they feel, doesn’t improve the battle experience one whit, particularly if the DM had thought of it as an apple tree, or simply didn’t specify or care what species it was.

The other consideration for the pixel size of a square is the pixel size of your tokens. While it’s certainly possible to use a scale different from that of your tokens, if you do so you need to perform a re-scaling when you place the first token. It’s not a huge nuisance to do so, but it’s one more step that stands in the way of starting the battle.

Edit: I just found another way size matters! The blogging software is telling me the post is too long. So I'll split it here. To be continued...

Now that I had workable maps, it was time to get some tokens. Back in the day, when my group used to play face-to-face we were using 1st edition AD&D rules, and minis and battle maps weren’t terribly necessary. Back in those days I was a poor college student (and then a poor University employee) and I couldn’t afford to purchase minis. I had a few, but I also lacked the talent to paint them well, so I never used them, and none of my friends used minis either. I did have some cardboard figures (Steve Jackson’s Cardboard Heroes), but we only used them sporadically. Combat was largely “theater of the mind”.

Fantasy Grounds didn’t have a ruleset for 1st edition AD&D so I converted my campaign to D&D 3.5. Since 3.5 relies heavily on miniatures and a battle map, I had to do something about tokens for the characters and monsters. At the time (2008) FG only came with a few portraits, and they didn’t have many tokens for sale either. But I did have the Cardboard Heroes. In fact, I had purchased the complete set as a spiral-bound book at Gen Con the previous year.

So once again I turned to my trusty scanner. While scanning maps hadn’t worked out very well (see here and here for the gory details), I’m happy to say that scanning the cardboard figures worked quite well. Of course I had to open the scans in Paint Shop Pro, crop them to a square centered on the face, resize them, and save the result in PNG format, but that went pretty quickly.

While I had the scanner fired up, I scanned in all the monster figures from the set as well. I only did the cropping and resizing on the ones I expected to need soon, reasoning that I once I had the scanning done I could create the tokens pretty quickly, and I wouldn’t waste effort making tokens I wouldn’t use. Over the years I have built up quite a store of tokens this way.

As you have probably deduced, what I ended up with were “portrait style” tokens. I find I prefer this style over the “top down” tokens because I find it easier to differentiate one token from another, especially when the map is zoomed out, but it really is just a matter of preference.

Over time my collection of tokens has grown considerably. Somewhere along the line I picked up a couple sets of tokens from Fiery Dragon, which covered most of the monsters in the SRD, and that has been a big time saver. I also got a couple PDF’s of cardboard figures as part of an Order Of the Stick Kickstarter campaign, and I’ve converted some of those to square tokens for FG as well.

Once in a while I use a monster that doesn’t appear in any of those sources. When I wanted to use the animated skeleton of a horse to pull a necromancer’s wagon, I had to search the web to find a picture of a horse skeleton, and crop and resize it to make a token. Likewise, nobody does tokens of mind flayers or beholders because of copyright restrictions, so I had to find drawings on the web and adapt them.

Speaking of copyright, I feel the need to step up on a soapbox for a moment. Please bear with me.

All of the images I’m using as tokens are copyrighted by someone (not me). I’m not a lawyer, so please treat my advice with caution, but as far as I can tell it’s OK for me to use other people’s images in my own game. Distributing the tokens to other people, on the other hand, would be disrespectful to the artists at the very least, and more likely it would be outright copyright infringement. I’m not 100% sure if the “work” of cropping and resizing an image makes it “mine” in the eyes of the law, but it certainly doesn’t make it mine in my own eyes. As a person who creates intellectual property, and who expects other people to respect my rights, I feel I need to respect the rights of other creators as well, and so I wouldn’t be able to share such images in good conscience.

OK, that’s enough soapbox time. Back to tokens!

One nice thing about portrait tokens is that when a monster is killed you can rotate the token upside down to mark it. If the token is rectangular and non-transparent (as most of mine are) you can even rotate it 45 degrees so it looks like a diamond instead of a square to make it really obvious.

When all else fails, FG comes with letter tokens. I have used them from time to time, but always as a last resort. Now that I’m used to having a monster’s picture, a letter token just seems a bit jarring. Also, turning them upside down to indicate a dead monster doesn’t always work so well. Someone on the FG Forum used to have a signature that joked about this: “That damned O just won’t die!”

The last item to discuss is the scale of your tokens. But that dovetails into a discussion of map scale, and I have a fair bit to say about map scale, so I think I’ll defer that to its own blog post.

I hope you found this useful. Please feel free to comment if you have any questions, criticisms, or observations. Thanks for reading!

In my previous post I wrote about the difficulties I had with scanning my old campaign area maps from paper into a digital form so I could use them in FG. As you’ll recall, it didn’t go very well. But of course, campaign maps aren’t the only maps we have to deal with as a GM. We have to make dungeon maps as well. And while I was scanning maps, I scanned some dungeon maps along with the campaign maps to see how that would go.

I’m sorry to report it went even more poorly than had the campaign maps. While the dungeon maps were a lot more readable than the campaign maps, and the file size was more reasonable, there was a fundamental problem with the graph paper: the “squares” weren’t actually square once they were scanned. I’m not sure if that was due to issues with the paper or the scanner, but the result was that I could only get the grid that FG applies to align with the squares on the paper for a small area, perhaps the size of a single room. The grid wouldn’t align across the entire map. Worse yet, no matter how hard I tried the graph paper was never exactly square in the scanner, so I always had to open the scan in a graphics program and rotate the picture a tiny bit to get it square. The angles would be small, less than one degree, but if it wasn’t square it looked terrible. Each scan was at a slightly different angle, so I had to tweak it by trial and error each time until I got it perfect.

I soon realized that by the time I did all of that I might as well draw the dungeons in the paint program to begin with. So I that’s what I did! The results were still quite Spartan, but at least the picture was square, and the grid would align properly.

Attachment 13954

That’s a very basic map. In fact, this is the DM map for the first adventure I ran with FG. Yeah, that’s right, I had a different map to show the players! Several maps, in fact. There was one for each area of the dungeon, so there was one for the corridor at the north end, one for the square room, one for the next corridor, one for the first of the three contiguous rooms, and so forth. As you may have surmised, I didn’t yet grasp the purpose of having a mask.

I soon learned how to use a mask effectively, and subsequent maps showed an entire dungeon level at once. Eventually I learned about other mapping tools, and the results became a bit more artistic as well. But that’s a post for another time.

Thanks for reading!