One of the tough things about plants is there's just too much to model. So I've got to decide how to do some basic divisions, and which features will add the most without being a complete deal-breaker in terms of coding.
Here's how I'm considering modeling annual vegetable crops now:
There's an object called a row - each row can be planted independently, although I don't think I will implement half rows and quarter rows. I am considering two row lengths: short ones for the garden, where most of the vegetables will be grown, and long ones for the larger fields, where I expect players will grow grain. (Pasture grasses are going to be modeled relatively shallowly, and since very different concerns are at stake, that will all be handled by a pasture object.)
Each row will store values for its particular growing conditions: soil fertility, friability, pest levels, weed levels, etc. At intervals, probably every hour, the row will update the growing conditions for the plants growing there - whether there's been more water or more sun, if there's a frost. (I expect to do this with a relation (growing in), but I'm fuzzy on relations now, so I have to experiment. I'm hoping something like "Repeat with R going through all rows: if a crop plant is growing in the row, blahblahblah" will work.)
The advantage to this over handling each plant individually is processor speed; plus, unless the player is trying to breed plants, there's no real benefit to treating each plant separately. Why would it matter if Tomato A or Tomato B dies? (In contrast, there may be a genuine loss if Bessie the cow dies but Pete the bull lives, rather than vice versa.) A player experimenting with different conditions will need to plant two rows of a plant to compare effects, but that seems like a small penalty to pay. Plus, the row can "fake" death of part of a row if necessary.
I'm hoping to get it so the player can address commands to either the row or the plants, and that I can get the parser to choose the right rows as necessary. I'll be limited the number of rows per screen, but it'll definitely be easier in the fields if ">WEED CORN" means the player spends a few hours pulling weeds, rather than getting a disambiguation like "Which corn do you mean: the corn, the corn, the corn, the corn, the corn, the corn, or the corn?" Playing with the parser is yet another thing I don't really get, so it'll be an interesting experience all round. I suspect it will be difficult to implement basically two actions from one command (>WEED [PLANT] vs. >WEED ROW), but if nothing else, I can implement a meta-command, like >WEED GARDEN.
Naturally, this brings up issues if the field is very weedy and large - there has to be a way to stop the action in the middle if the player gets hungry or injured or whatever. My, isn't that going to be fun? Still, there's got to be a way to do it. If Nethack can do it, I bet I can. Still, I think I might leave that aside, as that's going to be tricky meta-behavior, and will need to vary from action to action. That is, it's not just "Instead of doing something when the player is hungry:" behavior - I think I may need to classify actions into crucial and non-crucial, with crucial being ones that shouldn't be interrupted (ie cooking, going home) and non-crucial interruptable (sleeping, weeding, fishing, etc.). I do think the game shouldn't prevent the player from doing non-crucial things if she wants; sometimes it might be vital to get a field harvested before a storm, say, and the game would have a tough time predicting all those occasions.
Design and documentation journal for my interactive fiction (text games); also reviews and other miscellaneous stuff.
Thursday, October 22, 2009
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment