Introduction to the Matrices

What These Matrices Are

I love RPG weather. Establishing daily weather makes the game feel immersive, like the world is living and would continue to live in the absence of players. In an overland hex crawl (my favorite style of campaign), it gives meaning to the seasons and forces difficult choices—given it is winter in the North, do we chance it and explore those ruins, or remain safe and risk being beaten to the punch? Such choices are myriad in both adventure literature and history: think of the Fellowship’s decision to turn back from Caradhras or Lawrence’s hard march to Aqaba.

But in practice, I find weather difficult to deal with at the table. There is a hard tradeoff between realism and practicality. More realistic systems are also more onerous, requiring several rolls across many tables and often with modifiers based on season. Faster systems need just one roll, but present two challenges. First, there may be no memory effects—today’s weather has no bearing on tomorrow’s—giving the players less to go on when making choices. Second, the generated weather does not correspond to a real place, making it both less intuitive and less immersive. Computer-aided methods, such as looking up historical weather in some location and iterating day by day, are useful but require a computer and some additional legwork. (They also mean the weather is fixed in advance rather than rolled, which is perfectly acceptable but not to my taste.)

The weather matrices here attempt to resolve these issues: they are based on real weather patterns, they require a single roll on a single table, and they have memory effects.

How did I construct these? To begin with, I determined weather patterns for real locations. A legion of scientists have assembled historical weather data (since 1940) into a dataset they denote “ERA5” which compiles (when available) and interpolates (when not) weather data across the globe. I took this data, and for each day, coded the daily weather according to temperature, precipitation, and cloud cover, and determined appropriate seasons. Within these seasons, I determined the probability of each type of weather (e.g., “rainy” or “partly cloudy”) transitioning into any other type of weather (or repeating). This process yields a ‘transition matrix’ showing how the weather evolves. Cleaning up these transition matrices allowed me to produce the weather tables, d100 tables for each season which encode that weather evolution into a game mechanic.

The resulting tables are a close match for historic weather patterns (e.g., matching daily probabilities with 1%) while being easy to use at the table (one roll on one table). This last point has been readily apparent during play. I will give the table to one of my players and have them roll day-by-day, and several of my players have remarked on how easy—even fun!—it has been to generate new weather.

I hope you find these tables useful and enjoyable in your gaming!

How to Use These Matrices

Each location comes with general instructions, giving you information about the seasons and how they develop, including daylight and precipitation levels. These are followed by the matrices for that location. For example, here is the Cairo summer matrix. Each entry gives both the temperature (in words) and the cloud cover/precipitation (as an image). See the definitions section.

To use the matrix, you begin by setting the starting weather. This can be done via the shaded column, which is the most common type of weather for that season. (The daily probabilities of each day within the season are stated in the row labels). Next, you determine tomorrow’s weather. To do so, roll d100, counting 00/0 as 100, and reference the current column. You transition to the weather in that row. Then the process repeats.

For example, suppose I begin my campaign in my fantasy city of Rhakote, which I decide has similar weather to Cairo. I select Cairo and decide we begin in summer. The first day of the campaign is hot and sunny, because this is the most common weather in Cairo: Summer. After the campaign’s first day, I roll to determine the weather on day 2, getting a 05 on d100. This lands in row B, which is warm and sunny; day 2 is therefore warm and sunny. The adventure continues, and when another day passes I now roll on column B (warm and sunny). This time, I roll a 49; this is also on row B, and the weather remains sunny on Day 3. This process continues as we progress through the season.

When changing seasons, there are two options. First, I can simply assert a new weather type when the season changes. For example, suppose I began my campaign in Spring on May 1. When my in-game calendar reaches May 15, no roll is made for the day; I declare the weather is hot and sunny, and we move from the Cairo: Spring Table to the Cairo: Summer table. Alternatively, I can define a ‘band’ of days where the season may change, such as May 10-May 20. Then, each day, I check to see if the weather I generate on the Cairo: Spring table is also on the Cairo: Summer table. In this case, the season changes and I move to the new table. If not, I remain on the Cairo: Spring table. For example, if on May 10 I roll on the Cairo: Spring table and obtain a result of warm and sunny, which is on the Cairo: Summer table, then summer has arrived and I jump to column B on the Cairo: Summer table. If I instead roll cool and sunny, which is not possible in Cairo: Summer, then I remain on the Cairo: Spring table. (It may be necessary to force a change in season, as in option 1, if no season change occurs after many days).

Definitions

There are a few weather dynamics not captured in the table which may be worth including. First, many locations have large daily temperature swings: for example, in Cairo, daily highs and lows vary by ≈20 °F. This can be seen from the “Temperature” panel on the cover page. In such cases, the referee may wish to increase/decrease the temperature by one band at midday or at night (not both). Second, the matrices do not account for wind or fog. This absence is regrettable, as their inclusion would make for great gaming! However, the data are comparatively poor and they are challenging to include without increasing the complexity of the weather system. I recommend the referee include these conditions based on reference to the daily results—for example, overcast, cool days in Istanbul can have early fog, while the day before heavy rain may have high winds. Third, certain locations have odd, rare weather not represented in the tables: for example, Cairo may develop sandstorms, especially in Winter and Spring. These are noted in the description for each location.

Finally, given the diversity of systems these rules are applicable to, I do not include specific recommendations for rules associated with weather effects.