At this blog, we are interested in practical simulationism: rules that get us close enough to reality while maintaining usability at the table.
Weather generation
is great for this because:
-We
have tons of weather data for many locations in the world
-It’s a
background system that any RPG could care about
-It
feels solvable—there is a best way to do it
The goal of this series is to see if we can come up with a general purpose rule to go from real-world weather data to a working weather table. My criteria are:
-It has
to be simulationist. That means it has to ‘match’ real world weather
data from a particular place. How close does the match have to be? We’ll learn
more about that as we go through this series.
-It has
to be algorithmic. There are tons of cool ideas at there for generating
weather in this or that environment. But they can be hard to use because the
descriptions are generic. E.g., “Fall weather”, or “Tundra weather table”. It’s
much easier as the GM to say: “this environment is like Egypt. Let me use an
Egyptian weather table”.
-It has
to be practical. There is a level of taste here. You can create
detailed, and probably more accurate, weather if you’ve got a dozen tables and
after four rolls you learn that you roll 2d6+2 on subtable C. But this is not
useable at the table. I prefer a strict boundary: no more than two rolls,
and no more than two tables. A d100 table is two rolls (2d10) and one
table—we aren’t going to go much beyond that.
---
So what options are out there for us? First, there are tons of variations on table-based methods. Here is a selection:
(1) Roll on a single table. This is the most popular. I like this version for 5e; here is their table for spring:
(2) Movement along a table. This is how the Wilderness Survival Guide does it: it sets a range of reasonable temperatures based on environment, then rolls a 2d6 each day to change. If there is a chance of precipitation, you roll on a separate precipitation table (again based on environment).
(3) Multiple tables with jumps. Here for example, you have two tables (basically ‘nice weather’ and ‘bad weather’). Each day you have a 75% to stay on the same table and a 25% chance to jump tables. This adds a bit of constancy.
(4) Independent tables for temperature, precipitation, etc. There is an in-depth version in Dragon #137, by Lisa Cabala, that perhaps gives the apotheosis of this approach. Here is Table 14, for Polar Temperatures.
(5) There are also souped-up versions of these which I’d call ‘computer-assisted’ tables. Here is a post corresponding to this spreadsheet. I’ll be honest, I don’t really follow it, but I see they have little dials like a “rain multiplier of 0.8” in early summer.
Beyond tables, there are there two other systems I’ve seen that are worth mentioning.
(6) Take a real place, pick a year/time that corresponds to your campaign, then pull weather from a database. I see some people recommend the wundergound database. The idea is, you pick a location corresponding to your desired weather, you pick a year, and then use the day-by-day weather. So maybe my campaign starts on September 7 of DR 1000 (or whatever fantasy system I want). I decide the weather is like Chicago. I pick 1955, arbitrarily. Then the weather on day 1 of my campaign is like September 7, 1955 in Chicago. And I progress day-by-day.
(7) Use a hexflower, a hextable with structure to it, where you will move from cell to cell based on a roll. Here is an example. If you go off grid then you loop around, unless you hit an X. These are aesthetically pleasing and have some memory effects to them.
So much for the survey. Where do these techniques land from the standpoint of practical simulation?
First, computer-aided methods are a no go. If you use a computer already maybe it is not that big an ask. But if you don’t, having to start bringing your computer to games, and possibly configuring internet access, just to get weather is not going to happen.
Second, we should be wary of tables that get too complicated. The Wilderness Survival Guide and Dragon #137 were both comprehensive because they considered a wide variety of possibilities (like ‘Arctic’ --> ‘Hills’ --> ‘Spring’). This is probably good from a simulationist perspective, but it means flipping pages at the table. (I’ve seen this complaint elsewhere).
Third, I’d like to quantify how well it matches real weather. This is my biggest source of hesitation with the tables I’ve seen—I can tell the authors have put a lot of thought into their tables, and making them realistic, but I haven’t seen any data in that regard. (Of course doing so would have been way more difficult in the 1980s).
The third point matters because real locations are how we’re going to orient ourselves with respect to the weather. I want to be able to tell the players “we’re in the Moonsea, so the climate is like Chicago”. That immediately grounds them. Many of the systems seem to use a more vibe based approach—we want there to be more predictability, so we added a mechanic for that.
It may turn out that simulationism clashes with gamism and using real weather tables means weather that is too constant or too unpredictable or too slow to change or whatever. That’s all well and good—but I’d like to see some proof of that first, which we can only get by comparing to historical data.
