Phystus

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!