A big portion of FTA is data entry. When I get lucky, the data has already been gathered in one place, and just needs to be copied into the appropriate tables (usually with some minor modifications). I've written before aboutsome of the easy bits; naming turned out to be pretty simple.
I am not finished with what I'm calling wildland communities - a small breakdown than biomes, but similar idea - partly because my main source does not have consistent information. For some communities, all the information I want is in the documentation, and it's just a matter of teasing it out. For others, the abstract is essentially a brief overview. This is, of course, totally fine; Michigan doesn't owe me the canopy cover numbers on every community. But it often means I have to make stuff up. (Canopy cover is a percentage of how much land in a community is under trees; grasslands tend to be 0%, but can have occasional trees scattered through them; forests can be as low as 60%.) It's also the short hand I'm using for determining how shaded a particular location is. This matters annually in the wild, when the game determines what is sprouting, and also on the farm, when crops under trees are penalized and animals checked for protection from wind/rain/sun.)
Once you've got a baseline, of course, making stuff up is easier - you just copy and paste from a similar place. But it takes a while, and sometimes no number seems quite right.
There's a lot of extrapolation required. If trees in a mesic prairie meadow can grow enough to turn it into an oak savannah, you need to know that if you cut the trees down, you may get the meadow again. There are probably ways of handling these interactions that don't require cross-referencing; for instance, if I had enough numbers and measurements properly handled, the game could decide the range of options for succession on its own. But that's very iffy, since the numbers available tend towards general. Acidity of the soil is a range; it's helpful, but not determinative. Since I don't trust an automated process to be either realistic or fair, a more brute force approach is required; and almost undoubtedly less work than trying to figure out spontaneous in-game generation. (If it was more work but would work smoothly, I might try it; as it is . . .)
So there's data entry and data creation, which gets boring pretty quick. I'm about done with the wetland communities, which will be lovely, but I've got all the dryland ones to go. Thankfully, I'm eliding a lot of those. Does one really need limestone cliffs, granite cliffs, and sandstone cliffs to be separate communities? (Answer: YES, if you're an ecologist or geologist.) I think maybe I'll use one or two or those, or decide that exposed rock in this world is always limestone. The only cliffs in the game are going to be ones that I put there, so it's not like the player is going to care.
Imputing dozens of communities feels like overkill at this stage, but I think the differentiation adds something to the game as it stands, and gives the basis for a lot of very interesting future options. Unfortunately, the future is not now, so a lot of the work is slogging. Not fun slogging, either. And I may have taken a few weeks off because I was just that tired of trawling through multiple sites hunting for random obscure bits of info.
And the trees are still half finished, as well, for pretty much the same reason; I think I was using five or six sources plus internet searches on each one, and that was beginning to grind. I've cut back on the amount of information I'm inputting, but I am still woefully short of the 200th species mark.
I have no doubt that I'll get smarter as I go; I also need to plan ahead more. But a lot of this is just work that has to get done, that I can't give to a peon. (Dear self: find peon.) I'm okay with that. Some days I don't mind doing data entry, and on the days which I can, I'll input another entry or two, just to keep the process moving forward, even if it's mostly symbolic.
Saturday, June 19, 2010
Wednesday, June 9, 2010
Game Concepts: The Midas Touch
I probably should not have jumped right into The Biggest Project I've Ever Programmed without doing more practice in I7 first. Inform is deceptive; it looks simple, but the rabbit hole goes all the way down, and there's some subtleties that are . . . interesting. Plus, the more you use a tool, the better you get at it. I once swore never to touch lists; I'm coming around. I haven't come around on procedural rules yet; I don't get rules on a fundamental basis, and don't feel comfortable messing with them.
I also go through cycles of interest in this project. This is normal for me. And while I'm invested in the outcome, unless someone else releases a complicated apocalyptic farming sim with all the features I want, this is really more about the journey - there's no deadline. I work on it when I want.
So I keep thinking, as I survey my coding bits, that it would be a Good Idea to finish and polish a smaller piece. It would be good practice, for one thing, and undoubtedly teach me a lot about myself, programming, and the bits that come after programming - beta testing, bug fixing, release, fame and accolades . . .
Unfortunately, I don't seem to really click with small projects. They don't capture my imagination. This sucks, since I'm well aware that even a "small" project can mean months of work.
The most workable idea I have at the moment would be a game based on the story of Midas and his golden touch. Midas could be a fun character, I think. I don't have a voice for him, but he's a greedy, impulsive man with a clear love of life. (You don't hang out with Bacchus if you're a stoic.) And he's in the midst of a massive comeuppance.
The other great thing is that if everything you touch turns to gold, the range of actions is automatically limited. You can't cut things with a gold sword. You can't hug people without killing them. You can't burn, or tie ropes, or kiss, or eat. You can look. You can talk. You can touch things (that then may or may not become useless.)
It does have potential to be sort of a humorless preachy game, or a predictable quest game, but it's sort of nice that there's a clear preset goal: get rid of the touch, so you can eat again. And rescue your daughter, if you go in for that version.
I think there are some interesting puzzles that could be done with a golden touch, although I'm not much of a puzzle person. But the key to an interesting game like this is probably strong writing and storyline.
At first draft, I'm thinking something like this:
- Story opens just after you get the power. Cue glee as you run around touching things. (I think most players know what's coming, but Midas's glee should be enough to carry the scene.)
- Midas touches his daughter, or she touches him, or something. Cue the realization that gold is not really the most awesome thing ever. Probably about this point the servants find out. I suspect their response is not "Yay, the king kills by touching people."
- Quest assignment. Midas prays, or Bacchus shows up, or both, or someone advises him to go to the oracle, or something. Midas has to go either to an oracle to find out how to get rid of the touch, or to a river to wash his hands.
- Midas sets out, having to pass through the city and countryside to the mountain to the oracle/source of river.
- As he passes through the land, he has adventures. Maybe he meets peasants, or bandits, or whatever; these are essentially chapterlets of interest. Puzzles are simple, and can be solved a variety of ways.
- Midas reaches his goal, and is allowed to choose his reward. There's a variety of things he can wish for, although the most obvious is to have his normal touch back. To finish the game, he must go back through the land to the castle; at this point we see the effects of his actions on the way out.
- Ending text differs depending on overall choices and opinion of the populace.
I also go through cycles of interest in this project. This is normal for me. And while I'm invested in the outcome, unless someone else releases a complicated apocalyptic farming sim with all the features I want, this is really more about the journey - there's no deadline. I work on it when I want.
So I keep thinking, as I survey my coding bits, that it would be a Good Idea to finish and polish a smaller piece. It would be good practice, for one thing, and undoubtedly teach me a lot about myself, programming, and the bits that come after programming - beta testing, bug fixing, release, fame and accolades . . .
Unfortunately, I don't seem to really click with small projects. They don't capture my imagination. This sucks, since I'm well aware that even a "small" project can mean months of work.
The most workable idea I have at the moment would be a game based on the story of Midas and his golden touch. Midas could be a fun character, I think. I don't have a voice for him, but he's a greedy, impulsive man with a clear love of life. (You don't hang out with Bacchus if you're a stoic.) And he's in the midst of a massive comeuppance.
The other great thing is that if everything you touch turns to gold, the range of actions is automatically limited. You can't cut things with a gold sword. You can't hug people without killing them. You can't burn, or tie ropes, or kiss, or eat. You can look. You can talk. You can touch things (that then may or may not become useless.)
It does have potential to be sort of a humorless preachy game, or a predictable quest game, but it's sort of nice that there's a clear preset goal: get rid of the touch, so you can eat again. And rescue your daughter, if you go in for that version.
I think there are some interesting puzzles that could be done with a golden touch, although I'm not much of a puzzle person. But the key to an interesting game like this is probably strong writing and storyline.
At first draft, I'm thinking something like this:
- Story opens just after you get the power. Cue glee as you run around touching things. (I think most players know what's coming, but Midas's glee should be enough to carry the scene.)
- Midas touches his daughter, or she touches him, or something. Cue the realization that gold is not really the most awesome thing ever. Probably about this point the servants find out. I suspect their response is not "Yay, the king kills by touching people."
- Quest assignment. Midas prays, or Bacchus shows up, or both, or someone advises him to go to the oracle, or something. Midas has to go either to an oracle to find out how to get rid of the touch, or to a river to wash his hands.
- Midas sets out, having to pass through the city and countryside to the mountain to the oracle/source of river.
- As he passes through the land, he has adventures. Maybe he meets peasants, or bandits, or whatever; these are essentially chapterlets of interest. Puzzles are simple, and can be solved a variety of ways.
- Midas reaches his goal, and is allowed to choose his reward. There's a variety of things he can wish for, although the most obvious is to have his normal touch back. To finish the game, he must go back through the land to the castle; at this point we see the effects of his actions on the way out.
- Ending text differs depending on overall choices and opinion of the populace.
Tuesday, June 8, 2010
Describing Color
I've always loved colors. Madly. The paint swatches, and their improbable names, always gave me great delight. Color has always been a part of my world-building "requirements", up there with materials.
Color is currently in-game by using shades, which are really just text snips that can complete the sentence "The sky is _____". So sometimes it's a recognizable color, like "blue," and sometimes it is descriptive, like "caramel colored". These are sorted, somewhat arbitrarily, into tables by color family. Here's the beige one.
Table of Beige Names
Color name
"almond colored"
"barley colored"
"beige"
"buff"
"champagne colored"
"dust colored"
"fawn colored"
"khaki"
"sand"
"tan"
"taupe"
"tawny"
"wheat colored"
This is actually surprisingly workable from a coding and text perspective. The game can pull the shade of something at any time, so generated description text can always discuss the turquoise sky or the steel gray storm. Since shades are grouped by family color, it's relatively easy for the game to randomly assign a new shade within the color family, so the clouds may be silver one afternoon, and iron gray the next.
There are some things that are sacrificed in this model, though. First, many colors are close enough to fit into more than one family, or at least different families depending on who is assigning them. Consider the color rose. Is it pink? Red? Both? What about fuchsia? What about magenta? Listing colors in more than one family can cause serious errors; because there's built in checks to determine what family a color is in, a double-listed color can "jump" the object from one family to another.
For example: So much depends on the red wheelbarrow, whose shade is "tuscan red". If "tuscan red" is listed as an entry in brown as well as red, the red wheelbarrow may well show up in lists of brown objects. (Well, not currently, but if I used definitions rather than decisions . . .) Game breaking? Probably not, but not the sort of thing I want floating around.
So borderline shades are a little arbitrary.
Another downside is that it's hard to determine intensity and hue. "Olive" and "viridian" are both green, but only one is an appropriate color for new maple leaves. One solution would be smaller families of color, and overlap them:
To decide if (S - an indexed text) is green:
repeat through the Table of Light Green Names:
if S is the Color Name entry, decide yes;
repeat through the Table of Medium Green Names:
if S is the Color Name entry, decide yes;
repeat through the Table of Dark Green Names:
if S is the Color Name entry, decide yes;
decide no.
This only creates more border cases, though. And then do you need Tables of Intense Light Green Names? This could quickly get unworkable.
I wonder how difficult it would be to set up a system with color values that included enough information to:
- do intensity work (intensify, deintensify)
- do graying (is this saturation? hue?)
- combine colors (if you mix red paint and white paint . . . )
- tell a html page the closest color, for display purposes*
This might indicate a need to change colors from text values to their own value (either named or numerical with a text string). I suppose I could use straight hex values, but I suspect that would cause me trouble. Better might be a xxx.xxx.xxx format using numerical values, or a list.
The downside would be that it would concretize what a color "actually" is. I may have a different idea of goldenrod than another player, but the game would only reflect my sensibilities. I generally think players can suck it up. Also, of course, in terms of actual gameplay, what does it add?
It would make it possible to mix and use dyes in a sensible way; actual dye color would depend not just on what the dye was, but how much was used and what it was mixed with and whether a mordant was used. That would be *cool*, but would it *add* anything?
It would make it possible to do neat things with weather and time: sky lightening and darkening throughout the day, growing grey with clouds and ominous for serious storms. That would provide a use for sky watching, especially if it was integrated into part of the UI. (I'm thinking a band across the top of the game screen with essential information; the background might indicate time and weather conditions, with player status and other essential stats in a contrasting color.
It would at least float the possibility of the player being able to choose their own color schemes for maps and such.
It would allow for realistic color aging and decay of colored objects from sun exposure, age, rust (?), etc. Which is nice, but how many people would notice? It would be intensely satisfying to know that somewhere in the world, a player forgot to wash her scarlet sweater separate from her ecru socks, and now she has faded pink socks. I'm not sure it would make the game better, but I would take pleasure in that.
On the other hand, color doesn't affect play as intimately as materials do, so I can shelf it until I feel motivated to do the research. There must be equations and stuff for combining colors. And since I go in cycles of design, programming, and research, I'll get there one day. No need to force it, though. What I've got is perfectly adequate for experimentation.
*This is currently sort of a pipe dream, since display programming is really NOT my strong suit. But having a display that could pull colors from the game would give intriguing possibilities for mood setting or information: Want to know the color of your sheep? Here it is, right on screen. (Maybe in a box of color, or maybe the shade of the text, or maybe as a filler of some froofy graphic.) I don't know how possible it is; it's certainly beyond my interests to program such a thing, but someone else might have done the work already. Or would do it.
Color is currently in-game by using shades, which are really just text snips that can complete the sentence "The sky is _____". So sometimes it's a recognizable color, like "blue," and sometimes it is descriptive, like "caramel colored". These are sorted, somewhat arbitrarily, into tables by color family. Here's the beige one.
Table of Beige Names
Color name
"almond colored"
"barley colored"
"beige"
"buff"
"champagne colored"
"dust colored"
"fawn colored"
"khaki"
"sand"
"tan"
"taupe"
"tawny"
"wheat colored"
This is actually surprisingly workable from a coding and text perspective. The game can pull the shade of something at any time, so generated description text can always discuss the turquoise sky or the steel gray storm. Since shades are grouped by family color, it's relatively easy for the game to randomly assign a new shade within the color family, so the clouds may be silver one afternoon, and iron gray the next.
There are some things that are sacrificed in this model, though. First, many colors are close enough to fit into more than one family, or at least different families depending on who is assigning them. Consider the color rose. Is it pink? Red? Both? What about fuchsia? What about magenta? Listing colors in more than one family can cause serious errors; because there's built in checks to determine what family a color is in, a double-listed color can "jump" the object from one family to another.
For example: So much depends on the red wheelbarrow, whose shade is "tuscan red". If "tuscan red" is listed as an entry in brown as well as red, the red wheelbarrow may well show up in lists of brown objects. (Well, not currently, but if I used definitions rather than decisions . . .) Game breaking? Probably not, but not the sort of thing I want floating around.
So borderline shades are a little arbitrary.
Another downside is that it's hard to determine intensity and hue. "Olive" and "viridian" are both green, but only one is an appropriate color for new maple leaves. One solution would be smaller families of color, and overlap them:
To decide if (S - an indexed text) is green:
repeat through the Table of Light Green Names:
if S is the Color Name entry, decide yes;
repeat through the Table of Medium Green Names:
if S is the Color Name entry, decide yes;
repeat through the Table of Dark Green Names:
if S is the Color Name entry, decide yes;
decide no.
This only creates more border cases, though. And then do you need Tables of Intense Light Green Names? This could quickly get unworkable.
I wonder how difficult it would be to set up a system with color values that included enough information to:
- do intensity work (intensify, deintensify)
- do graying (is this saturation? hue?)
- combine colors (if you mix red paint and white paint . . . )
- tell a html page the closest color, for display purposes*
This might indicate a need to change colors from text values to their own value (either named or numerical with a text string). I suppose I could use straight hex values, but I suspect that would cause me trouble. Better might be a xxx.xxx.xxx format using numerical values, or a list.
The downside would be that it would concretize what a color "actually" is. I may have a different idea of goldenrod than another player, but the game would only reflect my sensibilities. I generally think players can suck it up. Also, of course, in terms of actual gameplay, what does it add?
It would make it possible to mix and use dyes in a sensible way; actual dye color would depend not just on what the dye was, but how much was used and what it was mixed with and whether a mordant was used. That would be *cool*, but would it *add* anything?
It would make it possible to do neat things with weather and time: sky lightening and darkening throughout the day, growing grey with clouds and ominous for serious storms. That would provide a use for sky watching, especially if it was integrated into part of the UI. (I'm thinking a band across the top of the game screen with essential information; the background might indicate time and weather conditions, with player status and other essential stats in a contrasting color.
It would at least float the possibility of the player being able to choose their own color schemes for maps and such.
It would allow for realistic color aging and decay of colored objects from sun exposure, age, rust (?), etc. Which is nice, but how many people would notice? It would be intensely satisfying to know that somewhere in the world, a player forgot to wash her scarlet sweater separate from her ecru socks, and now she has faded pink socks. I'm not sure it would make the game better, but I would take pleasure in that.
On the other hand, color doesn't affect play as intimately as materials do, so I can shelf it until I feel motivated to do the research. There must be equations and stuff for combining colors. And since I go in cycles of design, programming, and research, I'll get there one day. No need to force it, though. What I've got is perfectly adequate for experimentation.
*This is currently sort of a pipe dream, since display programming is really NOT my strong suit. But having a display that could pull colors from the game would give intriguing possibilities for mood setting or information: Want to know the color of your sheep? Here it is, right on screen. (Maybe in a box of color, or maybe the shade of the text, or maybe as a filler of some froofy graphic.) I don't know how possible it is; it's certainly beyond my interests to program such a thing, but someone else might have done the work already. Or would do it.
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.
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.
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.
Tuesday, April 27, 2010
Forest for the trees
I am doing a lot of ecology reading right now, trying to figure out what happens when and why. Ecology is really complicated, and there's no nifty table that tells you what to program. Things are going to be a bit dodgy. (Awesome.)
My notes are an absolute MESS.
Here's what I've got:
- a list of native trees in Wisconsin.
- a list of native communities in Michigan.
- the sketchiest understanding of forest succession in the history of ecology.
Basically, a forest proceeds from grassland -> shrubland -> shade intolerant forest (aspen/pine) -> shade tolerant forest (usually maple mix in the fictional world of Minneconigan).
This is driven mostly by the relative shade tolerance/intolerance of the species involved.
But clearly, some sites do not progress beyond grassland. Or, rather, they progress to a mature prairie type grassland. Why? That's what no ecology text seems to want to tell me. I've been able to identify a few factors by looking around: rise and fall of the water tables can drown out trees. Beavers cut them down. Fire burns them. It looks like beavers were a much bigger presence I thought, both in actual tree removal and in creation of dams that created wetlands (or destroyed them, depending on whether the land was upstream or downstream of the dam).
So designing a model of progression is a bit iffy right now, because *everything* would proceed merrily to a maple-fir forest. Also, all shade tolerant species would grow in a mature forest, whereas usually it's a weird balance.
So I'm trying to tease out other factors that are decisive.
Other factors, arranged in what I'm hoping is descending order:
- soil moisture (saturated, wet, moist, dry, parched - I'm pretending this stays mostly constant right now, because I don't really understand how and when it changes)
- soil fertility (changes over time, but am pretending it doesn't, except on actively farmed land)
- soil depth (also changes over time)
- soil type (ie clay, loam, sand, loamy sand . . .)
It really tough, though, because many of the different types are pretty similar, except for a small difference, some not even easily codeable. So it's a case of trying to figure out how to manage all the data available, and make it realistic without being total overkill.
Fun fact of the day: As far as Catholic dietary rules are concerned, beavers are fish.
My notes are an absolute MESS.
Here's what I've got:
- a list of native trees in Wisconsin.
- a list of native communities in Michigan.
- the sketchiest understanding of forest succession in the history of ecology.
Basically, a forest proceeds from grassland -> shrubland -> shade intolerant forest (aspen/pine) -> shade tolerant forest (usually maple mix in the fictional world of Minneconigan).
This is driven mostly by the relative shade tolerance/intolerance of the species involved.
But clearly, some sites do not progress beyond grassland. Or, rather, they progress to a mature prairie type grassland. Why? That's what no ecology text seems to want to tell me. I've been able to identify a few factors by looking around: rise and fall of the water tables can drown out trees. Beavers cut them down. Fire burns them. It looks like beavers were a much bigger presence I thought, both in actual tree removal and in creation of dams that created wetlands (or destroyed them, depending on whether the land was upstream or downstream of the dam).
So designing a model of progression is a bit iffy right now, because *everything* would proceed merrily to a maple-fir forest. Also, all shade tolerant species would grow in a mature forest, whereas usually it's a weird balance.
So I'm trying to tease out other factors that are decisive.
Other factors, arranged in what I'm hoping is descending order:
- soil moisture (saturated, wet, moist, dry, parched - I'm pretending this stays mostly constant right now, because I don't really understand how and when it changes)
- soil fertility (changes over time, but am pretending it doesn't, except on actively farmed land)
- soil depth (also changes over time)
- soil type (ie clay, loam, sand, loamy sand . . .)
It really tough, though, because many of the different types are pretty similar, except for a small difference, some not even easily codeable. So it's a case of trying to figure out how to manage all the data available, and make it realistic without being total overkill.
Fun fact of the day: As far as Catholic dietary rules are concerned, beavers are fish.
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.
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.
Subscribe to:
Posts (Atom)
