Revenge of the Blog

Hey everyone, happy New Year. Hope you and yours entered 2008 happily and safely.

After a long winter's "break" (which actually involved not only the holidays but a major purge/cleaning of our house, rewiring of my basement, and gutting and reconstruction of our bathroom), I'm back in the saddle and working away at a number of projects, including FantasyCraft (finally!).

First up is Cloak & Dagger, the fantasy espionage setting, which is actually coming along pretty well. It's fun to do a mishmash setting of some of my favorite ancient cultures in a genre that's both familiar and has plenty of room to play in. Espionage fantasy has been a subgenre that's largely virgin territory in nearly all media, so I'm hoping this grabs people where they live. There seems to be a fair amount of excitement from some of the diehards, so I'm hoping we can set it off :) If you haven't seen anything about C&D yet, click here for the teaser.

Aside from that and bathroom repairs, work is finally progressing on a board game I'm working on with a friend alongside my Crafty stuff. The first test went pretty well, with the game system holding up - now to add some more zip. Our playtest group was big enough to accomodate 2 tables and lots of good feedback, so it was a lot of fun seeing things running at the table. It's been a fun project to tinker with, and I'm glad to see my Spycraft-honed design chops are portable outside the box.

Speaking of which, World on Fire and 2.0 SP have *finally* hit the stands locally, but the good news seems to be retailers can't keep them in stock. I'm hoping that doesn't mean they stop stocking it, though :) Sales appear to be good, if the PDF and reports from the field are any realistic indication, and I think Mongoose's distribution machine is finally hitting its stride.

Well, I think that's it for my requisite "signs of life" post. Keep on coming back here or over in the Crafty blog for more info as we move forward...cheers lads.

"Just Deal With It."

I've recently been trying my hand at hyperbole when discussing game design - it's a time honored tactic that goes back to the earliest days of both gamers and game designers and I thought I had better get with the program. There are certain things I never do or always assume as a designer, which I think many designers could benefit from - call it hubris, call it experience...it all works for me.

The idea of asking a player to cope with a game or rule is just one of those things that wrings the hyperbole from me like Crest from an alumninum tube. Coping, in my mind, is the polar opposite of what gaming means; we game to make our own fun, not to deal with someone else's ideas of how that fun should be structured. Everytime you ask a player to "just deal with" a rule (not a ruling, mind you, but a rule itself - rulings are vital to keeping a game working) you are saying, 'My fun is more important than your fun,' and that's anathema to a good, healthy game group. Gaming is by its very nature - a group of friends telling a story together - a democratic exercise, and needs to remain as such as much as possible.

At the designer level, believing you can tell players to deal with your specific concepts is even more seductive and even more unforgiveable. There are many guys who don't write settings in their books, but write their campaigns. While there is some utility in this approach from a procedural standpont, writing a campaign, which is built for the people you game with specifically, ignores the many possiblities and interpretations that actual play groups bring to the table.

Making a game that respects the play group's vital contribution to the life of that game is both thrice as difficult and half as rewarding for the ego - people are not playing your game now, but rather playing a game you equipped them to run. It forces you to consider what people might want to do with your game beyond your vision, and worst of all, accept the distinct possibility they just don't give a fuck what you like or what you think about how a game should run beyond the mechanics.

This is exactly what makes writing games so challenging for me in the beginning, and so rewarding at the end. It's like how I describe game design to non-gamers - 'it's like writing the beginnings of 50 novels, where you don't know the characters or the plot, and have an editor who can do whatever the hell he wants to your manuscript once you put it down.'

So game designers, my message to you is: accept the fact you're enablers, creating the possibility for good, fun stories rather than telling them. That's why you're not a novelist...that and the fact nobody cares to hear about your character.

Just deal with it.

Developer's Digest: Research and Design
I'm currently putting together some materials for training new Spycraft designers for next year, and a thought occured to me that I thought I'd share. One thing I kept hearing from writers when I was at Gencon Indy this year was how fast people could write - 1000/2000/5000 words an hour, etc. I didn't hear how many of those words were kept through edits, or how many rewrites the editors went through with them. From the other side, the developers I spoke with talked about how quite a few writers were turning in pieces that was poorly thought out, written, or developed. Personally, I think there's a direct correlation, and this leads to the vicious cycle of low pay and thus lower quality output.*

The hub of this issue lies with research. I believe that knowing your topic - whatever it may be - is the lynchpin of good game design, and this applies to both setting and rules development. But when writers are pushed by low per-word rates, it's often the first thing that is cut as a luxury or worse, a waste of time. If you've read Spycraft material, you know we pay a lot of attention to our research. I like to think the Faceman/Snoop Class Guide is a good example of this - Clayton and I busted our humps to really make it representative of both cinematic staples and real-life intelligence and investigative practice. For the European Commonwealth Chamber Book, I delved into political thrillers, cold-war spy stories and conspiracy theory films to help make the tension of the chamber felt palpably down to the classes and feats.

But your game doesn't have to be realistic to benefit from research. A good example is Midnight, the first DnD game that I feel really captures Tolkein's vision of Middle Earth in a way that is inspirational for players, doesn't railroad them and leaves the iconic LotR characters and story entirely out of it. Wil Upchurch, Greg Benage and Jeff Barber** (Midnight's developers) obviously spent a lot of time looking hard at Tolkein's body of work, considering what makes the trilogy so damn inspiring, than building their own story and mechanics from there. It paid off - Fantasy Flight won an enNie for Midnight, and even my enthusiasm(an even rarer thing when it comes to Tolkein send-ups). Even if you are developing your own setting or mechanics, research is critical. Learn what has come before you - historically, storywise, or mechanically - to learn what you do or don't want to do. If working on a line, read the books that came before yours; if starting a new one, look at similar games, do a little research into history for similar events and inspirations, look at the game creator's notes, or even read your first notes again.

Research is the grist that makes the game believable, and as we all know, gamers are into gaming for the suspension of disbelief. They want to pretend to be rangers and spies and cyberpunks and jedi, not a group of twenty- to forty-somethings sitting around a table in a basement rolling funny plastic polyhedrons and eating chips and drinking Mountain Dew ;) Research lets you make a place live; and when you know the place you are writing about in and out, when you can make that place come alive in the minds of the GM and in the people listening and actively joining that world, that's good game design.

* Mr. Clayton Oliver and Mr. Will Hindmarch have good point/counterpoints to the views posted here, which are worth reading. Check the feedback - they are also right. Yay for pluralism!
**Edit - added the names of Mr. Benage and Barber to the list of Midnight's developers; good job, fellas!

Developer's Digest: Designing an NPC Class
I'm still trying to downshift from Spycraft prestige class design so I can knock out the stuff for Dragonstar (and the corresponding article) soon, but since I've got a little pick-up work for Scott Gearin on The Shop Threat Book, I thought I'd do a mini developer's digest on NPC class design. I'm not going to bother with the formulas (partially for NDA reasons, partly becuase it's been covered in the Spycraft forums pretty thoroughly) and instead focus on the principles of balance. Please note, these are all rules of thumb rather than set guidelines...balance is 90% persperation and 10% inspiration most of the time.

When designing an NPC class, I follow the same rules I do for creating standard base and prestige classes - I do my homework, lay out the the general mechanical concepts I want to use, and develop all relevant subthemes - then I get on to work. NPC classes by their very nature are supposed to be weaker than their PC class counterparts - in Spycraft, minions usually don't even have a class (in DnD terms, they're all effectively Warriors), this should be halfway between a base class and basic minion. Because minions are all shooters, I also try to develop NPC classes that actively work against that basic 'goon with a gun' build (maybe by altering stats like base attack bonuses, saves, and other goodies, changing up skills, etc). NPC classes should also effectively be prestige classes for minions - if the base minion is the generic goon type, NPC classes by extension should be specialized and more narrowly focused. That means thier abilities should concentrate on a special schtick, rather than improving on what is already presented in the basic minion. These new definitions can also create new archetypes - sure the Bond villains have the guys in yellow jumpsuits with guns, but they also have scientists pulling random levers in the secret rocket base and guys who drive the submarines as well.

Example: In this example, let's say I want to make a suicide bomber type - a guy who sits in his basement stirring a vat of styrofoam and orange juice to make napalm bombs that could slaughter dozens of people at a time, the sorta unhinged lunatic that we find in movies like Blown Away. Spycraft has a prestige class called the saboteur that will provide a template for what sort of abilities a player who wanted to be a bomber might have, so that will be a chief reference in this project. First thing the guy needs is full skills in his key skill needs - that means Demolitions. The saboteur also specializes in sneaking around (you gotta get close to the bomb site too), so we give him Move Silently and Hide as well. And for gravy, since this guy is might be disarming a bomb with 3 seconds on the clock, Concentration seems to fit too.

When selecting class abilities, the easiest way to work is to follow the rule of halves - each level of an NPC class should be treated as if it were only 1/2 a level in a PC class when it comes to abilities (this is usually fair, as most PC groups will be facing 2 or more of these guys at a time). Therefore, while most PC classes get a new class ability each level, minion classes get a new class ability every other level (plus 1 at first), and by extension, if a PC class that is similar to the NPC class gets an ability at, say, 2nd level, the earliest the NPC class could get that same ability is 4th level. I also try to never give an NPC class any feat higher than the second tier of a feat tree (ie, he may get basic and advanced skill mastery or power attack and cleave, but never grand skill mastery or great cleave) - 3rd tier feats are powerful and usually beyond the competence presented with your standard NPC class. Finally, I never give an NPC class more than 3 feats - while it's tempting to just create a chain of feats, the basic rules of minion design state you can't buy more than three feats for a minion type, and no PC will earn more than 3 level based feats in 10 levels.

Example:The saboteur PC class I am looking at provides lots of tasty abilities, like an Explosives Basics/Mastery/Supremecy feat tree, supporting feats like Skill Mastery for the Stealthy skill feat, and lots of little toys for making bigger booms. I can pretty much throw out any abilities after level 5 or 6 in this class - the rule of halves dictates it. So I'm looking at a few feats based on explosives use, some sneaking around sorta stuff, and abilities for getting away from bombs. Because Demolitions is absolutely key to the bomber's job, Specialty in demolitions is a good starting ability - much weaker than the 1st level ability of a PC class, but it works here. Explosives Basics and Mastery look good, and it fits our feat formula. Because explosives are so expensive, I also give him some free BP to spend on explosives, grenades and mines only - after all, what's a mad bomber without a bomb? Finally, this guy needs to be deadly - I go back to the saboteur and find the Chain Reaction class ability, which basically nullifies Evasion. Not overly powerful, but very good for a high level ability.

With my concept, skills and abilities chosen, I shuffle them around to find a string of abilities that feels right. This part is the hard part to describe when it comes to balance - you have to feel it out, and you can only learn that through experience. When laying out multi-tier abilities, I try to spread them at least 4 levels apart, with one ability of a different nature in between. This prevents a rapid progression of powerful feats early in the class, which means a twink GC would only select the most powerful abilities then move to something else (in DnD, I call this the Monk and Ranger syndrome - you get so much stuff at 1st level, it's almost always worth taking 1 level just to get all the free stuff). Finally, we do ability scores. I go back to a similar PC class and look at its basic progression, then adjust the NPC class's progression to taste.

Example:I start shuffling around the abilities of the bomber. Specialty is first. At 2nd, I have a tough time - do I want him to have some bonus budget points for extra bombs, or should he have Explosives basics? Finally, I decide that explosives is so key he needs the feat first, and the bonus BP ability comes at 4th. At 6th, I insert Chain Reaction - since minions can't crit, it's not nearly as powerful in the hands of the minion. Then bonus BP again at 8th and Explosives Mastery at 10th (the extra damage provided by this feat bumped it up to the 10th level ability). Ability scores are simple - he's a competent fighter who doesn't do it for a living, so medium BAB and Initiative work. However, the guy should be able to survive "accidents" in his work, so a High Reflex and Defence are important. Strength of mind and body don't really matter, so low Fort and Will saves work.

And that's pretty much it. It wasn't as short as I had hoped, but there you have it. Now get out there and do some good work!

Guest Developer's Digest - The Cool Theory of Game Writing
Clayton Oliver, my compatriot and counterpart from the Spycraft Design Team (AKA Jaeger from the Spycraft Forums), has submitted this guest contribution for the developer's digest. It's quite true, and an excllent rule of thumb. Read on:

"Steven Brust, one of my favorite authors, has a Cool Theory of Writing. It goes something like this: write about stuff that you think is cool. You will continue to enjoy your work this way - and people who share your preferences will read your writing and think it is cool, and thus you will gain fans.

I subscribe to a similar theory in game writing. I try to only write game material that I think is cool. More importantly, I'm a fan and a player before I'm a writer. I've been gaming since I was seven or eight, and I view my work in the gaming "industry" not as a job (you usually get paid for a job) so much as a contribution to the hobby. Thus, I rarely work on stuff that I don't want to use in my own games at some point - usually as a player. Frex, when I started writing the animal rules for African Alliance, I knew that I wanted to be able to make an alligator who was trained to open a refrigerator and fetch beer, because that's what I want my Cajun wheelman/martial artist to have as a pet.

Well, *I* think it's cool, anyway. But you get my point."

Clayton brings up an excellent point here (and touches on the last rule from my first column - don't expect to get rich) - that it is important to remember why you are writing, and always keep that at the heart of your work. While we may have to grind away at our day to day jobs to keep our houses/cars/mistresses, the industry is about doing something you love; something many burnt out or jaded designers lose sight of. Thanks Clayton!

Developer's Digest - Designing a Class from Scratch Part I: Planning
So yesterday I received my copy of the Dragonstar Starfarer's Guide, graciously passed along by Will Hindmarch, so I can get started on designing some classes for the new book he's putting together for the line, and I thought, 'This is the perfect time to share some of my insights into class design from the beginning.' Since I'm coming into Dragonstar totally cold, this might be a good opportunity to bring you all in.

First thing is to come up with a theme. Typically, the project manager hands you an outline of the book which contains major themes of the book and often a list of classes he/she would like to see. In this case, Will has provided me with 4 archetypes for the book that I should work to, as well as core classes that might provide good entry points (ALWAYS try to make this more than 1). Each theme needs to be distinct both mechanically and in presentation, so I generally brainstorm a series of subthemes based both on the prestige class's 'schtick', as well as the base classes that might provide the best paths for entry. If I'm stuck for subthemes, I may also do a little research on the Internet, at the library or watch a themed movie to broaden my idea base.

So for example, when I was developing the illuminati for The European Commonwealth, I first decided that I wanted a behind the scenes power broker. Subthemes of this idea were 'soft' power sources, such as finance and political wrangling, as well as the 'secret society' elements tied with the group's mythology (which I found after doing a good spot of reading on the actual group and watching The Skulls and The Contender). Further, I decided good class entry points would be the faceman, spin doctor and pointman, so I looked at how each of these agent types would change the way the illuminati class works in play - a faceman/illuminati would be the most shadowy type; the spin doctor/illuminati would be all about deception, twisting the truth and deflecting attention from his superiors; and the pointman/illuminati might be a financial wizard extrordinaire, an invisible man with the power to throw his weight around and make others do his bidding.

With subthemes in place, I start looking at the rest of the book to make the class really jive. I like to make classes that play with the rules presented in the book as well, so I read through the outline and see what, if anything, jumps out at me (You can see this theme with many of the prestige classes in the upcoming Faceman/Snoop Class Guide, which have many class abilities that interlock with specific rulesets scattered throughout the book, such as forensic investigation, profiling and psychology). Ultimately, this brings the entire book into play for the player and the GM, as they are using many different sections of the book to play their characters, and creates a richer gaming experience IMHO.

The next step is to learn about the line. It really is amazing how many prospective designers for Spycraft come in with classes that use Disable Device (turned into Mechanics in SC) or Animal Empathy (removed) in their skill lists. All that proves is that they have never seriously looked at the line they want to work on, and gets them a swift kick in the butt out the door. :) So I start out by reading the historical overview in the front of the book, all the classes (base and prestige), and the miscellaneous rules sections that might apply to the particular theme I'm working towards (in this case, rules on starships, trade, and so forth). I need to find out how these classes can mechanically work in the system and setting they are encompassed by. I find it's easier to get a broad theme for a class then work it back into the setting instead of looking at the setting and then making classes that fit it with jobs like this, but the door really swings both ways.

Now, with my reading done, my general and specific ideas in place and an idea of how it all ties into the game itself, I'm ready for the nitty gritty of designing the class - which is going to have to wait for another time :) Part II should contain some notes I make as I actually design a class and the decisions i make based on these broad ideas. More as it develops.

Developer's Digest
So, by popular request (well, popular for me, anyway), I want to start documenting a little of what I actually do in the game design process. I have a little downtime right now, but I have an assignment and 2 proposals I need to get ready for Gencon, so I think I'll use these as a starting point for how this whole crazy thing called game design works.

So you want to write a game...
This is question numero uno that everyone asks me - "How did you get in?" My answer (aside from that in my first post) is either 'luck,' 'hard friggin' work' or 'right place, right time.' Actually, it is all three, depending on my mood and what stage of a project I am in when you ask. Freelance game design is no picnic - it doesn't pay particularly well (compared to a day job, at least), it's almost always done during your "free time" (which is rarely free anyway) and is an arduous combination of creativity, attention to canon and brand, following an increasingly large set of rules and lots of algebra, all under pressure-cooker deadlines. Amazingly, however, it is still very rewarding, particularly the day you see your name on the cover of your first book and can say 'That's mine, dammit.' Just know it's only fun when you're not doing it ;)

What do you need to get in? It's the old catch-22 of any writing job - can't get experience without work, can't get work without experience. The best thing you can have is a published credit - and it doesn't necessarily mean in a game. If applying for fiction work, use stories published in a paper or journal; if going for a mechanical position, try something like technical writing or other creative presentation of facts. Personally, I found a system to latch onto (d20), then starting building a portfolio.

Meeting designers and other industry folk is also a big help - when someone knows you exist, and that you can do the work, you have a leg up over some shmoe off the street. Once you get your foot in the door, network your ass off. Build relationships with people, ask about work coming up and hand out cards and samples. Go to local cons, Gencon and maybe Origins or GAMA, if you've got the cash. Your work may speak for itself, but it's up to you to get it to publisher's hands.

Start small, too - you won't likely come in from the cold and get a book proposal picked up. The industry is so small and lives on such a shoestring budget, that they are pretty conservative about the risks they take. Try working on one of their lines, then once you have established yourself, throw out that new, fresh idea you have.

Build a niche. Like everything in life, specialization is a great way to get people's attention. Become a kickass designer or writer of a product, then show you can branch out. If you have a good reputation, your success in one line may be anticipated in another.

Lastly, don't expect to get rich. Don't quit your day job once you get a foot in the door, cause many companies are either unstable (living from book to book) or don't want to hire people full time. Having the right expectations will help you succeed.

Well, that's it for the sage advice this week. More as it develops.

Hey there!

Welcome to my stupid little spot in the massive nebula of blogs popping up on the web. I've built this dumb little place where I can share the fascinating details of life as a game designer (freelance of course) and talk about cool stuff I think of as I go. There probably won't be too much going on here, that this will remain on-topic most of the time, or that I will update it frequently, but I sure as hell will try (NDAs not withstanding).

Soooo...my name is Alex Flagg and I've been a professional (i.e. receiving a paycheck) freelance RPG designer for about 6 months, but I have been designing games in the hopes of being a professional for 4 years. I started off with a little fantasy project (which still hope will one day see print), then moved on to video game design for Strike Force, then wrote another RPG, which is in negotiations to see print in about 2005 (we'll see).

I started my most successful project about 2 years ago, a d20 game currently codenamed Project X, as a gift to a friend. After working on the game for about 8 months and making what I felt was good progress, I ran into an awesome little game called Spycraft which happened to have a good bit in common with Project X. I got to know Spycraft's mastermind, Patrick Kapera, through email and we both came to agree that Project X could be a significant contribution to the Spycraft line. As we were tying up negotiations on how exactly Project X would work at Gencon 2002, Patrick hired me to work on Spycraft, where I cut my teeth on professional game design.

Since officially joining the team 8 months ago, I have worked on 6 books, including The Fixer/Pointman Class Guide (Goodfella prestige class, Organized Crime department); Shadowforce Archer: European Commonwealth (first seat mechanics, including all classes save the Assassin, all non-fringe feats, rules for presence/celebrity, psionic powers, the Shadownet and the Prague chase map); The Faceman/Snoop Class Guide (with Clayton Oliver - prestige classes, investigation rules, lots of stuff on persuasion and interpersonal interaction to the tune of 40,000 words); Most Wanted from Paradigm Concepts, a book of villains and villainous options for Spycraft masterminds; Shadowforce Archer: African Alliance (prestige classes, foot chase rules, gambling, skills and psionic powers); and Stargate (foot chase rules that may not make the final cut :( and perhaps some NPC classes). I'm a busy boy, with lots more work in the pike, including some work on Dragonstar with my good friend Will Hindmarch (fellow journeyman designer and owner of The Gist Mill), more SFA and Spycraft stuff for AEG and Paradigm, and of course Project X (soon!).

*phew* So that's me. More as it develops.