Weather in Alnwich

Work on overland travel times has created the need to know what the weather is like around Alnwich throughout the year. I’ve seen this handled a couple of ways throughout the years, ranging from GM fiat to intricate tables that nearly require a meteorology degree to parse. Today, I’ll examine these different options, settle on one, and then develop it to fruition.

GM Fiat

This method sees the GM arbitrarily decide what the weather is on a whim. He might have story reasons in mind, or he might just feel rainy. This has a few advantages: The GM doesn’t have to worry too much about prepping extensive weather tables ahead of time or rolling before each new day – possibly on intricate tables. Furthermore, the GM can tailor the weather to the dramatic needs of the story.

GM fiat can also lead to inconsistencies in the weather that make it unbelievable – e.g., it was 90°F yesterday, it’s 40°F today, and you’re not gaming in central Florida. This can break suspension of disbelief, but more importantly, it reduces player agency by denying players the tool of predictability to adequately prepare for what lies ahead. This latter issue is the breaking one for me.

Copy a Location

This method is used quite successfully by +Peter Dell’Orto over at Dungeon Fantastic. It lets him generate realistic weather on the fly in a predictable way without the need to resort to tables. In fact, I almost went this route until I realized there is a key difference between how I intend to conduct my game versus how he does his.

In Felltower, he takes the weather on game day in a real world location for the weather in that session. This is great if you plan on enforcing a one-to-one relationship between game times and real world times, but I can see issues arising over time if the players take more than a day on a delve. There are a couple of ways to address these issues, none of which are to my liking. You can have the weather unchanging during the session, make up the weather as you go, or consult historical almanacs. The first is kind of boring, the second has the same issues as GM Fiat because that’s what it is, and the third will require you to use that almanac for every session after the first consultation.

Make a Weather Table

The final option is to make my own weather tables so I can, in old-school form, roll on a table and randomly determine something I need in that moment. This requires a bit of work up front, since I have to make said tables from scratch, but this has precedent. Most recently, The Hall of Justice by +Douglas Cole provides weather tables for the Nordlands. This approach, if done well, has the benefit of providing predictability in weather by season, but still maintaining the kind of randomness inherent in nature. The downside is that it takes a fair amount of work to produce a reasonable set of tables, and possibly multiple rolls.

For my purposes, multiple rolls are not an issue, since I use a random number generator to create my table picks. With a computer, these can be as numerous and complex as necessary and still require a single click in game, but I would try to keep my tables simple so they could be easily used with dice.

Which One?

By now, you have probably guessed based on my verbiage that I like the table approach, but also like the idea of copying a location. Also, I’m a bit of a math nerd, so I am going to combine the two options into one!

For starters, I will pick a location that fits the feel I’m going for, in terms of weather. Glancing over climates of major cities for which climate data is readily available, Moscow seems to be the right amount of cold versus warm and rainy versus dry. This means there will be snow cover for about half the year and comfortable weather the other half. Moreover, there will be pretty consistent precipitation in various forms, with snow in the winter and rain in the summer. I was also able to find data on standing snow depth by month, so I can include overland travel penalties in this, as well.

Building a Weather Table

So I have lots of data that needs to turn into random tables. This may seem like a daunting task, but rolling multiple d6s as opposed to a d20 actually makes this kind of easy. First, let’s consider the means we need. These are taken straight from the climate data. January has a mean temperature of 20.3° F (I will ultimately drop decimals, so don’t worry!). That means that the average result for a roll in January should be 20.3° F.

But that’s not the entire story. We also need to consider the spread of results. Are temperatures closely clumped around 20.3 or are they spread evenly from -459.67° F to 500.27° F? Without diving into a lesson on statistics, I’m going to assert that temperatures, if taken over a long enough time period, will tend to clump up in normal distribution, which is math jargon for a bell curve with a high peak and thinner tails. More than that, we know that with a normal distribution, 99.7% of all data points will fall within three standard deviations of the mean! This is great news because now we can keep the temperatures clustered and control how clustered they are simply by selecting the type and number of dice rolled to get our result.

Using this website because I’m too lazy to work out the math myself, I find that rolls on 4d6 have a mean of 14 with a minimum and maximum values right about three standard deviations away. This means that if I roll 4d6 and add [Mean Temperature]-14 to the results, over time, this will produce the desired mean temperature with all results falling within 99.7% of that mean. Now I only need one number per month on my table – the amount to add to a 4d6 roll.

Next, let’s consider temperature extremes during the day. These are given in the data as the daily low and the daily high, and they happen to be the same distance from the mean daily temperature. So for each month, I only need to record that distance and I can generate the coldest and hottest it will get that day by adding or subtracting the low/high distance from the rolled mean – if it even matters in the game.

I’ve also mentioned that I have data on precipitation and snow coverage – both useful for determining travel conditions, visibility, etc. These numbers get a bit hairier when converted to percentages, so I’ll use 1d100 to determine these. Ok, ok, ok, I know that’s not very GURPSy; quit throwing things at me! It’s just more elegant and advantageous than using lots of d6s. In fact, to even approximate this otherwise, I would need to roll 1d, 1d, 1d and have one percent represented by two rows on a massive table that doesn’t need to be massive. It’s far easier to just roll 1d100 and be done with it, so nyeh.

Lastly, we will use 3d6 for the snow coverage and have the table output Light, Deep, or None for snow coverage. This actually works out pretty well with the data provided because most months with snow have a lot of snow on the ground. Based on average and maximum snow depths, I’ve set the deep winter months with near certainty of Deep snow, spring and summer months as having None, and autumnal months as having fair likelihood of Light with chances of both Deep and None. This suggests snow melts pretty suddenly in Alnwich, but it piles up relentlessly in fall.

This might seem like the last bit of information we need, but there’s one thing missing that might affect player choices and gameplay – hours of daylight. This isn’t so bad to handle, since it is very rigidly set by physics. The final row in our table will include the number of hours of daylight and night time for each month.

So what does this look like?

Alnwich Weather Table

	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
Temperature
4d6+	6	6	16	30	42	49	53	49	38	28	16	9
High/Low	5	5	6	8	10	9	9	8	8	5	4	4
Precipitation (1d100)
Snow	1	1	1	1	–	–	–	–	–	1	1	1
Mixed	59	58	36	4	1	–	–	–	1	11	34	59
Rain	75	72	55	21	4	1	1	1	4	24	61	82
None	78	76	65	54	43	48	46	46	54	63	81	88
Snow Coverage (3d6)
Deep	3	3	3	3	–	–	–	–	–	3	3	3
Light	15	15	13	4	–	–	–	–	–	4	5	10
None	–	–	17	8	3	3	3	3	3	7	11	15
Daylight Hours
Day	8	10	12	10	16	17	17	15	13	11	8	7
Night	16	14	12	14	8	7	7	9	11	13	16	17

Tying It All Together

This approach gives me a single table that provides a realistic weather – because it was based on weather in a real place – determined randomly with only three dice rolls. Sure, one of them doesn’t use d6s, but I’m okay with that for my own purposes. Those who want to only use d6s can certainly construct a similar table using 1d6, 1d6, 1d6 rolled individually, but that’s going to be a messy table. Also, if you use a random number generator, this becomes a trivial process.

What I like most about this is that it provides predictable typical weather. Naturally, unusual weather may occur, and I have another table for that, but these tables tell the players what to expect in the area. This lets them plan their travels accordingly without me, the GM, imposing anything on them. They decide if there is an “adventuring season” or not. They decide if they buy snow shoes or skiis or not. Are there optimal choices? Sure – after all, people don’t invent new modes of transportation because it makes travel harder –, but whether or not the players choose to use it is ultimately in their hands and not at the whim of an arbitrary GM.

What do you think? Did I hit all of the points? Is this too complicated? How do you handle weather in your games?