Villanelle for Easter Eve

The athlete and missionary, Eric Liddell

For years, I sought to walk a godly pace,
Not sensing all things rushing into God.
But now I run, I run as in a race. 

There was a stream, but one I could not trace
While I was wading dust as thick as blood
And shouting that I walked a godly pace. 

There was a sun, but one I did not face,
Nor see the hills pursue it in a crowd.
I did not hear it panting in its race. 

But everyone who turns to seek His grace
Becomes a restless horse the faint breeze prods
And instigates beyond a godly pace. 

I could not be left lonely by the chase
Toward Him. The ground was moving in a flood,
And all things sang and hurtled in the race. 

And through that storm I saw how wide a space
I had to cross. I heard each slow step's thud.
For years, I sought to walk a godly pace,
But now I run, I run as in a race.

Villanelle of the Hidden Life by Sarah Ruden

Fantasy Weather: How to Create a Temperature Algorithm in Just 16 Easy Steps!

Or at least I'm going to tell you how I did it for THE ALMANAC of FANTASY WEATHER.

I'm not a computer programmer. The last (and only) programming language I learned was Fortran, as a college sophomore in 1982. (Yes, Fortran. Is it still around?) But I've always enjoyed working with numbers and logic puzzles. So, I've ended up spending a fair amount of time "programming" in Microsoft Excel. I'm not an expert, nor even close, but I've learned enough Excel to help me do what I want to do for both my real-world job and gaming projects.

I also knew almost nothing about weather or climate science (at least in any formal, courses-in-school way) before beginning the SEVEN YEARS of FANTASY WEATHER and THE ALMANAC of FANTASY WEATHER projects.

In a sense, this post is a companion post to my Editing Batten post of a few years ago. It tracks the progress of an amateur (or more accurately, quasi-ignoramus) in "learning" a new thing.

I don't want to sound falsely modest. I do think I am pretty good with numbers. But as far as I can tell, 80%+ of OSR people are pretty  good (or better than pretty good) with numbers. My impression is that many of you are IT or programming people. One of my favorite gaming blogs - Delta's D&D Hotspot - is written by a professional mathematician.

As with Batten, what's notable is not that I did it, but that I did it. Or to put it another way, If I did it, then you can probably do it, too. We're all nerds here.

Whether you would ever want to do it is, of course, another question...    

The problem: Given a particular real-world model - say, Jerusalem - create an algorithm for realistically simulating the temperature for 365 days or 730 twelve-hour day/night periods over the course of a typical year.

1. Find a data source. For temperature, I used Weatherbase and Weather Spark almost exclusively. Most online weather data sources feature both the Fahrenheit and Celsius temperature scales. I used Fahrenheit for all data entry and internal calculations, but presented the temperature using both scales on the actual weather charts. Here is some of the data from Weatherbase:

And here is some of the data from Weatherspark:

I should note that the overall weather data would often differ from source to source. The average number of days with precipitation was notoriously variable, for example,  presumably because the definition of "precipitation" differed from site to site (and many sites wouldn't explicitly tell you which definition they used). However, for temperature  this wasn't a huge problem.

2. Determine base temperature ranges and probabilities for each season or month. I began, following the suggestions in Lisa Cabala's 1988 Dragon magazine article, "Weathering the Storms," with three seasons - Winter, Summer and Spring/Fall - each broken down into four sets of ranges. Here is what I started with for a "South Temperate Coastal Hot" climate type, similar to that of Jerusalem:

But in redesigning SEVEN YEARS of FANTASY WEATHER to create THE ALMANAC of FANTASY WEATHER I made things more granular - in this case, going from seasons to months, and from four ranges to eight ranges - and made the data specific to the location I was trying to model:

The lows and highs were taken from Weatherbase, but the ranges within the percentile chances were taken from the Weatherspark charts for the middle day of each month, using the values at the time of day that contained the peak day temperature. "Eyeballing" the values for the shades was initially annoying, but after a while I got pretty fast at it. 

3. Smooth things out. As you can see, unsurprisingly, the ranges can shift up or down pretty dramatically from month to month. For example, they shift up about 8 points or so from April to May. Rather than have these shifts suddenly happen, so to speak, on the 1st of each month, I smoothed these transitions from "peak" - the middle of each month - to peak. You just take the difference between peaks and divide them by 30 or so to get the incremental change for each day. If you think about it, one problem with this method is that it might smooth things out too much - a peak is not necessarily the same as an average. I'll talk about how I addressed that problem in #16, below. Here are the smoothed numbers for the first five days of January for Jersusalem:

Why are the lows (0.0) here 10° higher than the lows under "Lowest Recorded Temperature" in the Weatherbase data? Because, these are the base day temperatures. The evening temperatures will be, for January, an average of 10° points lower.

Why is the first "1/1" cell red, and what is that "J" and "x" in the upper right-hand cells? Don't ask. My "programming" is filled with that sort of cryptic stuff. I often forget myself what some of it means myself. 

4. Determine how "sticky" the base temperature is. Generally temperature doesn't suddenly "re-set" every 12-hours. You might get a sudden major rise or drop, but on average you don't. Early on, I settled on a 90% "stickiness chance." That is, as you go from one 12-hour period to the next, there is a 90% chance that the base temperature will remain the same and a 10% chance it will re-set. This means that a particular base temperature phase will last an average of 5 days. Of course, even if the base temperature does re-set after, say, 5 days, this might not be noticeable - it might re-set to a value close to the previous one. So even in climes and seasons with quite wide potential temperature ranges, relatively consistent warm or cold spells might persist for some time.

Is 90%, or an average of 5 days, realistic? I have no idea - whatever "realistic" might even mean in the context of this sort of model. But it seemed about right.

5. Determine the relationship between day and evening temperatures. In virtually every climate, the day temperature is on average higher than the evening temperature, though, how much it might be higher, on average, will depend on climate and season. Weatherspark provides the average high (day) and low (eve) temperature averages for each day throughout the year. In Jerusalem, these high and lows differ by anywhere from 10° in the Winter to 18° in the Summer. In other words, if the afternoon temperature reaches, say, 90° F for a particular day in July, it will, on average, drop to a low of 72° F during the coldest part of the evening. This is, again, an average, however - the algorithm randomly determines a different actual variance each time. I settled on a variance (from the variance) of 20%. That is, the actual variance will be between 80% and 120% of the average variance. Thus, in July, the temperature might drop anywhere from 14° to 22° from day to evening. Of course, it won't always drop, since it's possible the temperature might re-set to a higher base during the transition from day to evening, an increase potentially higher than the average day/eve decrease. But this will be infrequent.

6. Add a completely random variance to the base. I went back and forth between 1° and 2°, and I think I settled on 1°. (Weirdly, 2° made things look too swingy to me.) That would mean a base of 80° F could yield an actual temperature with whopping variance of anywhere from 79° F to 81° F. Why go to the trouble of doing this since this would obviously have virtually no effect on play? Well, so the charts would look more "realistic," of course - like real weather as opposed to made-up weather, and thus trick the reader into thinking it was real. Here, as in many other places, "realism," for me, would actually mean "apparent realism."  

7. Add an additional quasi-random small "step" cycle to the base. In the real-world, you often notice small up or down temperature trends over the course of days. It's not quite a random-walk, in that once you've started to go up or down, there's a greater chance that you will continue than that you will stop or reverse. But a stop or reverse is always possible, and once you get to a peak of 3 or 4 above or below the trend line, you go back in the other direction. This adds further variance and "apparent realism" to an otherwise constant base.

Here is a (very rainy) first nine days of January. Can you tell which temperature changes happen around the same base and which are "re-sets"?

8. Add in the possibility of "exogenous" shocks. In the real world, sometimes particularly cold or hot years are completely random within the internal parameters of the system. But other times, some external factor - sunspots, ash from a volcano, etc. - will shift the whole system one way or another. In THE ALMANAC, every 50 days there's a chance for such a shock, which at the limit could move the ranges up or down by as much as 8° (though 8° would be very rare). Like the base temperature, these shocks have a 75% chance of sticking from one 50-day phase to the next. Also, as with base temperature, the shocks are often not shocks - the transitions are smoothed - though occasionally they are.

I thought it would be fun to indicate on the charts whether a particular month or year was unusually cold or hot. The player-characters or NPC inhabitants of the area would presumably know this, and it might prompt adventure or plot hooks perhaps involving higher level NPC's, monsters or even gods messing around with things.

Or it could just be sunspots. 

9. Optional: Create ceilings or floors for record highs and lows. This is sort of a question of taste, but in THE ALMANAC, once you get to within 3 or 4 points of a record high or low for the month (based on real-world weather data often going back many years), a mechanism kicks in that will randomly re-assign you to a point also within 3 or 4 points of that high or low but in a manner that makes actually hitting the high or low less likely than getting a few points from it. That's a confusing way of saying that if you have ceilings and floors, you don't want temperatures to "bunch up" at the identical extremes. This would look odd and "unrealistic" on the charts.     

10. Determine temperature minimums and maximums for precipitation events. This is a basic insight, and it's sort of obvious, but as with many otherwise obvious things, I was alerted to it by David Axler's Dragon article, "Weather in the World of Greyhawk". I initially cribbed the values from Axler, but would later modify some of them. The idea is that you always have a chance for precipitation event - determined by the climate type and month - but the range of which precipitation events you might get will depend on the temperature. 

Thus, it needs to be at least 30° F for Drizzle, 40° F for a Gale and 55° F for a Cyclone. It must be below 35° F for a Light Snowstorm and below 20° F for a Light Blizzard. For Light Fog, it has to be between 30° F and 70° F. For Freezing Rain or Sleet, it has to be between 25° F and 35° F. And so on:

11. Make sure that the temperature won't exceed the maximums or fall below the minimums during the precipitation event. Many precipitation events only last a few hours, and thus will only take up one 12-hour period, but some will last longer. You don't want to temperature to suddenly shoot up to 50° F during a blizzard.

12. Create a mechanism for possibly lowering the temperature if a particular precipitation event happens. This is different from 10, above. The idea is that temperature is the base engine that influences everything that happens - from precipitation to windspeed. If the temperature is 100° F, you can still get a rainstorm, but that rainstorm would then lower the temperature - at least while it was raining. I went around and around on this, and had a difficult time finding information for how this worked in the real world. But it just seemed sensible that rain would "cool things off," somewhat. Can it be 100° F during a rainstorm? 90° F? 85° F? I came up with some values but am still not sure whether they were "realistic".

Also, as with #10, above, you have to come up with a way to "fuzz" things, otherwise any lowered temperatures will bunch at the maximums and look dumb.    

13. Create the possibility of temperature shifts - warm fronts or cold fronts - caused by or associated with precipitation events. This is different from 12 - not a temporary shift in apparent temperature, but an actual change in the base. In THE ALMANAC, there's a 50% chance that "mild" precipitation events - Drizzle, Light Rainstorm, etc. - will cause the base temperature to shift up 1 to 3 steps, and "harsh" events - Thunderstorms, Blizzards - will cause the temperature to shift down by 1 to 3 steps. I think this is quasi-realistic, based on the information I could find.

Writing this into the algorithm was tricky for me as it potentially created circular references (utter doom in Excel) - temperature determining possible precipitation which in turn possibly determined temperature - but eventually I figured it out. To be honest, I don't remember how.

Here's a case where a Light Rainstorm rode in on a (minor) warm front:

14. Add in wind-chill. In the Introduction to SEVEN YEARS of FANTASY WEATHER: Indea, I argued against this, but then I changed my mind, perhaps due to suffering through another unpleasant Chicago Winter - a Winter (still not over) made much more unpleasant by the wind. But I thought it would be too fussy to put two temperatures - the actual one and the "feels like" wind-chill one - on the chart. Thus, my wind-chill measurement is hidden, but it does determine the "C" rating - C-1, C-2 and C-3 - for rating the effect of cold temperatures. The effects of wind-chill are particularly noticeable in the Southern Mountains:

15. Add humidity and a heat-index. The internal algorithm for THE ALMANAC of FANTASY WEATHER generates relative humidity for each 12-hour period, based on the climate type, temperature, season, cloud cover and precipitation status. But, as with wind-chill, I decided it would be too busy to list relative humidity on the charts, except in a general way on the yearly summaries. But the relative humidity does help to determine my own heat index, represented, as with cold, with three ratings - H+1, H+2 and H+3 - on the charts. Along with temperature and relative humidity, the rating also incorporates wind speed - which at very high temperatures may actually make things feel hotter - as well as sun intensity. Thus, cloud cover could go both ways - more clouds might mean more relative humidity, but they also might mean that direct sunlight is less intense.

16. Adjust the monthly weather ranges to approximate the desired averages. Because of the peaks vs. averages thing and the sometime bias caused by the warm and cold front adjustments, as well as other factors - some of which remained admittedly somewhat opaque to me - the average monthly temperature averages I ended up with for a particular climate template were sometimes "off" the real-world model averages (as listed on Weatherbase) by a number of degrees. (The average averages were taken from 80 simulated years. Don't worry - once you set things up, simulating up to eight years at a time takes about five  seconds.) Here, I suppose, was another place where it's unlikely anyone would have noticed or cared, but it still bugged me. To have gotten this far, so to speak, and then to end up with, say, February off by an average of 6° was annoying. Fortunately, the problem was easily fixed by simply adding a constant (a plus or minus value) to the original monthly temperature ranges.

There's something satisfying about designing a completely artificial simulation which nevertheless appears to get the averages, as well as the highs and lows, variance frequencies and so on, right or at least apparently right.

Maybe I need to get out more.

Here is the final product - January of Year 1 for "Jerusalem":

As I mentioned in the Introduction of THE ALMANAC, while Climate Template 101: Southern Temperate may have been modeled on Jerusalem, it ended up diverging from the model in a few significant aspects. Perhaps most obviously, I added a coastal cyclone season in the Fall.

Did those violent cyclones (or those gales caused by Storm Giants or the occasionally marauding cluster of possibly malign whirlwinds, etc.) kill all of the meticulously averaged averages previously mentioned? Actually, they didn't:

                   
See, for fantasy weather Year 1, the average temperature in Temperate South is 60° F, while Weatherbase tells us that the average temperature for Jerusalem is - oh, damn!

61° F.

It must have been one of those exogenous factors.    

"Weathering the Storms" (Dragon #137) and the Köppen Climate Classification System

The second major inspiration for what would later become THE ALMANAC of FANTASY WEATHER was Lisa Cabala's article "Weathering the Storms" in The Dragon #137.

The central insight of the article was to present twelve climate templates, templates that both tracked the different climate tyoes of our own world as well as (presumably) any half-way "realistic" fantasy world. The climate templates were these:

1. Desert
2. Tropical Savanna
3. Steppes
4. Equator
5. Warm and Rainy
6. Monsoon
7. Warm with Dry Summer
8. Warm with Dry Winter
9. Cool and Rainy
10. Cool with Dry Winter
11. Tundra
12. Polar

Each type was defined by its temperature ranges within the four standard seasons as well as the daily precipitation chances within those seasons. Those two variables and how they changed or varied (or didn't) from season to season constituted the basics of any climate type, and simply by presenting twelve of those types you could track the richness and diversity of all the earth's climates, or so it seemed.

For example, much of Western Europe was Warm and Rainy (5):

Unlike some other climate types, Warm and Rainy had a simple precipitation rate scheme. Daily chance of precipitation was a constant 40% throughout the year.

That's it.

I found this to be an improvement over what I saw as the more fiddly mechanism for determining temperature presented by David Axler in his "Weather in the World of Greyhawk" (The Dragon #68). There, the referee would, among other things, constantly be checking latitudes. Cabala's scheme also seemed more true to life. While latitude obviously affects temperature, in our own world wildly different climate types co-exist at identical latitudes. And in turn, very similar climate types appear at quite different latitudes.

So, the original design for my fantasy weather algorithm was to enter the climate data for the twelve climate types and then choose the appropriate one for each geographical location I wanted to model. If the average temperature for one or more seasons came out significantly different than that shown by the data for the location, I would simply make the appropriate adjustments.

However, in my quest for greater "realism," I soon became a bit dissatisfied with the list. As I found myself making more and more "adjustments" it became clear to me that the twelve templates offered worn't really enough. There were hot deserts and cold deserts, for example.

Somewhere along the line I discovered the Köppen Climate Classification System. In the late 19th century, the Russian-German climatologist Wladimir Köppen had also separated the world into different climate types. After the system was modified and refined by others, there were a resulting thirty climate types (or thirty-two, depending on how you counted them). Here were hot deserts and cold deserts (and hot semi-deserts and cold semi-deserts), among other things.

My inner weather nerd (yet another inner nerd this outer nerd never knew it had) became excited.

Again, one of the things that is fascinating about the climate types (if you're into this sort of thing) was how they didn't track latitude, at least as much as you would think. The world map above sort of gives you a sense of that, though it's more apparent if you focus on a smaller area. Such things as warm and cold ocean currents, wind patterns and so on are often much more important.

This is of course a commonplace for anyone with even a minimal knowledge of weather and climate, but it was useful and interesting to be reminded. 

I suspect Cabala had riffed off of Köppen but had wisely chosen to simplify it for her Dragon article. Thirty templates would have been too many for a scheme that required one to consult charts and roll dice. But if I were designing a relatively complex algorithm from scratch, starting with thirty sets of data wasn't that much more difficult than starting with twelve.

I would later make things even more granular to model different areas within each type - London versus Paris, for example - in order to make each location modeled truly "its own." And in the end, the classifications themselves would fall out as I settled on basing each of my own climate templates on the raw climate data for the particular location modeled, as opposed to its Köppen classification (which used the same sort of data but in a more general manner).

So, for example, I used Athens, Greece as a model for my internal Köppen template of Csa - Temperate, Dry and Hot Summer:   

But when creating my own Climate Template 101: Temperate South, which I roughly modeled on the climate of Jerusalem (also classified as Csa), I entered an entirely new set of data:

Would anyone have known that Temperate South, which I claimed to have roughly modeled on Jerusalem, was in fact really roughly modeled on Athens?

Yes. I would have. God would have.

Okay, even God probably wouldn't have cared, but still.

THE ALMANAC of FANTASY WEATHER: Volume 1, Swords & Sorcery was intended to simulate Middle-Eastern, Central Asian, Robert Howard-ish, Fritz Leiber-ish, "Swords & Sorcery"-ish sorts of climates. And, dammit, Athens didn't really fit. Entering the data for a second Csa climate type only took an extra hour or so.

And now, that one weather nerd out there who knows that it never would get down to -11 F in Jerusalem can't complain.   

But readers of THE ALMANAC of FANTASY WEATHER will notice that each of my own climate templates is also labeled with the Köppen type that it fits.

Tomorrow, the excitement level ramps up. Yes, I'm talking about temperature.

"Weather in the World of Greyhawk" from Dragon #68

As I might have mentioned before, the idea for designing what would eventually become THE ALMANAC of FANTASY WEATHER came to me when I was re-imagining druid spells for the Book of Spells supplement to SEVEN VOYAGES of ZYLARTHEN. Many of the spells were directly or indirectly linked with weather, which naturally brought up the question - how do you know what the weather is?

As far as I know, none of the original rulebooks for old-school D&D - OD&D, Holmes, B/X or AD&D offered a weather generation mechanism (I didn't go back and check this, so it's possible I'm wrong), which is sort of odd considering that some of the books, such as the DMG, went into such great detail on other things.

However, an article by David Axler, "Weather in the World of Greyhawk" in The Dragon #68, offered a detailed and robust system. As I understand it, that system had been or would be also incorporated into the Greyhawk boxed set. This was where I started.

Readers of FANTASY WEATHER may note that I took many of the same names for precipitation events from that article - Light Rainstorm, Heavy Rainstorm, Light Blizzard, Heavy Blizzard and so on. Since my original intention was not to design a commercial product, I didn't initially worry about copyright, but when I did start to think about that, the naming conventions seemed generic enough to be fair game, and I did notice that much of the same list was used in some of the other newer non-TSR weather products.

I soon altered the list however. Some of the names seemed too American or Western - Hurricane, Tropical Storm, Tornado, etc. - or too obviously culturally specific - Monsoon - for the tone I was trying to set. I didn't want FANTASY WEATHER to sound like the weather report from a North Carolina CBS affiliate, or an AP report from Bangalore. And I folded the article's "special weather" into the more general list. If you used the calculation scheme of the original article, a desert would only get a sandstorm once every eight years, or so I figured it. Where's the fun in that?

I used the article's durations, rainfall/snowfall amounts, wind speed ranges and the like for each precipitation event as a jumping off point, but soon started to fiddle with them for various reasons. For example, I soon discovered that while the rainfall amounts initially seemed realistic, if you did the math, the amount of yearly rainfall for pretty much anywhere in Greyhawk would be off virtually any terrestrial scale - often more rain (in inches or millimeters) than even the wettest place on earth. One of the first things I designed was a method to quickly alter rainfall and snowfall amounts to fit the data for the climate type being simulated. For example, if the weather results for a London-type climate yielded 400 inches of rain on average (roughly ten times the actual total) you could simply divide the rainfall for each event by ten. Of course, you could also just make precipitation events less likely (by a factor of ten) but that possibility wasn't attractive. London is pretty rainy. That doesn't mean you get a huge amount of annual rainfall, measured in inches or millimeters (it's less than New York), but it does mean that you have 150-200 at least slightly wet days per year. Reducing that to 15-20, which would have amounted to desert conditions, didn't seem right.

I realize that the last consideration is more for weather nerds or "realism" nerds. It's unlikely that many readers, referees or players would know or care that the sum of the daily rainfall totals wasn't "realistic." But I figured if I was going to do it, I might as well get it right.

"Weather in the World of Greyhawk" also gave me the idea for those funky rainbows (including that 1 in a 1000 chance of a Bifröst bridge), which I thought, if nothing else, added a fun flavor to things. So I left the idea intact, though I did twiddle the percentages. Later I would add in "supernatural causes", again, suggested by the article, although I substantially modified their chances and content. And I significantly changed how lightning worked. I wanted there to be at least a chance of it in most rain-event types, not just in thunderstorms. Again, this seemed to better match the real-world data, at least as I understood it.

And, of course, I found the article's mechanism for generating each day's weather with dice to be utterly impractical. It just took way too long. That's not the article's fault per se, of course, simply an unavoidable factor of real-world physical realty. That you could do it virtually through an algorithm coded into an Excel Spreadsheet, and then present it clearly in "almanac" form, was the whole idea behind FANTASY WEATHER.

That's the sum of it. I don't mean to sound critical of what in my view was the best treatment of weather and climate to ever appear in a TSR product. Along with a later article, which I'll talk about in the next post, it gave me the framework for how I would look at the problem of fantasy weather. The central insight of the article for me was framing the thing around "precipitation events" and their properties. But there's a lot more to the article than that that either I didn't talk about here or didn't find relevant for the FANTASY WEATHER project but that is still quite interesting and useful in its own right.

If you have The Dragon #68 in hard copy or have access to the PDF, I urge you to read or re-read it.

Tomorrow: "Weathering the Storms" and Köppen climate types.

THE ALMANAC of FANTASY WEATHER is now live on DriveThruRPG

Campion & Clitherow has just released THE ALMANAC of FANTASY WEATHER. It's available on DriveThruRPG and Lulu.

THE ALMANAC of FANTASY WEATHER is a new and greatly expanded edition of SEVEN YEARS of FANTASY WEATHER, published by Campion & Clitherow in 2017. The most obvious difference is that while SEVEN YEARS included seven years of weather for one geographical area or climate type, THE ALMANAC has eight years of weather for each of ten different climate types. Here you will find cyclone lashed coasts, burning deserts, steaming jungles, ice-covered wastes and more—enough (we hope) to provide realistic and interesting weather for an entire “Sword & Sorcery” world in the style of Burroughs, Howard or Leiber.

We have also made some other changes. Some of them are “internal” and, therefore, not immediately noticeable. I think the data sets and algorithm for SEVEN YEARS were pretty rich, but we couldn't resist tweaking them and expanding on them. We increased the number of data points and redesigned the internal format for how initial information for each climate type was represented, allowing for more diversity, complexity and pattern in the generated weather results. Thus, many precipitation events now come at the head of “real” warm and cold fronts, cloud cover varies by month and season, wind speed and precipitation often vary according to whether it is day or evening, “exogenous” factors may cause cold or warm spells for days, weeks or months, and so on.

The most noticeable external changes to the weather charts are a slightly expanded list of precipitation types, the addition of a wind-chill/heat index rating and the addition of a new category of weather events—those directly caused by “supernatural” forces.

THE ALMANAC clocks in at 1,130 extensively bookmarked virtual pages (960 pages of weather charts - 12 x 8 x 10 - plus 70 pages of text, climate summaries and spaces for notes). It sounds like a sort of monster, and in a way it is, but the bookmarks allow you to get around quickly to find or use (on your phone, tablet, computer or hard-copy print-out) only what you want or need at the moment.

Because of its size and diversity, I think it makes for a more useful product, giving the referee many more options to choose from and match with the specifics of his or her campaign. I should note, though, that the climate types and weather charts for MEDIEVAL ENGLAND, THE ICELAND OF THE SAGAS and INDEA remain unique, and have not been "rolled-in" to THE ALMANAC.

Previous purchasers of SEVEN YEARS may purchase THE ALMANAC at a discount ($12.95 - the list price of $19.95 less the $7.00 price of SEVEN YEARS).

An email has just gone out to most purchasers of SEVEN YEARS on DriveThruRPG. However some purchasers did not include contact information on the DriveThruRPG list. If you purchased SEVEN YEARS and do not receive an email in the next few hours, send me an email at zylarthen@gmail.com and I'll shoot you the discount code.

These tables (from the Introduction) detail some characteristics of the new climate types:

And here are two months of weather from "Climate Template 102: Southern Desert", roughly modeled on the Arabian Desert:

The desert has a higher proportion of relatively rare "supernatural" weather events. (They occur, on average, roughly twice a year in most other climates but roughly six times a year in the desert.) The "ef" next to whirlwind denotes that it was caused by an Efreeti. Why was there a sudden downpour? Because it was caused by a demon or demons ("dm"). Obviously, the player-characters may not know that an event had a direct supernatural cause, though there may be signs - the clouds form unusually quickly, they can dimly see an outline of a figure or figures in the sky, etc. As always, the referee is free to alter or mix and match things to suit the specifics of his or her campaign, and ideas for how to do this are included in the introductory notes.

I had a blast designing THE ALMANAC of FANTASY WEATHER. It brought out by inner weather nerd (which I never knew existed). And I'm very excited by how it turned out.

I hope you enjoy it!