Design and documentation journal for my interactive fiction (text games); also reviews and other miscellaneous stuff.

Showing posts with label wild. Show all posts
Showing posts with label wild. Show all posts

Tuesday, June 29, 2010

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.

Monday, May 17, 2010

Underbrush, grasses

I'm handling most species of tree individually - they are discrete objects, defined by tables, with their own stats. Some trees are officially classified as bushes, and vice versa. Since I'm pulling info from different databases, they don't all agree on whether alders are trees or bushes or both, so there's some clean-up to do.

I am currently trying to figure out modelling of shrubbery, grasses, and whatnot. As awesome as finding information on nearly 200 species of trees has been, I'm not eager to repeat the process with another 500-1000 species of plant life. For trees, I considered a bunch of options: a single forest object, that would hold different text properties pretending to be trees, a single forest object that related to a table holding a more complex tree recordkeeping, a grove object that would hold a variable number of trees of the same type . . .

In the end, individual tree modeling got the thumbs up. Part of this is programming skill - having individual objects is how Inform is intended to work, and doing a work around is a little sketchy, especially at this level. And if it went wrong, I have a feeling it would be impressively awful. Also, players are likely to be dealing with one tree at a time. Whether they're gathering food, cutting trees for firewood, or looking for lumber-sized trunks, they're focused on interaction with one tree. (To be sure, gathering food might include several trees in the same location, but we can't presume an orchard instead of an apple tree.) The only scenarios which it would be advantageous to have clumps of trees would be descriptions, and that I can work with. If I implement events like wildfire, there would be advantages to handling the trees together - we could look at intensity of the fire within groups more easily, but since not all species respond equally to fire pressure, there's also more finagling that needs to go on.

Also, trees mostly sit there and do nothing, and there's relatively few per location, with the exception of things like windbreaks, which I intend to make a separate object.

Shrubs and grasses are mostly useless. I should make grass cutable (for hay) at some point, but the main thing the player will be doing with the understory of wild locations is looking for herbs and food. Successful gathering seems most dependent on the season, rather than what's in the location. Gathering's usually not a matter of stopping off at neatly demarcated plants anyway - there's a lot of crawling and peering, so it makes sense to me that while the player would get a sense of what's around, she wouldn't be able to merely waltz in and out without effort expended.

I'm thinking of making an underbrush object that will give flavor to a location. I haven't quite figured out the details:
- Should I make one backdrop with differing descriptions purely on the type of biome and season? This makes it hard to track individual room issues - what if a fire burns down a meadow, but not the swamp? The underbrush for the meadow should change its description, but the swamp should stay accurate.
- One scenery per location: has advantages in that I can track what events happen in the room, and alter the scenery to suit.
- One scenery per biome type: nice in that many biomes share understory species. That is, the kinds of grass that grow in a bog are the same kind that grow in a muskeg. (A muskeg is essentially a bog with some tree cover.)
- Multiple scenery objects per room, correlated with biome. This would allow separate grass and shrubbery objects, which is nice for post-fire events that have wiped out shrub layers. It would also allow for community succession fairly easily - have two grassy layers indicating the transition from the old type to the new type. On the downside, this is complicated, and requires flawless programming on something I only sort of care about.

Usually when I write these things out, design choices jump at me - either what I want, or a new solution, or one option that's the clear winner in terms of gameplay. Nothing on this yet, which suggests I don't have quite the right idea yet.

The upside is that I can afford to wait a while longer, since understory components are essentially icing, not cake.

Tuesday, April 27, 2010

Square two

Past few months have been rough - I experienced a debilitating injury that's meant a lot of time recuperating, and a computer switch-over that somehow ended up discarding some of my experimental projects.
I am not exactly back to the drawing board, but I am not in the midst of a particular problem any longer, which makes it hard to dive back in.
A lot of stuff that seemed clever four months ago doesn't now. Instead of scrapping that, I'm putting it on hold, and looking at a different segment of the game altogther.
It's really worked well in terms of rejuvenating my interest, and it's a bit I'd formerly been bored to tears with, so I'm very pleased with myself.
I've been looking at the wild areas of the game, and thinking about it in terms of world gen and post-world gen changes.

Things that have become clear:
1) I'd originally planned to let the player select climate, soil types, and weather patterns - in short, to instruct the world how to model, so it could make a fair approximation of any US climate, and most non-US climates, barring Australia and Africa in favor of Central and South America. This is not going to work - not if I want the modeling to happen normally.

There's far too many biomes in even one climate to handle easily. For example, Michigan has a list of dozens of natural communities, broken down into half a dozen rough divisions. I feel like the choice is between a deep implementation of one climactic region, or a very shallow, unsatisfying implementation of a handful. Since there's not good information for all the areas I'd want to implement, that skyrockets the chance I'd mess up the ones I'm not familiar with, which would be worse.

So the game is taking place in Minnsiconigan, a mash-up of the contiguous states with the best information publicly available. The extension offices, forestry services, and departments of natural resources in Minnesota, Wisconsin, and Michigan are outstanding, and make the info pretty easily available for those with determination.

2) There's not a good way to represent a full-scale forest. Two problems: of primary concern is the ease of play, or at least the ease of understanding what's in a location and specifying what you want to do to it. So far, I've found this easy in a location with 1-5 trees, and doable but slightly more difficult with 6-10. After that, all bets are off.

I'm still trying to figure out how to let the player specify things like "the tallest oak", but I'm sure I can do it eventually. No, the problem is just clutter, especially if I want these places to be somewhat distinct.

Of course, no community is made up of ten trees, much less five. On the other hand, 100 rooms with 10 trees each is neither interesting nor helpful.

Potential solutions:
- model a "forest" object, or maybe a "stand" object, that fakes a number of trees. Downside - I like the idea of individual trees that I can track stuff for and create individual descriptions of. Also, stands and forests are going to be very very bug prone, and they need to work perfectly.
- pretend that a room is representative of a bigger community. Give the player more wood, etc. to represent the large number of aspens being cut down (or whatever). Downside - the *character* is supposed to be only one person, so giving extra wood or food is unbalancing and would be hard to explain in game.
- say fuck it, include enough rooms that the player probably won't run out of wood if she manages well, and just pretend pocket-sized communities exist all over the place. Downside: player may be weirded out to discover she turned a forest into a grassland by cutting down five trees.

I am leaning towards the last implementation. At least the player will have a clear effect on the environment, and with enough room, that should be okay. I hope.