Biblyon the Great

In the medieval world, anything important requires planning. Even things we consider the most trivial of actions require making a plan, collecting resources, and using those resources to execute the plan.

Take building a fire. Matches are awesome things. It’s not a wonder that time-travel novelists wanting to get their protagonists in trouble with the locals give them matches. However, in the standard fantasy faux-medieval world—such as Gods & Monsters’ Highland—there are no matches. Matches were only developed during the seventeenth century and onward, and until the late nineteenth century were dangerous.¹

If you have magic, that’s almost as good. Anything that a match can light, fan of flame or eternal flame will have no problem lighting, and you won’t have to worry nearly as much about wind.

Without magic, however, how do you start a fire?

Starting a fire without magic consists of three simple steps:

1. Start with a fire.
2. Light a torch, candle, lantern, log, or other long-burning combustible using the fire.
3. Transport the torch to where you want to build a fire.
4. Light your fire.

Yes, the best way to build a fire barring magic or technology is to start with an existing fire. The need for an existing fire is almost as important a reason to have a torch or oil lamp as the need for light.

Starting a fire without a fire

Whether you have a spark or need to make a fire completely from scratch, the most important step to building a fire when you don’t already have a fire is finding something that will burn easily. You want the kind of thing that makes brush fires start spontaneously: very dry, very light, soft, filamented and frayed. You don’t want density, you want fluffiness. Thin strands of something very flammable. Leaves, if they’re very dry, will work well, but they’re rarely really dry. Straw is another good choice if you can get it. Dry grass, too. If you have dry rope, unravel it and unravel it again. If you need to something to carry, aged and thin wood shavings are probably the best combination of durable and flammable. Sawdust is awesome.

If you want to make it easier, make or get some “charcloth”. Start with something very thin and light, such as cotton or linen fiber. Then dry it even further under heat (put it into a pot over a fire, for example). Put this in with your kindling, and the charcloth will light as long as it catches a single spark.

Can someone explain Villains and Vigilantes falling damage? I can’t be reading it correctly.

Falling speed seems to make sense. It is calculated per turn rather than per second, which makes things easier to calculate at heights lower than 500 feet, but that’s a decent abstraction.

Damage, however, is wacky as described.

Background

For background, the average human has about 40 power points and 4 hit points. That means 8 points of damage will knock them unconscious¹ and 44 points of damage will kill them. A large bomb will knock the average person unconscious (21 points average, from 2d20) but not kill them. A small nuclear bomb will kill the average person (53 points average, from 5d20).

A large nuclear bomb will kill just about anybody, doing 20d20 points damage for an average of 210 points.

Given comic book physics this makes sense. Bombs throw heroes around, knock some of them unconscious, and leave a few conscious to survey the carnage.

Falling damage

Falling damage is in another league altogether. Damage taken is the distance fallen during the last turn (fifteen seconds), in “inches”, where a V&V inch is five feet, times the square root of the character’s basic hits². Falling off of a 500-foot building will mean 100 points damage times 2 (the square root of basic hits) for 200 points damage.

That’s a large nuclear explosion. But it gets worse: if you have size change to small and you’re down to a quarter inch, you multiply by your height factor of 288 for a total damage of 57,600 points.³ That can’t be right. What am I missing?

Falling from an airplane has crazier numbers. Depending on height fallen, the height number will be anywhere from a hundred (as in the above example) to a thousand (terminal velocity in Villains and Vigilantes). Two thousand points damage for falling ensures death, even if you’re lucky enough to share it with the ground. That’s five large nuclear bombs.⁴

A solution

The thing is, there is already a system in Villains and Vigilantes for damage from high-speed impacts. Brawling weapons do damage based on both weight and velocity. Assume that falling means maximum damage, and falling from 500 feet does 12 points damage, ensuring unconsciousness for the average person. Terminal velocity means 44 points damage, killing the average person.

Villains and Vigilantes uses real-world weights for determining damage when throwing non-weapons. Thrown rocks do damage according to how much they weigh and how fast they’re going.

I personally find it difficult to visualize how much a rock or slab of cement will weigh. What does a 6-inch diameter rock weigh? What about a two-foot diameter rock?

The way to determine the weight of something is to multiply its density by its volume. The more dense something is the more it weighs, and the bigger it is the more it weighs.

Densities are almost always given in grams per cubic centimeter, or g/cc. Grams and cubic centimeters are pretty small; your superhero isn’t likely to be tossing pebbles at the villains very often. Grams per cubic centimeter, if you choose to do the math, can be multiplied by 1,000 to get kilograms per cubic meter.

However, Villains and Vigilantes uses the English system of pounds and inches and feet. It will probably be easiest to convert this to pounds per cubic foot. Convert kilograms to pounds by multiplying by 2.2. Convert “per cubic meter” to “per cubic foot” by dividing by 3.28 cubed, or 35.3. Thus, multiply grams per cubic centimeter by 62 to get pounds per cubic foot.

Lots of rocks are relatively round. It’s easy to imagine the size of a rock by way of its diameter. The volume of a spherical object is four-thirds times Pi times the cube of the radius; radius is half of diameter.

In general, if you know a brawling weapon’s density in grams per cubic centimeter, and what its approximate diameter in inches would be if it were spherical, you can multiply the density of the material by the cube of the item’s diameter in inches, and divide by 53, to get its weight in pounds.

Which leads us to a table of diameters to weights:

Computers have a poor reputation for randomness, and with good reason. In the old days, randomness wasn’t taken seriously. In order to get a random number the system might poll some non-random aspect of the hardware. Those whose programmers understood some mathematics might use an algorithm, but they would reset the algorithm every time the computer started up, or, worse, every time a program started up, resulting in the same series of “random” numbers every time a program was run.

Nowadays you shouldn’t have to worry about that. The reason is security: modern security relies heavily on getting truly random numbers out of the computer’s random algorithms. This has resulted in a lot of research into computer-friendly random algorithms. Python’s random functions are able to leverage this research.¹ You should have no problem using your computer’s random number generators for gaming purposes nowadays.

The default random number generators in most programming languages are not cryptographically-appropriate random, however.² The reason for this is that computer programs are bound by predictability: programmers want predictability, even when they say they want randomness.

Imagine, for example, that you’re animating a film clip in a 3D renderer. You carefully place all of the major components of the scene, but you also have a flock of birds flying in the background. You outline the path that the flock will take, but after you render the video, the birds are far too uniform. They look more like a smooth amusement park ride than a flock of individual creatures. You might say they look like a railroaded adventure.

So you add some randomness to each individual bird’s flight path; each bird follows the basic flight path of the flock, but each moves left, right, up and down by some random amount each frame of the video. You don’t want to individually plot every single member of the flock, you just want them to act like birds. A little random variation is fine.³

But when you look at the film, you see that some of the birds are flying through a telephone pole. So you make some minor adjustments to the flight path and try again, and this time it’s great.

So you make your film and you send it off to the producers, and they say, awesome! Let’s make a high-definition version for the theaters. So you re-render the film… and the birds are moving in different directions this time, because it’s random! Every time you re-render the film, the birds move differently.

So now, what about doing more than one table at a time? Getting three dragons and one snake from the same command line? As soon as you start thinking about using a type of “thing” more than once with different properties, you’re talking about a class of item. Classes are used to take some pieces of code and variables, and put them all together to define that kind of thing. Once we do that, we can use them a lot like we have been using lists and randoms already.

So the first step is to separate the table code into a class:

If you run this from the command line now, it will do exactly what it did before. You should test it to make sure.

What’s new? The word “def” stands for “define function”. We’ve created a class and defined some functionality on it. The “__init__()” function is a special function that runs every time you create a new object from a class of something; in this case, every time we create a new table it will run—initialize itself using—that code. So we use that to load the file as a list of items and save it on the object (“self”) for later use.

Now that we’ve separated the table code into a class, however, we can make a more readable multiple-table command line.

“Bwian” commented on The Adventures of Heisenberg’s Cat:

The PCs are the centre of the universe! Yay!

I agree with this very strongly. The game can’t help being what the participants together make it. This includes the players—therefore their characters actions are key—as well as the GM—whose input is also key, in a different way. The whole enterprise works better if the GM responds to what the players have their characters do. But also in reverse—it helps if the players take account of what the GM just introduced when deciding what their characters do.

The other side of this is that if what the GM is trying to do is make the world seem ‘world like’ to the players, then using 1) ‘secret plans’ (or introducing pre-planned situations, if you prefer) can be helpful sometimes; and 2) as you so remarked, the situation when the players return to the city better be different than it was when they left. This tends to introduce a need for the GM to silently ‘keep track’ of what is ‘happening’ off-screen. That can be at a small scale (what are the orcs in the other rooms doing while the PCs batter down the door), or on a large scale (so what happened to that city, after the PCs left?).

As a GM I often end up with a lot of loose-ends dangling that require a lot of work (or brain-space) on my part to maintain consistency. Any ideas about how to make this less work to handle, while building/ unfolding a sand-box style environment?

First, I really don’t “silently keep track of what is happening off-screen” once the characters leave the area. What “the area” is will depend on what the adventure was, but if it’s not going to affect them, they’re out of the area. At that point, I don’t bother with what’s happening in that area. I tried to find a picture of Harold and the Purple Crayon for the article, because that’s pretty much the way I treat the game: it follows the player characters.

I really did mean it when I said “the plot doesn’t start until the players are involved” and “everything before that is just… potential backstory.” Of course I do keep notes when something occurs to me about a place they might go, or if something interesting occurs to me about a place they’ve already been. But that’s all they are until the player characters actually go there—scattered notes.

I also write a short summary after each session. If the players return to an area, I go back over these summaries and extrapolate what’s happened since. And if I need to introduce something new later, I’ll do a search for something similar in their previous adventures. This allows me to tie in any old incidents they’ve forgotten about with new incidents they’re meeting—i.e., potentially tie up loose threads.

This way, when they suddenly take an interest in the world tree, the adventure will include the druid they just met two adventures ago. Their current adventure didn’t originally include her, and she was just a throwaway character in the old adventure. But now they’re biting on the world tree myths they’ve been hearing? No problem, I’ll pull in the fatherless young druid they rescued earlier.

Don’t worry, I’ve got some more cool stuff with the random table management script for later. But sometimes you don’t want to have to set up even a simple table. You just want to make a quick choice. “Death or mercy?” asks the gladiator, and the emperor responds with?

As problems go, you can’t get much simpler than that. Here’s the code:

Save it as “choice”. Make it executable using “chmod u+x choice” just as in the previous installment. You now have a script that lets you make a quick choice between any arbitrary possibilities.

And a tip: the Unix command line uses spaces to separate arguments and options. If you want a single argument to include a space, surround the entire argument with quotes.

Ooh, that hurt.

As it currently stands, our script lets us easily get a random item from a “table” of items. But not as easily as it could let us do it.

The script looks for a “table” option and a “count” option, both of which are optional; leave the table out and it defaults to “suns.txt”. Options are very useful, but they’re probably not appropriate in this case. Once we have a hundred or so tables set up, how often, really, are we going to not have to specify a table? Why require typing --table and --count every time?

It would be a lot easier to be able to type:

Or even:

Let’s take it a step at a time.

Arguments, not options

If you look at the current version of the script, we have:

We’ve used the options—we used options.table and options.count—but we haven’t used args. Options are very precise. We say “--table” and specify a filename, “--count” and specify a number. Arguments are more freeform. Let’s switch this around to use arguments instead of options.

Now we don’t have any options (don’t worry, we’ll have one by the end of this series). The new syntax of the command is “python random number table”:

Dragons? Create a dragons.txt file with these lines: