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.
Design and documentation journal for my interactive fiction (text games); also reviews and other miscellaneous stuff.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment