Crafting

When characters are not fighting one another, what are they doing? Socializing, exploring, and being pains, yes, but in gameplay terms what do they have to occupy them? Except in the elder game (which I’ll come to later), they’ll typically be creating something (for example, digging iron, making arrows) or providing a service (transporting iron, selling arrows). Because in most virtual worlds the service side is either trivial or automated, it’s normally lumped together with manufacturing under the general heading of crafting.

Much of this was covered earlier in the Chapter 4 section on economics, but there are a few more points that can be raised in the light of what has been discussed since.

Manufacture

Here’s how a simple real-world manufacturing process works:

• Raw materials are grown, dug from the ground, or captured. Examples: wheat, ore, cows.

• The raw materials are refined to get rid of the useless bits. Examples: grain, copper, milk.

• The refined materials are made into components or finished goods. Examples: bread, wire, cheese.

• Components are combined with other components to make new components or finished goods. Examples: sandwiches, circuit boards, pizzas.

• Finished goods are sold to consumers, who use them to destruction.

• Destroyed goods are recycled into refined materials.

In virtual worlds, it’s usually even simpler. Except for animals, raw materials typically emerge in refined form. Components don’t exist: Raw/refined materials are combined (using an abstract formula known as a recipe) to make finished goods. Recycling does not occur, except perhaps when encapsulated in some grand closed-economy scheme.

Needless to say, the excitement derived from crafting approaches 0% in intensity.

There are exceptions. The virtual world A Tale in the Desert ¹, which is set in ancient Egypt, has a full-blown crafting system at its core. Players can collect slate from riverbeds, that can be used to pay for tuition in stone blade fabrication; they can then make a stone blade from slate, which will pay for tuition in the carpentry skill; using wood obtained from trees, they can manufacture a wood plane and create boards; also using wood from trees, they can pay for the tuition necessary to make a brick rack; they can then make a brick rack; grass can be harvested and dried to make straw; they can obtain sand from the desert and mud from riverbeds; using their brick rack, they can finally manufacture bricks.

Needless to say, the excitement from crafting using this far more sophisticated system still approaches 0% in intensity. Fortunately, because it’s so tedious players will manufacture components that they sell to each other; this introduces an element of interaction that makes for some fun (at least it does if people will sell you what you need). There are some gameplay bugs to be ironed out, but designers have high hopes for A Tale in the Desert as a proof of concept if nothing else.

If a virtual world has a craft system of any substance, there are three golden rules to obey:

• All crafts should have gameplay value.

• The range of craftable objects should be great.

• The depth of crafting skills should be deep.

I’ve covered these elsewhere already, but I’ll quickly reprise the reasons for them here. Crafts should have gameplay value because this adds to immersion and interaction. This applies even to basically intangible objects such as “pretty” jewelry: Anything that impresses PCs should also impress NPCs, even if only crudely so by comparison.

The range of craftable objects should be great or people will end up making the same things and flooding the economy with more goods of one type than it needs.

The depth of craftable skills should be great or players will not consider crafting as a career. If crafting is something that adventurers do in their spare time, this is enough; if you want to cater to people who would rather create objects than destroy mobiles, however, they’ll need skill sets potentially as deep as adventurers’.

There may still be a problem when player expectations come up against virtual world economics. The “I’m role-playing a hero and I don’t see why I should be killed” adventurer has an equivalent in the “I’m role-playing a swordsmith and I don’t see why I shouldn’t sell my swords’” crafter. Sorry, guys, but no one is buying the identical swords that NPC swordsmiths are making, they’re not going to buy yours either unless you drop the price.

Recipes

My house is within five miles of four large supermarkets. The bread in the first one is too doughy; the bread in the second is too crusty; the bread in the third is too soft; the bread in the fourth is perfect (a shame the rest of the stuff they sell is so rubbish). Bread has been manufactured for thousands of years, but even today bakers use different recipes.

To make crafting more palatable to non-socializers, some virtual worlds have introduced explorative or competitive elements to it. One favored technique is to have multiple recipes for the same basic object (or, commonly, spell—this can be applied to more than just manufacture), some of which will endow the resulting creation with different properties than others. A recipe typically consists of a set of ingredients; these will often have to be explicitly arranged in some (usually linear) sequence, but in some implementations the “use recipe” action will do it implicitly.

This is one of those suggestions that sounds reasonable until you think about it. Unfortunately, it is frequently implemented without being thought about.

The idea is that players should be rewarded for experimentation. If you sit around mixing reagents and come up with a recipe for a steel that is more hard-wearing than regular steel without being any more brittle, you should be able to profit from your experiment. This is fair enough: If people discover through use that your swords are better than Joe NPC’s, they’ll come to you next time they need a new one. This is, of course, until some helpful soul puts a ton of sword recipes on their web site with a description of the precise effect of each one.

To counter this possibility, designers will usually try one of two approaches. The first of these is to allow characters to patent a recipe if they discover it first; subsequent use of this recipe by any other crafter will result in a royalty for the patent holder. This is fine for those who start playing the virtual world early, but it’s no use to those who come along six months later.

The second solution is to individualize recipes, so that the proportions of ingredients that you need to make the perfect sword are different to the ones that I need. This is unrealistic when applied to mundane object creation, but works for things like magical artifacts. Asheron’s Call allows for spell experimentation through different ordered combinations of “spell components,” and incorporated a random taper to make these unique to every character. These yielded easily to brute-force cracking methods, though. AC did have a back-up mechanism to discourage spell recipes from becoming commonly known, in that the more often a spell was used the weaker it grew. Mages who knew the recipe were thus disinclined to tell others what it was. Unfortunately, it only takes one recipe-holder to break ranks (for example, an explorer who doesn’t care if a spell loses its potency) and anyone who wants to find out can.

The root of the problem is that players don’t like having personal recipes. They want recipes to be global, so they don’t have to figure them out in advance. Designers may want to convince them otherwise, but it’s not going to happen. Like any other discovery in virtual worlds, once a recipe is unearthed it rapidly becomes common knowledge.

Ironically, although recipes are typically conceived to help crafters, it’s adventurers who are most likely to end up using them. There is some scope for using recipes in directly competitive situations—that is, as combat scripts. There, the efficacy of your recipe is directly dependent on the recipe your opponent is using. Co-operative recipes, where I do this while you do that, are also possible; however, they’re not going to make manufacture any more fun.

Beyond the Virtual World

So, I want to bake a loaf of bread. I get the ingredients, I mix them up, I stick them in the oven, then—I wait? What if I’m not baking bread but am manufacturing swords? I get the metal together, heat it, beat it, rapidly cool it, heat it, beat it, rapidly cool it, heat it—for how long? Do I actually have to do this? My character has the skills, not me—why should I have to be present while it happens?

The sheer monotony of repeatedly clicking on the same icon (or, for really advanced systems, the same three icons) for long, long periods has led designers to look at ways to alleviate the boredom. The most promising one opens up other possibilities, too: offline action.

Although many players may find this hard to believe, they cannot spend 24 hours a day playing in their virtual world. There are real-world demands that have to be met, most notably sleep. Some of the time, players are disconnected from their characters. What do the characters do during this offline period?

Well, the answer is that they can do the stuff that the player didn’t want them to do while being played. Thus, the character can sleep, eat, visit the bathroom, and so on. For reasons of safety ¹ and confusion ², they will usually not be visibly present in the virtual world while they do this (that is, they’re not temporarily NPCs); however, they are there in the abstract ³.

It seems obvious, therefore, that if players want their characters to do something mindlessly boring, this would be the time to do it. You set your character digging, you log off, go to school, come back half a day later, log back on and your character has deposited six truckloads of ore in your depot.

Virtual worlds always took some account of characters’ continued existence while their players are offline. MUD1, for example, would gradually heal characters’ wounds while no one was playing them. These weren’t actually offline activities, though; you didn’t really have a choice about what your character did while you weren’t there.

The first steps in that direction concerned trade. You hired an NPC to buy and sell stuff for you (usually the latter rather than the former) while you went away adventuring. The NPC remained in place when you finished your session, therefore when you next returned you might have found that someone had bought something from you or sold you the materials you wanted. There are some issues as to how price changes work in this situation, but in general it works well. Offline manufacture extends the same principle to the PC, rather than some NPC hireling, and simulates what the PC was doing rather than actually doing it (as it does with the NPC).

Skill learning fits this system well. Learning how to make a pot isn’t something that occurs the instant you hand over your training fee; to make sense, it ought to take time. By making it an offline occurrence, this passage of time can be suggested without drying the brains of the players. Furthermore, it makes them eager to come back next session to try out their new skills, and hey, it benefits adventurers, too!

There are other applications for offline action of which travel is perhaps the most interesting. Virtual worlds are large, but players don’t really get a feel for how large because of the (economy-wrecking) instant travel solutions that are available to them. No one wants to make players march their characters across a desert, but how can you convey a sense of remoteness if you let them press the magic button and materialize instantly? Well, offline action lets you do it. You set off walking, riding, flying, or whatever, then disconnect. When you reconnect the next day, there you are. If you were to reconnect prematurely, you would appear in the desert, your exact location interpolated from your starting position, destination, the elapsed time, and your mode of transport.

There are two ways to handle offline activities, whatever you use them for.

The first way is to give orders in advance. Just before you log off, you instruct the virtual world as to what your character will be doing while you’re away. Some of these tasks will take longer than others, but you can create a queue of orders so it doesn’t really matter. When you next log in, the character will have worked through some or all of the queue, and you can pick up from there. The advantages of this approach are that you can be informed (for example, by email or phone message) when a task is complete, and that you can set orders without using the virtual world’s client software (for example, via a standard web browser from work).

The second way is a more quantum mechanics approach. Your character accumulates activity time while you are offline, but you don’t have to decide how it’s spent until you log in and collapse the quantum wave. This means you can take into account events that have occurred while you were offline—for example, if gold has been discovered in them thar hills in the direction opposite to where you were intending to travel. This retroactive approach doesn’t allow for interrupts when actions are complete, but it’s handy for meeting up with friends who have wandered off since you last played.

There’s no reason why a virtual world couldn’t use both of these approaches, of course: When the action queue is empty, subsequent offline time is banked for when the player next logs in.

Offline actions aren’t a panacea for boring activities. In practice, there will usually be some limit to the amount of offline time that can be spent, if only to stop players from setting up programmed mules to act as craft factory cash cows. Some people object to it in principle, as it can break the bond between player and character (“How can I be in the virtual world and at work in the office at the same time?”). Nevertheless, this idea does have potential and the advantages seem to outweigh the disadvantages.