How Do You Make a Gem?

This is not intended to be a how-to. I sort of talked a bit about that before. I’m writing this post because, as I breathlessly blogged before (alliteration!), I released my first gem. I then immediately turned around to start using it. And it was terrible. Yay for version 0.1! So I’m going to try something else.

The thing that sucked so bad was the API, basically. I didn’t really know how I wanted to use it or how best to fit it into a Rails app. I made a reasonable guess and got to work. It wasn’t a terrible first try, but it was a terrible API. However, I’m not sure what better looks like yet. And I think that I sort of got ahead of myself; I put the cart before the horse.

It’s a little like making the transition from drawing on paper to creating art with the GIMP. When you’re on paper, you draw the stuff that’s in front first and you only draw as much of the stuff that’s behind other stuff as can be seen. So you learn to think a certain way about how you build up your picture. In a program that has layers, you can draw in any old order and draw something entirely even if it’s obscured by something else in the long run.

I was thinking that the obvious path would be to develop my little gem of functionality and then use it in the larger Hey Go Vote application. Now I’m starting to think that’s backwards. I’m going to just work on Hey Go Vote and trust that doing so will give me insight into what parts of the announcement machinery can be made portable. Then I’ll extract those bits into a gem and refactor Hey Go Vote to use the new gem. I’m sure I’ll let you know how that goes.

My First Ruby Gem

I just released my first ruby gem, Twitter Alert. It’s intended to be a component of the side project I mentioned forever ago, HeyGoVote. It grabs all the followers for a Twitter account and DMs them a message. The messages have dates on them because their intended to be schedule ahead of time. I’ll crib from the readme near the end, but if you want, you can go read the whole thing for yourself. First, I’m going to talk a bit about my experience writing my first gem.


I used the jeweler gem to create a gem template for this guy. It’s very simple and was a huge boon considering this was my first time. It scaffolds out the directory structure for you, sets up some handy rake tasks and generally gives you guidance on how to structure your gem. The readme for jeweler is very helpful. I won’t bother to restate what it says, but seriously, new to gems or not, you should have a look at jeweler if you haven’t already. One of the nicest things is that it’ll generate your gemspec file for you and also handle version bumping in a semantic versioning compatible way. It also integrates with git and GitHub in some interesting ways.


Jeweler will also handle publishing your gem to “gemcutter” for you, which is nice. I say that in quotes because, of course, is no longer a thing and their stuff all got officially adopted by, so it actually publishes to there. The jeweler documentation, though, all acts as if gemcutter were still a separate thing. This could be potentially confusing, I guess, but it ends up working right, so it’s fine. It does use the gemcutter gem to manage the publishing, so you’ll have to have that installed, and make sure you have a account and api key set up. The api key goes in ~/.gem/credentials as you’ll learn on your rubgems profile.


I’ll crib from my readme example to show the most basic setup:

require 'twitter_alert'

account = :user_name => 'benhamill', :password => 'thisisnotmyrealpassword'

class Alert
  include TiwtterAlert::Alert

alert = 'Very important message.',

account.announce alert

In the wild, I don’t imagine that your Alert class will be so simple. For instance, when I plug this into HeyGoVote, it’ll be included in an ActiveRecord model so I can run a cron job that pulls out tweets that should go out today (based on the date) and sends them all.

I haven’t plugged this into code yet, and note the version number 0.1. The tests pass, but they may not be comprehensive and I might have botched something up in my publishing, but it looks like everything’s working to me. My next step is to start building up HeyGoVote and using twitter alert in it, which might reveal some needed features. In the meantime, I welcome feedback. Leave a comment here, or fork it and issue me a pull request, if you have an idea.

Final Post

This will be my final post on this blog, but that’s not as dramatic as it seems. I’ve been setting up a Wordpress install over at and moving all the posts over there. I’m still messing with CSS to make it look right, but that’ll just be a little while. If you like, you can go ahead and subscribe to the feed over there. After this post, all new posts will go into Wordpress.

In a couple of months, I’ll make it so that points at the Wordpress install, too, which will probably break your feed if you’re subscribed to this one. So, go ahead and change your feed or bookmark or whatever. The first new post on the new engine will be about the ruby gem I just released about 20 minutes ago.

Open Source Fail

Currently, this blog runs on a great Rails-based blog engine called Enki. I initially installed it here because I liked the idea of hacking on the engine a bit or looking under the hood as a learning experience. And it was educational, at first, but more and more, I find that I don’t really want to mess with it. I’d rather the blog Just Work.

I’m thinking I might look at installing Wordpress and running Garbled that way. I’m not sure how it’ll go, exactly, and it feels a little dirty, being php and all. But, really, blog software isn’t something I really have a big interest in. I suspect that the Wordpress code base might not be as awesome as I’d like, but, honestly, I won’t have to look at it and it has a lot of neat features that I’ve gotten used to on the other blog that I write at.

However, the real driving factor is in the idea that Wordpress is so widely used and stable. Comments have been broken here for a while and I’ve been too busy, distracted and/or lazy to track down why. In fact, as I was writing this, @jcsaltergo discovered that I was having some kind of Passenger issue. Then it vanished. I don’t really relish tracking it down.

I’m hoping that I can make the URL for the feed stay the same, but in case I can’t, consider this fair warning, that you might have to resubscribe when it breaks. Similarly, I’ll have to see what the best way to port all the posts is. I’m suspecting the copy/paste will win for simplicity.

Efficiency in Algorithms Everywhere

I have heard UI folks talk a lot about how everything has a UI. Doors have a UI, you know? If there’s a horizontal bar, it’s clear that you’re supposed to push. If there’s a vertical bar, that invites you to pull. It’s a poor UI if you walk up and the door looks like it wants you to pull, but, in fact, requires you to push. I’ve been seeing UIs everywhere since I first heard this idea.

I realized just the other day that I also look for efficient algorithms everywhere. I think I may have been doing it for years and just not realized it. Maybe other people do this, too, but I’ve never heard anyone say it out loud in quite this way. Maybe I’m insane or OCD. I’m just going to present some that catch my eye frequently (or have recently, anyway) and rant about them. How’s that for a thesis?

The Cash Register

I often buy things at stores. Most of my transactions are via credit card. Especially when I’m buying, say, lunch, the transaction is so small that the store doesn’t ask me for my signature (let alone ID). So after placing my order, the employee tells me the total and I hand over my card. They then swipe it and stand there while we both wait for the receipt to print out and the register to see that the transaction went through. Then I get handed back a receipt (maybe with an order number) and card at the same time. I have to keep the receipt out and put the card back in my wallet. I may also have to carry away a cup to be filled with soda.

Frequently as I’m handed my receipt and card at once I’m told, “ThankyouforcomingtoRestauranthaveaniceday?” in a big rush and then glared at because it takes me a second to put my card away, pick up my receipt and cup and move along. If time is such a big deal (and during a lunch rush, let us understand that it is) that you’ll glare at a paying customer over it, perhaps an ounce of algorithmic analysis should go into minimizing it, no? If, for instance, I was handed the card back immediately, then I could put it away and be done with it before I am handed a receipt and cup. Then I can immediately move and let the next customer up. This increases the number of times the employee has to reach across the register and the number of times I have to reach to meet them, but that action takes much less time than it does for me to operate my wallet or for the credit card machine to get a response from the credit card validation server. It bugs me.

The Bus

Some people seem to think that there are two discreet tasks when boarding the bus: Waiting-in-line-to-pay-and-board and swiping-card-or-paying. This is sort of ridiculous to me. Clearly you can get your money or card out while you wait. In fact, unless you just managed to catch it in time, you probably saw the bus coming a block away or so, which gives you plenty of time to discover that your bus card is not in the pocket of your backpack that you thought it was and frantically search for it before (whew) finding it… all without making several other people wait.

What would be even more speedy, though, would be to be more organized on an even higher level: always keep your bus pass in the same place (infrequent riders, of course, won’t benefit from this). I generally ride by bike when I take the bus, which means I have to load the bike on the front before boarding. It’s not really possible to load it while holding a bus card, but I still manage to have it out and ready by the time I walk around to the front door and pay terminal thing. That’s because it’s always in the same spot in my wallet.

Making Titles For Wrap-Up Sections Sucks

The connection of this post to programming is perhaps tenuous, but hopefully you can see where I’m going. I wish laypeople knew just a little about thinking in this way and applied it to stuff like this. I like to think doing so has made my life easier and I feel like it’s let me be more courteous to those around me.

Also, this was intended to be my February post, but I was trying to come up with another example. In the interest of staying in the habit of posting, though, I’m just going to hit publish and call it done. Feel free to complain about that in the comments.

Thoughts on Google Wave

The buzz about Google Wave has worn off considerably (I’ve been unable to hand out the 18 Wave invites I have; if you want one, send me an email), but I also feel like I’ve used it enough to talk about it intelligently. I hear a lot of people still speak about Wave with confusion. They ask things like, “What is it for?” and “What am I supposed to do?”. People talk about running out of things to do in Wave. I’ve never really understood the thinking that leads to these quandaries. I tried analyzing it to understand it, but I don’t get it. So I’m going to try to explain how I’ve been thinking of it and hope that someone else can maybe bridge the gap for me.

What Is It For?

In a word: collaboration. It is not quite email and not quite AIM and not quite a wiki. It’s all of them. If you’re willing to wave someone instead of emailing them, you’ll get only a little bit of win out of Wave, which is that you can add someone in later, go back to edit old content and reply in line. That’s nice and all, but I think not enough that people really notice. Especially if the other person they’re trying to communicate with isn’t checking waves frequently.

The real win, in my experience, has been when I’m working with someone on some kind of document. For instance, some buddies and I want to put together a Gowalla Trip around the UT Campus. We started with a snippet that just had a big bulleted list of ideas from me. Below that, we discussed other ideas to add or not and all three added them to the list. Then we’ve been going around making the Spots and when we do, we add the url to the listing. It’s been a wonderful work flow; some of it has been real-time like a chat room and some of it has been asynchronous like email.

Similarly, I was working on some code and couldn’t figure out what was going wrong with a specific bit of it. I IMed a co-worker about it and he was trying to help me, but it was cumbersome because he couldn’t see the code (it’s a big campus). We switched over to a wave, where I pasted the code in. He could see it, edit it, reply in the middle of it. So much more efficient than using AIM.

So that’s the trick. Wave doesn’t have a lot of win over email if you’re telling your mom when to come over for dinner next weekend. It has a lot of win when you’re working with someone on some kind of document.

I Ran Out Of Things To Do

Well, yeah. That’s a bit like saying you ran out of things to do with your table saw. The same charge could be levied at gmail: if you don’t have any more emails to write or read, there’s not a lot else to do. Especially before people get comfortable with what wave is good at, you’re not going to have a ton of new waves. I, however, have had plenty to do in wave recently. Partly because I’ve been trying to find almost any excuse to use it so I could see what it was good at. This meant people replied to me there and some stuff wasn’t so good, but mostly nothing was amazingly worse in wave than whatever other tool we’d’ve been using for that interaction else wise.

So Wave Is Perfect?

No. In fact, I’ve found something that it’s pretty bad at or at least very awkward at: random chatting. If I IM a friend across the country to see how he’s doing and our conversation wanders in topic, I feel like wave is sort of too much structure. On the one hand, it’s nice to be able to manage threading as topics shift and change (if I post a tangent, we can basically split the conversation thread there). On the other hand, it’s kind of a pain to have to manage threading as topics shift and change. When we switch topics, do I want a new wave? Not really. I’m just not sure what to do with that kind of thing. Maybe it’s a matter of discovering the right work-flow, but maybe not.

Relatedly, since Google has taken the liberty of linking my gmail/gchat/gcal/etc. account with my wave account, it would be nice to be able to take a gmail thread or a gchat exchange and import it into wave for further editing. This is especially when I’m in a random chat and the topic shifts to some project we’ve been collaborating on. I assume this is something that’s on the horizon, but as I’ve been using wave pretty regularly, I’d get a lot of mileage out of it now.

I also think there are some things wave is or will be good at that no one’s discovered yet. I think it has huge potential and I’d like to warn people off of giving up on it too early. Like so many things that are super valuable to know how to use and can change the way you work (or work/play) for the better, it’ll take some getting used to, some learning and some exploration.

My Git Talk at Austin on Rails

At the last Austin on Rails meeting (Nov 17), I gave a talked entitled Practical Git Quickstart (Prezi link). The slides don’t have a lot of content and mostly underscored what I hoped to talk about. I blew through them in about ten minutes or less. The short of it is that I feel like a lot of git tutorials and introductions start off with the high-level stuff and that, especially for people new to git, that that’s confusing. My goal was to give git newbies the most basic commands they’d need to be able to use git on a daily basis so that they could build their own abstractions before diving into the more heady stuff. I was aiming for an 80% solution to that, anyway.

After I finished the slides, I fired up a command line and an editor and just worked through some stuff. This post should sum up what I talked about, more or less. I started out covering the same stuff I covered in my previous git tutorial post, so maybe go check that out first. It should get you through setting up a new repository, adding files to the staging area, making a commit, checking your status and committing to a remote repository.

So let’s pick up there, with remote repositories. The way you get code up to your repo is with git push origin master. Once it’s up there, other people can get at it. If you recall, you told git where your remote repo was going to be with git remote add origin<username>/<project>.git. Someone who wants their own local copy of your repo does so with the clone command like so: git clone<username>/<project>.git. That will create a directory wherever the command is issued, named <project> and pull down the current state of the remote repo. Then, that person will be able to push their own changes, etc. This is all, of course, assuming they’ve got permission to do so.

So this new second person makes some changes and pushes them on up. How do you get them? Well, sensibly, the opposite of push is pull, so you issue git pull origin master. This is actually a two step process that’s just for convenience. I don’t want to get into the plumbing too much, but it basically grabs the state of the remote repo (git fetch) and then attempts to merge (git merge) it with your local stuff. So that’s the most basic case of working with someone else on a project, or working alone on one using different machines, if you like. I use that case all the time.

So what about conflicts? If you both make a change to the same file and they push it first, you’ll not be allowed to push because git can’t handle the merge on it’s own. Similarly, if you try to pull, it will do the fetch part, but be unable to merge and will tell you so. You can use git diff to see what the changed were and do the merge yourself. You can also use git difftool which is awesome, but takes some setup, so you should look into it later on (I skipped it in my presentation).

Once you handle the conflicts, you’ll add the conflicting files to the staging area and make a commit. With all merges, I should note, git makes a commit just for the merge, so when you have conflicts, it’ll have staged the things it can merge on its own and left the conflicts unstaged. As you fix them, you stage them and then you commit the merge commit. Git doesn’t know if you really fixed the conflicts, so you can git add whatever version of the file you want, even a broken, not-conflict-resolved one. Just be aware.

That was more or less the end of my ordered presentation. There were some questions afterward and I’m going to attempt to sum up the discussion that followed, here:

First off, I wanted to mention how you ignore files in git. Unlike subversion, there is no git ignore. If you want git to ignore a file, you have to add it to a .gitignore file. This file is a list of patterns that git will ignore for the directory it’s in and all directories below it. So you might have one for a python project like this:


This will ignore all compiled python code (*.pyc) and everything in your tmp/ directory. I was baffled by this when I first came to git, but it’s not really that hard. Note that you generally commit your .gitignore so that others can share it. If there’s something you want to ignore on a per-machine basis, rather than a per-project basis, then you need to turn to my next topic.

Which is global git preferences. On Linux and Mac, git will look for a file in your root directory called .gitconfig and take global behaviors from it (it’s tricky on Windows, and I haven’t figured it out to my own satisfaction, sorry. If someone asks about it, I’ll try to sum up what I know in the comments). In my other git post, I had gone through setting up a repo on GitHub and said to follow the directions there. Two of those steps were these:

$ git config --global "<your name>"
$ git config --global <your_email>

Those created entries in your ~/.gitconfig telling git your name and email address. You can also declare a global ignore file there. I like to call mine .gitignore. This is shockingly original, I know. On the machine I’m typing on right now, my ~/.gitconfig looks like this:

email = blah@blah.blah
name = Ben Hamill
excludesfile = /home/ben/.gitignore

I bet you can guess it, but just in case, you can either put your excludesfile in manually or do git config --global core.excludesfile /whatever/file/path/you/want. For reference, my ~/.gitignore looks like this:


A .kpf file is a project file created by Komodo Edit, which I used to use for all my code editing needs, but not since I switched to vim, which is what creates *.swp files.

Finally, someone had asked about git stash. It’s what I’d consider a more advanced command, but a lot of git fanboys sell it hard because it’s cool and svn doesn’t have it. However, as cool as it is, I think it can get you into a lot of trouble. Basically, you can be working on something and issue git stash and git will store whatever changes you’re in the middle of and hide them away, putting your repo back in the state it was right after the last commit. You can then work on something more pressing, make commits, merges, new branches, whatever and when you’re done, issue git stash pop and it applies your changes back (if it can).

The really hairy bit is that you can name stashes and so have more than one stash going at once. While a super organized developer might find this really useful, I find that it’s easy to get stuff lost in there. You don’t want to have tons and tons of stuff stashed and not remember, anymore, what changes were in which stash, etc. I advise, as a basic rule of thumb, that if you’ve already got one thing stashed and find yourself wanting to stash something else, then you should be looking at branching, not stashing.

I think that about covers it. I think someone recorded audio of my talk or maybe video. If it ends up posted somewhere, I’ll come edit this post with a link to it. If you were at my talk and notice something I talked about then that I haven’t covered here, let me know and I’ll try to amend. Or, if you weren’t there and feel there’s a topic you have questions about, drop it in the comments and I’ll do what I can.

Vi Improved

I recently started using vim on my Linux machines for development (actually gvim and I just haven’t gotten around to installing it on my Windows partition). I’d tried to learn it some time ago with the understanding that it’s awesome, but it didn’t catch on. I know a lot of smart people who use it and it was always one of those things that I felt would be really valuable for me to learn, but–it was hard.

Well, now it’s easy. @adambair mentioned this blog post by Derek Wyatt. It’s a collection of videos he made introducing you to the most basic commands in vim. Enough to get your feet under you so that further research on your own has something to stick to. They’re awesome.

However, the reason they’re awesome is not just that he takes you step by step through the most important stuff or that he’s lighthearted and friendly-sounding. The awesome part is that he shows you why it is that vim is so raved about. If you try to learn vim thinking that it’s like TextMate or NotePad or something, you won’t get it. And until you get it, there’s very little impetus to get over the learning hump (or through the dip, depending on which way you chart things in your head).

The key to understanding, for me, was realizing this: You should not be spending most of your time with vim in insert mode. You should not be typing and selecting in the sense that Word teaches. You should be doing finds and replaces and yanks. You should be operating on your code with macros. If you’re writing new code, great. You’ll be in insert mode for a while, but even then, you’ll want to invoke something that’ll set up your class structure with maybe some default methods in it or something. And as soon as you’re done, you’ll want to be jumping around by line number, moving to a specific character in a line, replacing a segment of a line with two keystrokes. Really, just the movement possibilities blew my mind. So, go watch the introduction.

New Roleplaying Blog

For those of you who thought my last post (about role playing) was interesting, I have some news: I won’t be posting about that stuff here. I will, however, be writing on the topic. My friend, Stewart, and I realized the he and I would have a lot of fun writing together on a blog specifically about role playing. So if you are interested in our thoughts on that topic, we’ve called it Maximizing Rockmost. We’ve started off with several posts (some of which are expansions of material from my post here) so you can see what sort of thing we’re likely to be writing about. I’m looking forward to it.

For those of you who wonder why I’m blathering about RPGs and wish I’d get back onto a technical topic, don’t worry. I’m presenting at Austin on Rails this month about git (along with Mike Subelsky of OtherInbox). I plan on blogging about that presentation. I also want to write about vim and about ruby koans and about making my first ruby gem. So there’s technical topics in the pipeline. Never fear.

FYI: My Tastes in Role Playing Games

This is one of those posts bloggers write so that they can repeatedly refer to it later on. I intend this to be a short introduction to role playing (as in nerds at a table with dice, not a couple playing Santa or whatever your kink is) followed by a bit about my tastes and general habits regarding the hobby.

What’s an RPG?

If you want, check out the Wikipedia article on it, but my definition of a role playing game is this: There are some number of players and generally one Game Master (Dungeon Master, Referee, etc. terminology varies). The players and Game Master (GM) are telling a story together. Each player makes a character (a Player Character: PC) and they constitute the main characters of the story. In order to offer some tension for events where chance plays a part in the outcome, the group is generally using a set of rules that uses a randomizing tool (various kinds dice are most popular, but I’ve heard of cards, for instance) to help decide if the characters succeeded or failed at certain tasks. The important thing, here, is this sentence: The players and GM are telling a story together.

The GM is in charge, basically, of running the simulation, as it were. He (please don’t take offense at my use of pronouns, Lady GMs) manages the world, figures out what the various not-protagonist characters (Non-Player Characters: NPCs) are doing, arbitrates the result of any actions taken by the players the outcome of which is not guaranteed, etc. The other thing that the GM does is he plots the stories the group tells together. Plotting for an RPG campaign, however, is significantly different from plotting for a book or movie because the players each control one of the main characters. So the GM ends up getting a general idea of where things are headed, what the major goals of various NPCs are and then how the PCs fit into it all. Then the PCs get in there and muck things up in interesting, fun ways. This collaboration in authorship means (like laying out a web page) letting go of a certain non-trivial amount of control as compared to, say, a novel author.

The Ways of Ben

In my specific group, I’m the GM. I have, right now, three folks playing in the campaign I’m running. In many schools of GM thought, game play from one sitting to the next are strung together to form a “campaign”. The term originates from D&D’s origins in table top war gaming, so it can be a bit of a misnomer as it’s used today. What constitutes “a campaign” varies widely. My definition, which you’re about to read, is not in the majority, but it is how I do things.

In my social circle, a campaign is like a book: It has a beginning, middle and end. There’s some unifying plot that ties it all together. When the plot is done, those characters go away and you read an entirely different story (please ignore Robert Jordan for purposes of this analogy). A lot of people think of a campaign and the game as one and the same. They might be confused or skeptical about the same group of people just putting down one group of characters and making new ones. Campaigns without an end point in mind from the start can last for years and years and they generally increase in power level (trying to out do themselves over and over) to a place where the characters are fighting gods or eating planets or something suitably EPIC. People have fun doing this and that’s great for them, but it’s not for me. It starts to feel like a TV show that’s been running too many seasons in a row (better bring in Henry Winkler and some skis). I like a narrative arc and I like to pick the amount of epicness from the get go and have it be relatively stable. Also, having campaigns with a designed ending lets me change settings and try on a lot of different ideas. Which leads me to my next point.

My system of choice is GURPS. You can follow that link or not, but suffice it to say that it stands for Generic Universal RolePlaying System. It’s basically a toolkit of rules without any setting information (contrast the famous Dungeons & Dragons, which describes the world the game is played in to great detail). The thing I like about this aspect is that you can play a D&D-like fantasy campaign to completion, then play a space opera and then play a police procedural or something. The ability to try out one thing for a while (length of my campaigns varies wildly, so take that with a grain of salt) and then entirely change gears for the next campaign is a big draw for me. As a GM I really enjoy the world-creation aspect and so I’m constantly thinking about what worlds would be fun to play in and what stories would be fun to play out in them; what kind of interesting people might live there. You get the idea. That’s not the only reason I like GURPS, but I don’t want to evangelize too much. Maybe that’s a future post.

Another thing I do that I’ve heard very few people talk about is I’ve got a GM consultant. This is new as of my most recent campaign, but it’s worked out so well, I can’t imagine why I’d stop doing things this way unless the consultant turned into a player. Basically, the friend who introduced me to GURPS moved away and, in order to get his role playing fix, offered to help me hash over things with the world building of the campaign I was thinking of running. I recommend this technique to every GM that can swing it. Having two minds on the task, as long as you work well together, is an incredible boon. Your NPCs will seem more real and your world can afford to be more complex. It’s easier to track more events happening at once and you’re both going to think of cool things that the other wouldn’t have. I feel like it’s been multiplicative rather than additive to the quality of the campaign world.

Most RPG groups make a “party” or other group of characters that more or less always act in concert. They make decisions together and go do things all as a group. Lengthening the parade of unconventionality, that’s not how I do things. If your character is not in the scene, you’re not in the room. For some campaign settings, that means players (especially early on) can spend a non-trivial amount of time in my living room playing Rock Band or whatever instead of role playing. The win is that by containing information, you can, for instance, more easily dole out clues to each of the players and have them piece it together later when they’re all in. This is cool for the players, not for the GM, I should note. The other thing it does is it lets each player get used to his character and how to play him without the noise of other players doing the same thing; to establish a sort of a base line. It takes a while to really figure out how to inhabit a character you’re playing and unlike other kinds of acting, there aren’t really rehearsals.

I’ve implied that there’s a stage, early on, where the characters aren’t spending a lot of time together. This is a symptom of what my GM-consultant and I call the Dann-style Campaign (Dann was the guy that introduced my consultant to GURPS). Dann-style Campaigns are very formulaic, but it is a formula that works very well. There are 3 (less commonly 4) PCs. They don’t know each other at the start of the story and they all have different goals, needs and reasons for doing things. There is some kind of plot or conspiracy or mystery going on and their various goals draw them into being involved in it, which causes them to meet and discover/uncover/solve it together. The entire campaign general centers around a single, well developed location (say a single city). The fact that the characters are strangers and have different goals means they don’t trust each other right off. The fact that they have different (possibly opposed) goals means they want different things to get done or have different priorities for things to get done. Together, those two facts make it not uncommon for a player to say, “Great. You guys go do that, I’ll catch up with you later,” and then go do his own thing.

I hope this makes a bit of sense to the uninitiated. If you’ve read anything by William Gibson, he uses this sort of story telling a lot. There will be several independent stories going on that, in the end, all have to do with each other in some way and come crashing together at some point in the tale. Now, Gibson tends to have things come together in the final act. In a Dann-style campaign, you generally want the PCs to all meet and start collaborating around the half-way point of the first act. “Act”, here, is a vague unit of story-telling, not anything specific, mind.

Or think of a show like Lost, where the characters are strangers at the start and there’s a high level of distrust and paranoia about each other. People spend a fair amount of time doing things on their own. From setting to setting, of course, the level of distrust can be dialed up or down. In Lost, the level of distrust is rather high between some protagonists and there’s a fair amount of alliance shifting as time goes on. In a Dann-style campaign, you wouldn’t have as many PCs as Lost has main characters and so shifting alliances between them would be somewhat tricky to do if you wanted it.

All of this is really in service to the next post I want to write which addresses some ideas I’ve been batting around about how and what to vary up in the Dann-Style formula. It seemed that, before I talked about variations, I should do a kind of an introduction to my style and, then, that an introduction to what an RPG is, etc. seemed appropriate. If you have questions about anything I’ve put here, post a comment and I’ll be happy to answer it. Be warned, I may try to convince you that you should give role playing a try.