anyway.

*grin* It was only a matter of time. Cool, though.

That's awesome. I will be using that in a couple of weeks.

I've been thinking that a more useful tool would be a registry of towns. So not only would the application step you through the town generation process in a non-coercive way (I mean, letting you fill out the fields in whatever order you needed to) but it would database them and present them to everyone else for use. I'm still dreaming up how to organize things, but I might just give it a whirl as time permits.

Challenging ... or maybe less so than I think. I'll help if you want and I'm able.

The thing that I need to figure is how to organize the data. What kind of information is associated with a town, that is unique? What kind might have more than one entry?

Unique: name, description, what demons want, untended outcome

Duplicable: somethings wrong, NPCs, played outcomes/summaries

To some extent, the placement in those categories is subjective. I'm thinking that keeping the "somethings wrong" and the NPCs as individual entries in their own tables, associated with the town, is better than just having a text box where a description of all those things gets compiled. I'm not precisely sure why, but it seems better. You could treat "what demons want" in the same way (I'm noting that in the Boxelder Canyon example, there are two distinct things that the demons want), but it seems less valuable to give that kind of attention to that data since "the demons" are a collective force rather than individuals.

What am I missing? Is there a reason that things should be stored differently?

I'm imagining that ideally, people will use this tool to create, store, find, share towns and also share how their games worked out. If Player B uses Player A's town, pretty much as written up, then adding Player B's summary of the outcome would be valuable, or at least interesting.

Finally, I'm going to present a problem of town generation that I've been having because it's directly related to this project: I'm imagining a fairly small, fairly remote town in which a Mountain Person convert is using his native rituals to gain improved crop yields during a mild famine. So I'm starting from the point of False Doctrine or maybe even False Priesthood, but I'm having trouble reverse engineering back to the sin that allowed the demons to cause the famine. So, two things: should a town creation/DB tool allow the inputting of "somethings wrong" in any order or first take sin, then up the ladder? And, is there some obvious reverse engineering path that you (whomever) see? Is my problem unique to me, or does it turn out that starting up the ladder and filling in the lower rungs is just harder?

I haven't heard of anybody yet successfully starting high up the ladder and working down. I suspect that it's harder, but I don't imagine that it's impossible.

You can choose any old random unrelated sin, though, it doesn't have to touch your Mountain Person guy. Like say: Brother Theo shouldn't have had children, his heart isn't with his family, so he's been spending months at a time tending his traps out along the river. Finally now he's gone and he'll never come back. Meanwhile, his wife, tired of living on handouts and now that the baby's weaned, left her younger children in the care of her older, put on men's clothing(!) and hired on to a farm in the next town. Now the demons can cause famine (in either town or both) and your guy can do his thing.

If it were me building a database, I'd demand the progression in order, with an option to do it out of order you'd have to choose on purpose - but of course I would, that's how I did it in the book too.

Is this for CableDogs? Is this CHris Weeks from Ft Huachuca?