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.
Monday, May 17, 2010
Wednesday, May 12, 2010
IF Reviews: What an Author Wants
There's been a lot of talk since the October comp about who reviews are FOR in the community, and how nice someone should be when writing. I basically think that transcripts and beta-testing are for the author, and reviews are for the players.
That is: in development, an author needs a clear vision of how she wants the game to go over, both objectively (bugs, hunt-the-verb, hunt-the-noun, communication of facts) and subjectively (difficulty, ease of understanding, pleasure of reading, communication of themes and story). I think transcripts are a tremendous boon to the former, and helpful to the latter. For the rest, the author needs to either communicate his needs to his beta testers, or suss it out from comments. You need a significant sample size to get a feel for whether players in general find the game difficult, whether they like the writing/setting/story, and what bits need fixing.
A review is a single report of what the player finds significant, which is almost guaranteed not to match up to what the author wants to know. I have no way of knowing what the author wants unless she put in an ABOUT command. Did she want it to be funny? Poignant? Nostalgic? Did she want the player to struggle with the puzzles, or breeze through? Did she want the player to notice the multitude of Shakespearean quotes and winks throughout?
Authors should be seeking out constructive criticism, rather than expecting it to come pretailored in reviews.
So that's where I draw the line. It feels presumptuous of me to review something with the intended audience of an author without being invited to do so personally, and without any idea of what he wants. It comes perilously close to "fix this game so I like it" territory. While often I have something specific to advise, sometimes it's just general distaste, or unease, or dull, exhausted rage.*
What I want from a review as an author is not entirely different from what I want as a player; this is especially true for "literary" works, where I'm interested in the reviewers interpretation of themes and characters, how smooth gameplay was, where the game fell short. Here's the crucial different, though:
As an author, I'm interested in the player's experience in and of itself. The goal is that person's enjoyment.
As a player, I'm interested in my own enjoyment, and in the ability to translate that review into the likely play experience I'd have.
I'm going to start playing and posting transcripts of randomly chosen games from the IFDB at frequent intervals. It's essentially an exercise for me, but also an opportunity for other writers. I wish more people put up their transcripts; I think understanding how people (lots of people) are playing IF is important for writing well.
*Mazes, people. Take them out.
That is: in development, an author needs a clear vision of how she wants the game to go over, both objectively (bugs, hunt-the-verb, hunt-the-noun, communication of facts) and subjectively (difficulty, ease of understanding, pleasure of reading, communication of themes and story). I think transcripts are a tremendous boon to the former, and helpful to the latter. For the rest, the author needs to either communicate his needs to his beta testers, or suss it out from comments. You need a significant sample size to get a feel for whether players in general find the game difficult, whether they like the writing/setting/story, and what bits need fixing.
A review is a single report of what the player finds significant, which is almost guaranteed not to match up to what the author wants to know. I have no way of knowing what the author wants unless she put in an ABOUT command. Did she want it to be funny? Poignant? Nostalgic? Did she want the player to struggle with the puzzles, or breeze through? Did she want the player to notice the multitude of Shakespearean quotes and winks throughout?
Authors should be seeking out constructive criticism, rather than expecting it to come pretailored in reviews.
So that's where I draw the line. It feels presumptuous of me to review something with the intended audience of an author without being invited to do so personally, and without any idea of what he wants. It comes perilously close to "fix this game so I like it" territory. While often I have something specific to advise, sometimes it's just general distaste, or unease, or dull, exhausted rage.*
What I want from a review as an author is not entirely different from what I want as a player; this is especially true for "literary" works, where I'm interested in the reviewers interpretation of themes and characters, how smooth gameplay was, where the game fell short. Here's the crucial different, though:
As an author, I'm interested in the player's experience in and of itself. The goal is that person's enjoyment.
As a player, I'm interested in my own enjoyment, and in the ability to translate that review into the likely play experience I'd have.
I'm going to start playing and posting transcripts of randomly chosen games from the IFDB at frequent intervals. It's essentially an exercise for me, but also an opportunity for other writers. I wish more people put up their transcripts; I think understanding how people (lots of people) are playing IF is important for writing well.
*Mazes, people. Take them out.
Subscribe to:
Posts (Atom)
