Crafting in RPGs


Stick with me, folks, this is going to be meandering, but I’ll hopefully reach some kind of point by the end!

I think about crafting in games a lot. Part of that was designing a crafting system for an MMO that was seemingly well-loved by the small playerbase (which owed a lot to Brandes’ work on Fallen Earth and the crafting systems in Elder Scrolls and Star Wars Galaxies). Part of it is that I’m an avid hobbyist crafter myself (all available surfaces in my house are presently largely covered with miscellaneous resin and woodworking experiments as I try to get to the point I feel like I can make a resin river table without wasting hundreds of dollars of supplies). Part of it is that I just love to tinker on customization in games when I’m a player. This week, though, it’s because the Angry GM wrote a big article about crafting.

Angry’s system is a pretty big advance on the common, afterthought D&D crafting system. After all, it’s very similar to my system for Pathfinder Online, and likely draws inspiration from the same sources (such as Elder Scrolls). But even if it’s interesting, I’m not sure it feels like crafting.

Crafting systems (like those used in virtually every MMO) where you put one or more components into a recipe and get out a predefined item are basically just optional quests. If an NPC in town offered you a mission to collect five iron ingots and turn them in to him for a basic iron sword, that would have no difference other than fiction to “crafting” that same sword using a recipe that requires five iron ingots.

The last MMO crafting system I remember feeling like it wasn’t just a quest was in Star Wars Galaxies (which was why it was an inspiration for PFO). But that worked by virtue of having lots of extremely granular and important stats such that minor variations in materials and skill could produce items with meaningful differences in use. That’s a hard enough sell in a video game (where your programmers don’t want each item in the game to be a complicated special case record and the other designers don’t want to make an extremely complex system just so items can have a bunch of things to adjust) and it’s an even harder sell in tabletop (where you don’t have a computer to run all these complex calculations for you).

Angry is right that what a lot of players seem to want out of a crafting system is a way to customize their characters. I have some reservations about that, particularly in D&D, revolving around making found treasure seem less interesting because everyone just wants to have nothing but flavorless, specialized items. But I also don’t know that you need a crafting system to achieve it: players seem just as happy to turn over custom treasure coupons to the village blacksmith or guild quartermaster and get their items, independent of the fiction that they, themselves, are crafters.

In my personal experience, particularly as a hobbyist, crafting is never like putting in a few items and getting a standardized result. While to a certain extent it is probably like that if you make the same thing repeatedly as a profession, my experience with people on reality shows and skilled crafters in real life is that even full-time creators are interested in opportunities to make something special and unpredictable. When you’re working at the edge of your skill, it’s a long fight with your materials to get them to make what’s in your head: sometimes it’s not as good as you hoped, and sometimes happy accidents make it even cooler.

This means that, despite Angry’s reasoned points about it, some kind of randomness is probably essential to coming close to being “crafting” as opposed to quest (though Ars Magica makes a good argument that you can do something interesting as a between game system… by virtue of, like Star Wars Galaxies, having a lot of complexity). And I did a one-off crafting system in my Beyond the Wall game where a PC had one shot at making a cool magic weapon and made a lot of rolls, testing multiple traits, to find out just how cool, so I don’t think it’s a foregone conclusion that one PC making gear has to be boring and time-consuming at the table.

But randomness isn’t enough. The randomness, like most randomness in RPGs, is largely about capturing the variations in skill, circumstances, and focus that can’t be measured at the level of granularity most games sit at. When one of my resin projects doesn’t go the way I want, it’s not really random so much as my lack of complete understanding of the chemistry and problems with the environmental conditions (turns out there’s a reason serious resin-crafters invest in a vacuum chamber…). What really makes things feel like crafting is watching as raw materials become finished product one step at a time.

I… may have spent a lot of time this weekend making this and have boxes on the brain.

Let’s just look at a simple wooden box (of the kind that MMOs would say involves throwing a bunch of one raw material type together):

  • You have to measure out all the boards carefully, and cut them to size. Minor variations in measuring, starting board standardization, and tool precision can make things not line up, having you sanding furiously just to keep there from being obvious gaps when you’re done.
  • You have to fasten and/or glue everything together. Even if you cut the pieces exactly right, it can be challenging to get corners at exact angles and joints pushed closely together. There is a lot of clamping and waiting involved. And if you get glue that leaks into the inside of a corner, it can be really annoying to sand out later.
  • You have to sand down the whole thing and do any detailing you want to make it look interesting, and getting impatient can result in accidentally adding flaws that you then have to sand even harder to get out. If you’re going to add paint, stain, varnish, or other protective finish, you have to figure out how to apply it evenly and keep it from pooling up due to gravity.
  • You have to apply hinges and fasteners. At this point, any imperfections in the alignment of your pieces becomes really obvious when it’s hard to get the hinges to bend straight. And if you made a small box, trying to add fasteners can wind up splitting the wood and ruining everything at the last second.

And that’s one of the simplest things you can make. Once you’ve made a few, at each stage you start to get a sense of how it’s going. Early successes can lead to later despair as you make an error at the last second and ruin what was shaping up to be a really good piece. Early failures might be something you power through, something that causes you to adjust your final plan/expectations, or something that causes you to cut your losses and scrap the project entirely.

Does every crafting system in an RPG need to be multiple stages heavily informed by simulation? Not necessarily, but there is probably some juice in breaking it up into increments to increase anticipation. Each stage could carry over a modifier to the next stage based on how well it went, or grant a fraction of the final score that will be used to judge how good the final result is. Either way, it means multiple rolls, which is often a good way to bend dice luck towards the average (whereas one-roll systems make extreme results happen a lot of the time). It will vary from game system to game system and crafting type to crafting type how you capture the thrill of a stage turning out better than you hoped or the pain of deciding to make due with a mistake and continue forward. You might even save this for the really big projects (like how Fallen Earth had vehicle crafting happen in stages).

Ultimately, as Angry points out, if what your players want is a system to customize their gear loadout and you want something that’s not a distraction at the table, a recipe-based “quest” system is a fine solution. But if you want to capture the feel of actually doing crafting, I believe you have to capture the variability and sensation of chasing a masterpiece.

Only cooking and baking really use recipes anyway, and there’s a reason (other than not being able to taste it at home) why cooking shows spend hardly any time on “mixing together the recipe” and so much on all the parts that aren’t the recipe. There’s so much there there, when it comes to crafting, it seems a shame to relegate it to mixing A, B, and C to get an item off the gear list.

Designers and the Desirability of Dogfooding

1 Comment

For those not familiar with the term, “dogfooding” is the idea that when you produce a product you should “eat your own dogfood” and use the product you make. It appears to have originated in software development, and is a particularly common exhortation in the video game industry. Companies frequently ask their employees to play their games regularly, even when not on the clock, and a lot of companies with live games make significant play of that game a major factor in hiring decisions (some go so far as to tell applicants that don’t play the game to not even apply).

I had recently wondered whether this was only common in the world of core games: I asked friends whether they thought that developers of Barbie games, for example, were expected to dogfood. When you provide the universe with a question like that, it seeks to provide an answer, and within a week I’d met someone who had been a designer on a Barbie game. Yes, they were expected to dogfood. The entire team was exhorted to “be Barbie” in all of their design decisions.

The idea seems to be pretty obviously good, on the surface, particularly in the applications-development world in which it originated. If developers on Microsoft Word are secretly using WordPerfect at home, that says something pretty problematic about the utility of the software. But I’m not convinced it’s as universally laudable a goal in game development. Before I go into my reservations, I’ll list a few areas where it is a great idea, if used for a particular purpose:

  • Decision makers (producers, leads, and anyone else that can allocate development resources) should play the game at least casually, particularly during betas and major feature pushes. They should attempt to see the game as a player would, and also try out anything that’s suggested to them internally as worthy of their attention. They’re not necessarily playing the game to get ideas for things that should change, so much as to experience pain points that their employees have been trying to get resources to fix. Often, bugs and feature requests that seem low priority when you’re not playing the game escalate precipitously when you are. Playing the game can serve to align the expectations of players, designers, and decision makers.
  • Anyone at the company should play parts of the game relevant to a feature/content he or she is working on. When a task in on your plate, it’s often been flensed of context to make it easier to implement. But that context is still important in how the addition is going to be perceived in the game, and may control how you configure the feature for future expansion. For example, if you’re adding a new creature and thinking about whether to give it a bunch of knockback abilities, it might be important to know how common pits and cliffs are in the areas that creature will appear.
  • Everyone should obviously play their content to make sure it’s free of obvious bugs before turning it over to QA to look for the subtle ones.
  • When players are complaining about something, it’s worth trying to get as many internal eyes on it as possible to see for sure whether the players are right (or are just squeaky wheels; I’ll talk more about this in a later post).

But, all those in mind, I’m not so certain about the general idea of dogfooding, insofar as you should be playing your game all the time, even with no specific ends in mind. There are a few really obvious reasons, mostly related to how video games are not the same as software applications:

  • Games don’t have a clear competitor in most cases, and definitely don’t have a clear use case. It’s embarrassing if the MS Word developer prefers WordPerfect, and it’s strange if he does all of his writing in Wordpad, but, meanwhile, it’s less embarrassing if the Smite designer players a lot of League of Legends (he may prefer the setting/fiction) and not even all that odd if he doesn’t feel up to playing MOBAs in his spare time.
  • Games can require a lot of time, and are ostensibly entertainment. Particularly when someone is off the clock, it’s a little peculiar to expect them to relax by playing the game they’ve been working on for at least 40 hours a week (usually lots more). They probably do not ask the NCIS cast and crew to spend an additional dozen plus hours a week watching reruns of the show as their leisure activity. If you produced a product of a type that your employees were going to use anyway, you could expect dogfooding. But in the games industry it tends to feel a lot like assigning your employees lots of extra work for which they are not being paid. (If you expect them to play the game during a set number of hours in the week for which they are being paid, great! That’s actually a fine way to do dogfooding.)
  • Game developers are not typical users, and it can be dangerous for them to play the game pretending that they are. This last point is obviously my central one, and I’ll unpack it more for the rest of the article.

I know very few game developers that play games like a normal user, particularly on games they’re working on. Everyone that does the job for a living has some level of running commentary when playing a game about things they would have done differently, and this can be very difficult to turn off to just enjoy the game. Artists are constantly critiquing the game’s art, people who work on missions and story are always second guessing the unfolding of plots, those that work on systems are often offended by “choices” that are just exercises in finding the one correct option, and don’t even get me started on UI designers confronted with someone else’s UI.

And this is just the kind of thing that happens to you when you’ve been doing it as a job; just like people that work on films watch them much differently than normal viewers, the process of working on games changes your priorities and makes you hyperaware of the craft that went into the art. But on top of that, many developers are unusual even before adding in the years of behind-the-scenes knowledge. These are people that were so passionate about games that they decided to make them a career instead of the many more lucrative things they could be doing. They are very likely to have stronger opinions about things than a normal player.

There’s some good argument that you should make a game for one person, so at least you know that someone will find it fun (and hopefully more people like that person will also find it fun). But, importantly, that one person shouldn’t always (possibly ever) be you. If games were only made for game developers, there would be a lot of audiences (largely composed of the world’s less obsessive people) left without games. And when your company forces you to play your own game, ostensibly for fun, it provides a subtle pressure for you to figure out how to make the game fun for you (to preserve your own sanity), and you could easily lose sight of the fact that things you change to improve your own enjoyment might make it less entertaining for your actual audience.

But what about the companies with live games that only hire existing fans? Surely that solves the issue, since you’re getting an employee that is already part of your audience? Not necessarily. Remember, developers are obsessively passionate. Even if they love your game, they probably love it for a different reason than your average player. If their fannishness is manageable, expect some ramp up time where you have to explain to them why parts of the game they dislike and never use are worthy of development time. Worst case, they could quietly and unintentionally work to bend the game to favor the niche they were part of, reducing the fun for the majority of your players.

Ultimately, my worry about dogfooding in the game industry is that it sets up an expectation that you should only work on games you find fun, and you should work to make your game as fun as possible for you. But games, particularly large games, are targeted at an audience wider than yourself, and I feel like a fundamental skill as a developer is to be able to make things that aren’t for you, but you can still understand how to make them for someone else. I’d much rather work with someone that can make a good case for doing something based on metrics, comparison of multiple sources of user feedback, and established best practices than someone who plays the game regularly and is really passionate about his or her own experience.

There are lots of good reasons to play your own game. And if you’re lucky, it’s even a game that you, yourself, find fun to play. But there shouldn’t be shame if it isn’t, and narrowing down your staff as policy to those that love to play the game or can fake loving to play the game has a lot of potential pitfalls. As an art, you should absolutely make games you’re passionate about and love. But, as a profession, I object to the stigma that if you don’t love what you’re making you can’t work on it. Sometimes a game job is just a paycheck, but that doesn’t mean you won’t use your skills to make it the best game for someone else that you can.