Basic rain stats

Finally did an extended test run with the weather extension, just to see how the numbers broke down.  I suspected the rain might be a little high. 

It was. 

Wissotagan gets a fair amount of moisture - there's precipitation of some kind on about 30% of days.  I couldn't find average hours of rain per se, but an average, moderate rain drops 5 mm/hour.  Making huge assumptions that all rain averages out to that point, the wettest months probably get about 20 hours of moderate rain, with a broader range of 4-100 hours, assuming very light or very heavy rainfall, or somewhere between 2-10% of the actual hours will be precipitation. 

And yes, I'm lumping snowfall in with rainfall in terms of hours expected.



I ran 10 simulations out of the box for around 10,000 turns.
There is a lot of variation in the clear and rainy hours, presumably because of the way they're calculated internally.  Weather is essentially a number between 1 and 10; lower numbers are clearer, and higher numbers rainier, and sunny/clear are edge cases, so get extra randomness.  That's not a problem in and of itself. 

The average clear hours are right in the middle of my low/high/ideal ballparks.  The partially cloudy hours are too low - about half where I'd expect them to be, and the cloudy hours are on the high side - just over my most generous range.
 
But the rain/snow hours are essentially double my most generous guess (all rain being extremely light). 


This makes sense in most cases that the extension would be used, where it's probably more valuable that weather changes and is visible to the player than it is to adhere to a somewhat arbitrary realism.  It's sort of an issue here, though.

The problem is two-fold:
- I'd like to be able to incorporate rain as an actual effect on parts of the simulation, and elevated numbers are going to bork the sim unless I do constant fixing.
- It's vaguely silly to have it raining constantly when you want the world to "feel" real.

These are only going to be exacerbated by any graphic display, emphasizing *just* how often it's rainy/cloudy.

So I added a semi-random tweak that kicks in when the values are high (cloudy/rainy) and makes it more likely to be sunny.  That helped, but also sent clear number soaring into the range of 50%+.  So I added a line that bumps up sunny values on occasion, and I'm getting about a 30/35/30/5 split between clear/partial/overcast/rain.  That falls into default ranges (a little high on cloudy days, still, but 35% is a dramatic improvement over 50%.  The rainfall quantities are still a little high if I use the default rain rates (about double), but I think I can tweak the rainfall rate so that they stay a little light (averaging out 2.5mm/hour rather than 5, which is borderline light/medium rain).  I suspect the easiest way to do that is to make rain start fairly lightly, which will pull down the overall average, but I can't remember how I did it originally.

Other updates

- Graphics continue to kick my ass.  Photoshop is being a gigantic pain, and sprites and layers are coming out of my ears.  I'm kind of overwhelmed there.  But I've got trees down pat - there's a couple maples, an oak, a cherry, a pine, and a willow done; I think a couple more foundation trees will give me really good range to do things.  The oak may need to be redone - there's a good approximation of oak leaves, but I'm not sure it matches the rest of the style.  The color needs to be tweaked on some of the layers, especially the spring ones, but that's be easier to see once I've got groups up.  (I think.)

- Took a crack at making a map that looked drawn by the PC.  I found the right brush settings to make it look charcoally, but not so much with the actual "this looks good" part. 

- Clarified some ideas on the advantages of maps, compasses, watches, and other physical/temporal location tools. 

- Removed some ideas that totally weren't working in terms of animal generation and placement.  (Basically, strict assignment of probabilities by region, with spawning calculations - the whole thing was wretchedly complicated, and added nothing to gameplay.  Also, it was manically bug-prone - the last straw was the spontaneous generation of rabbit burrows in every location in a 12-room block, despite careful coding designed to prevent such a thing.)

- Completed 3 more entries to the Encyclopedia of Doom.  (This sounds trivial, but every little bit helps.)

- Added 10 more things that need entries into the to-do list for Encyclopedia of Doom.  Have started combining entries to save sanity.

- Found a scanned copy of one of the early Sears Roebuck catalogs.  It is awesome - a good reference for prices, and comprehensive enough that it helps remind me of refinements, or clarify choices of use.  Honestly, I haven't added all that much *stuff* from it (YAY), but I have better ideas how to differentiate between certain tools, and a better idea of what sorts of things should be on sale, and some fun new terms to throw into patterns and descriptions.  American frontier needs are surprisingly similar to post-apocalypse survival needs.  One of the watches actually has a calendar and moon phase tracker, which amuses me to no end, because that would be actually useful in FTA. 

Community spreadsheet finished-ish

So I wrapped up the wildlife community data-collection yesterday (or at least Phase I).

The current table deals with quite a few specifics; there's a few things that will probably only be used as internal checks, but most have a direct impact. 49 "regular" communities that might be auto-genned or created through natural succession processes, plus a few different lakeshores, a couple cliffs, and a cave environment. Because of obvious game balance issues, those last categories do not auto-spawn.

These are not, of course, the descriptions or anything - just raw data to work with. But it was a boatload of work, and I feel very good having a first run-through.

These are the categories of data:

Fertility: A rough overall measure of soil fertility. I have no intention of tracking this for wild places, but it becomes important if the player wants to farm a particular location, or when determining succession. (I seemed to start by using high/moderate/low and switched to rich/moderate/poor later. Yeah, that'll have to be fixed.)

pH: Combined with moisture and fertility, these are the most predictive of plant types. pH is one of those things that will probably stay static. Right now, pH range is a list of two values, so: {65, 75}. The first is the lower range of pH in the community, the second the upper. If I wanted to, I could then categorize a particular room as acidic or neutral. I haven't done the coding yet, but it's straightforward enough.

Slope: From flat to cliff, in list form. Wetlands tend to be the flattest subset of communities, and things roll more in the drylands (and, of course, cliffs are cliffs.) Good for helping determine drainage, likelihood of flooding/drought, erosion for farmland, and nice immersion opportunities for wilds. I'm considering features like gullys and things, and stream placement.

Moisture: A tremendous determiner of plant-life and succession. Change the moisture level, and everything changes. Significant in farming, although wetlands would probably be drained, and moisture levels will depend more on precipitation and soil type than natural environment. These values range from saturated to dry.

Climax: Signals whether or not to check community for succession without an event. Every community gets checked when there's fire or something, but natural passage of time changes some communities (grassland -> savannah -> forest) but not others (a mature old-growth forest is an entity unto itself).

Soil Depth: I may take this out; it contributes to windthrow likelihood and erosion, but doesn't seem as important now as it did a few weeks ago. Still, I probably won't remove it until I know I won't use it. An uncomfortable number of the entries are sheer guesses.

Succession Possibilities: Given the natural passage of time, options for what a community may turn into. This is a brute force way of handling succession. It's not as complete as I'd like, since understanding the dynamics at work is challenging at best, and my data is very incomplete. Without disturbance, does a dry prairie turn into an oak barrens, or a pine barrens? Either? This list needs checking over.

Flood, fire, and beavers: These tend to knock succession "back" or change it significantly. Increased flooding may kill trees. Fire may kill fire-vulnerable trees, or all trees. Beavers can redirect streams, increasing or decreasing water flow. I'm well aware this category is mostly raw guesswork, but brute force manipulation is better than nothing, and keeps every room in the game from proceeding directly to forest and staying there.

Likely Nearby Types: What communities tend to be nearby. Some of this was helpfully provided by Michigan. Some of it was made up by me. (Michigan's lists tend to be shorter; I made mine by association.) I intend for this list to affect map generation, increasing the likelihood that a bog will be near a muskeg. This list is related to the succession possibilities and flood, fire and beavers lists, but tend to be a little longer.

Canopy Range: Hard numbers at last. Like pH, canopy range is a list with two numbers, bracketing the range. Canopy is a neat shorthand for tree density, size, and shading. Tree density is inadequate because some rather dense forests still let lots of light in; there may be tens of thousands of aspen per acre, but on the forest floor, you've still got dappled sunlight. Under an oak forest, with fewer trees, you get deeper shade because the canopy is closed. These tend to be guesses, but guesses based on examples. I have no doubt I'll need tweaking. The idea is that during generation, the number, age, and type of tree will create a canopy in the range given. When the shade in a location exceeds the canopy range, it might kick up to another community. For example, if enough oaks grow in an oak savannah, it may transition to a southern dry mesic forest (essentially an oak dominated forest). If no forest-y succession type is listed for a location, it will check and see if it can "match" current conditions with more canopied communities.

For example: A bog is essentially unforested: it has a canopy range of o-10%. Anything over that, and it will look at its succession possibilities column. Muskeg is the only option, but if nothing was listed, it would look for a community matching its current statistics, and become something new.

The difficulty of getting the coding right for the latter bit is what made me do the Succession Possibilities column in the first place. I plan to do it, but hope it will not ever need to be used. Things being what they are, there's probably multiple options that can create communities with statistics that fall outside the normal range. For example, our bog is now a muskeg. A bog has a pH range of 3.0-5.0 ({30, 50}), and a muskeg has a range of 3.2-4.3 ({32-43}). What if our original bog had a pH of 3.0?

My idea right now is to implement a sort of regression to the mean, where numeric values will gradually "pull" towards the mean value of a range. It's not actually cheating; biologic and chemical values do change over time, often showing this tendency to move away from extremes. But it's something I'm not going to implement for quite a while, because a better idea may occur to me.

Tree density: So, canopy is awesome. It is. But sometimes, a quick check is better. How many seedlings to try planting in a place per year? What's the likelihood there will be 10 young trees vs. 1 old tree in a prairie? Besides, canopy requires math. Kind of a lot of math. (Take sum of: each tree, look at its height and species, multiple density of species by height.) Tree density is quick.

Wind Risk: How much wind hits a place, and how likely is it to cause damage? Mostly windthrow, but may also play a role in events.

Flood Risk: How likely a place is to be flooded. Floods can trigger succession, wipe out crops, sweep away items, and in extreme cases, may be catastrophic.

Fire Risk: Chance of significant surface fire. Fires can trigger succession, but they can also maintain communities; dry prairie would quickly become something else if there were not regular fires. The risk ranges from low (as rare as once per 1,000 yrs.) to high (as often as every 10 yrs.) to regular (as low as 1:10).

Fire's deeply problematic from a play view: on one hand, having a wildfire sweep through and destroy the player's house, barn, crops, animals, etc. is kind of awesome and I approve. (Sort of. Maybe not the animals.) On the other hand, it's random destruction that is completely catastrophic, and sort of a break of trust. (And I'd be pissed if it were me playing.) Plus, fire is kind of like a rope: the permutations for how it should behave and what it can do are really, really troubling. I may have to do fires more or less locally: only in the location that spawned them, plus surrounding fire-vulnerable places. Or maybe I should drop the idea altogether.

Forest Types: So the foresters of America have a very long list of different groups of trees that tend to be found together. These are not communities in any sense of the word: they're both less specific, in that certain forest types are found all over the US in huge gloms, and more specific, in that they specific groves and smaller associations of species than communities tend to. Unfortunately, I haven't been able to find a good source for this data online, except scattered far and wide. So this column is there to remind me to hit the research library and see if I can get a reference book.

Dominant trees: What I hope will be the basis for forest types later. The trees most likely to be found in a location, usually comprising about 80% of the trees. This is for initial world generation, as well as future seeding purposes.

Minor trees: The other 20% of tree species. Usually there are more of these. For example, a prairie fen is dominated by tamarack, but occasionally you'll also find yellow birch, red maple, or American elm there. The minor trees are extra nice because there's a decent chance that two otherwise identical communities will actually have different minor trees, some quite rare. The opportunity for a player to find a grove of wild plums amongst a large deciduous forest is pretty neat. It also gives some trees true dominance: maples, oaks, spruce, balsam fir are all over the place, both as major and minor species.

--

I'm hoping all this info will help me do two things: create a world that feels unique and interesting and real, and then model changes to the world over time in a way that provokes curiosity and pleasure, but doesn't require too much head-scratching for the player - if she doesn't notice, that's okay, just as in the real world.

There's no way to do this to the extent I'd like to, but hopefully there's enough to give the world a solid veneer.

Food and measuring food

Looks like the time vs. time of day typo really was the big issue. The lesson of this story: never blame other people before checking over your own work very, very carefully. And don't leap to conclusions about what's broken - it's likely something very silly.

I can't quite wrap my head around how I want to do hunger yet. A lot of animals, especially grazing animals, seem to eat a lot. That is, they'll kind of hang out and nibble for a lot of hours. So they need regular access to food, and aren't going to eat the few pounds of hay/grass in one minute-long turn.

I'm tempted to say that the sheep will need access to adequately nutritious pasture for a certain number of hours a day, or they'll need a certain quantity of supplemental feed (probably in the barn). This gets a little dicey, since it requires looking at some hard numbers and deciding how I'm going to handle weights and measures and stuff. Since I don't quite have that crystallized, I'm going to work on some other stuff for now.

Before I handle harvest-type things, I need to set up a basic weights and measures system. I've got the most basic weight and volume set-up now, but it's not up to handling hay harvest, much less apple harvest. Part of the difficulty I'm having is that the measures are radically different across the world, plus there's some weird farm measures, like bushels.

I considered breaking this down to "meal-units" - the amount of food a person would reasonably eat in a sitting - but I think that's too vague and variable. Some of the factors I'm juggling:
Storage - Assuming the player will set aside space for storage of foods for both people and animals, what does that look like? What's a bushel of wheat vs. a sack of wheat flour vs. a "pile" of hay? (How big is a ton of hay, anyway?)
Quality - high quality hay has more nutritional value than low quality hay, and in real life, an animal fed high quality hay will eat less of it, and/or require less supplemental feeding
Carriable/describle quantities - I want the character to be able to visualize and handle the quantities of food we're talking about, without fine tuning. So not "You feed 2.5 grams of wheat to the chicken. She's thrilled!" but "You scatter a handful of grain for the flock." How much hay does a sheep eat a day? An armful? A flake? Half that? Would there even be hay flakes if there's no baler?
Different kinds of foods and equivalencies - does it matter if you give chickens cracked corn vs. wheat? What about sheep on turnips rather than alfalfa?
Calories - I'm not planning on handling detailed caloric intake for the animals - probably just quantity of certain foods - but I am considering it for people-food. Eating three solid meals of spinach a day is not the same as eating three solid meals of bread and cheese. Basically, this is an extension of food equivalencies.

A lot of these issues are solved for animals if I can figure out pasturization. On the other hand, I can't assume players won't try grain-only diets for the sheep, so there needs to be some back-up systems in place. I'm not really sure how to program the different factors, so I'm setting it aside for now while I turn over different possibilities. I think if I have a clear conception of where that piece needs to go, it won't be too ugly to slot it in a bit later.

Nomenclature finished!

Got all the names sort appropriately. There's a lot of very strange things people name children. There were a lot of gigglicious moments.

I have a couple concerns with the list I have:

- I may have inadvertently skewed the names towards European names, since those are the ones I encounter more and type more, and so find easier to type correctly.

- The list itself is inadvertently skewed towards Western names, given the time periods I used, and that the names weren't a random sampling - only the top 1,000, so names from small groups are bound to be left out. I don't remember seeing any Vietnamese or Thai names, and only a couple of Korean names. Japanese names have minimal representation.

- I left in a fair number of names I'd feel queasy about using for people. I mean, at some point, Commodore was a popular enough boy's name to make it on the list. I'm a little uncomfortable with the gender binary here. There were an amusing number of names that I'd tag feminine on the male names list, but since there can't be duplicates, I took them off. So there's no Rose, Marian, Ethel, or Edith in the male names list. On the other hand, I left a lot of the action names, job names, and war hero names on the male list. I may go back and change that. On the other hand, I kind of love the idea of having ram named Napoleon or Admiral.

I'm changing the instances to where the code picks names to use variables, rather than hard numbers, so it'll be easier to update the list numbers when I add/remove names.
(So instead of saying "Let R be a random number from 1 to 1000 . . ." I say "Let R be a random number from 1 to numberoffemalenames . . .")

It should clear up issues down the line. I hope. It's kind of hard to plan ahead, since I'm still figuring out Inform's little quirks. Stuff I think should work *awesomely* doesn't.