Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Sowelu]

Sounds like some Markov chain stuff going on, the kind of thing that gets dangerous when it's been going on for a while.  If you only have ten years or so, saying "This town's imports are 20% from that town, which were 50% from the other town, and during this period that town produced 40 X and 50 Y, but later, that town produced them in higher quality because the legendary leatherworker moved in" is...hard, but do-able.

After a while though, the sheer number of things that move *around* is going to be hard.

[NW_Kohaku]

Sounds like some Markov chain stuff going on, the kind of thing that gets dangerous when it's been going on for a while.  If you only have ten years or so, saying "This town's imports are 20% from that town, which were 50% from the other town, and during this period that town produced 40 X and 50 Y, but later, that town produced them in higher quality because the legendary leatherworker moved in" is...hard, but do-able.

After a while though, the sheer number of things that move *around* is going to be hard.

You don't have to do it purely by "where it came from", you can simply do it by "what it is".  There doesn't need to be a difference between monkey leather generated locally, and monkey leather that was traded in, you just need to say that when a trade takes place, the local pool gets an uptick in the probability of all the things in the pool of the trade partner. 

[Sowelu]

It *totally* matters when and where decorations were made, though, and most goods that are tracked long term in worldgen can have decorations.  Hell, leather made from MBs can matter.

[NW_Kohaku]

It *totally* matters when and where decorations were made, though, and most goods that are tracked long term in worldgen can have decorations.  Hell, leather made from MBs can matter.

You can simply add that retroactively. 

So long as you know where it possibly could have come from, by simply tracing the trading patterns had taken place, you don't need to necessarily keep major data on what actually was traded. 

[King Mir]

Yes, you can retroactively model the relative price of tables and chairs through out history, but such a model would be complex enough that it wouldn't be an optimization. At best it would mean that either dwarf more or adventure mode would be slower at the expense of the other, and make world gen faster at the expense of both. I don't think that would be a good idea.

Either simulate supply and demand for tables and chairs separately, or fix their relative price throughout history and treat them as one good.

______

Equal value materials won't have separate S&D curves. But if you keep track of item type, and separately keep track of material, you haven't actually optimized anything. You'd have a list of items types, and for each item type a list of materials, which amounts to the same as having a single list of items, indexed by item type.

[NW_Kohaku]

Yes, you can retroactively model the relative price of tables and chairs through out history, but such a model would be complex enough that it wouldn't be an optimization. At best it would mean that either dwarf more or adventure mode would be slower at the expense of the other, and make world gen faster at the expense of both. I don't think that would be a good idea.

Either simulate supply and demand for tables and chairs separately, or fix their relative price throughout history and treat them as one good.

I'm not saying you determine prices retroactively, just what, specifically was traded. 

The real-time calculations would include watching for shortfalls, and a rather abstract form of price calculation (which would really only manifest as a trade imbalance), and the shifting of probability pools between trading towns. 

The exact amounts of each good, and the exact conditions and qualities of each good are the retroactively determined things. 

I don't think you really even need "historical prices".  I doubt anyone cares what the price of milk was 300 years ago outside of extreme historical reenactors.  All that really matters is what it is when the player walks into the market, and what it will be in the future, if they choose to speculate.  (Probably not on milk futures, though...)

Equal value materials won't have separate S&D curves. But if you keep track of item type, and separately keep track of material, you haven't actually optimized anything. You'd have a list of items types, and for each item type a list of materials, which amounts to the same as having a single list of items, indexed by item type.

Actually, yes you have, with even that much. 

If there are 50 material types, and 50 types of tools, you are tracking 100 values compared to 250.  Even with the weakest possible optimization, you've already more than halved the amount of data you are updating.

Besides, you can easily abstract things much more completely than merely trading totals of specific types of materials.  You can simply have a total "stone" supply, and have an index of a specific weighted chance of each stone type that any given stone might be.  You don't have to update specific stone type weighted chances except when you have new trade access, so you're reducing this from 20 types of stone that get checked every year to just one vague stone type that gets checked.

Beyond that, like I said with the car, you don't have to actually iterate this value for every single year.  As long as the actual conditions don't change, you can simply track a vague rate of surplus for the year, and assume a constant rate of trade that lets you skip over even performing an adjustment of the goods available.  You only need to stop and adjust for the years where something changes, such as when there are sudden labor shortages or trade routes collapse. 

Again, you don't even have to be exact - a player isn't going to recognize that there should be only a 4% chance of a monkey leather item, when the weighted averages, by simply using loose accounting with the weighting, results in a 5% chance.  How are they ever going to figure it out? 

It makes no more sense than complaining that the inside walls of a tower are only randomly generated when they walk within a certain range to complain about how imported monkey leather seems 25% too common. 

[Sowelu]

Honestly, I think that as the caravan arc proceeds, it will be important to know "the price of milk 300 years ago".  Because worldgen can be stopped at any time, and thus you want worldgen at all times to be able to translate into a stable post-gen state.

If an abstracted worldgen says "This city is a major leather producer", but once things start being traded in-game it becomes clear that it's actually short on the material, that's going to be a problem.

[NW_Kohaku]

Honestly, I think that as the caravan arc proceeds, it will be important to know "the price of milk 300 years ago".  Because worldgen can be stopped at any time, and thus you want worldgen at all times to be able to translate into a stable post-gen state.

If an abstracted worldgen says "This city is a major leather producer", but once things start being traded in-game it becomes clear that it's actually short on the material, that's going to be a problem.

If you stop worldgen, then the game will simply generate all these things at the time of stopping, in exactly the same way that it would have if left to generate to the "proper" stopping point, in exactly the same way that worldgen works now - worldgen itself takes up a gig or more of RAM, and is put in a save consisting of about 10-50 megs in hard disk space because of all the work that is put on the finished worldgen save to prepare it for play.  The process isn't any different when you stop it mid-way.

If the city wasn't producing leather, then it wouldn't have been considered a leather-producing city to begin with.  The game doesn't backfill that it had leather, the game only backfills what kinds of leather it had.

None of these things you list as problems are problems at all.

[Kento]

The economy in worldgen is never going to directly mirror the economy during actual gameplay, you would have to simulate how long it takes elves and humans and dwarves to path from stockpiles to their workshops and back in their different cities, and all sorts of other details. It would be very, very, very cool to have a highly detailed economy in worldgen, it might allow for additions like mercantile empires or middlemen economies that might not be possible to add in every implementation of abstraction we can think of, but we have to acknowledge that we face technological limits. Worldgen has to be abstract on some level, and NW_Kohaku is right in saying we're too far on the concrete, detailed simulation side of the scale right now.

Remember the actual core of the game is when the game actually starts. We want to get to the point where there are caravans and armies moving while we play, and where we can switch between multiple adventurers and fortresses, building the world. It seems like we might not be able to reach that point if we can't even gen a world because we want the worldgen stage to be incredibly detailed.

[King Mir]

Yes, you can retroactively model the relative price of tables and chairs through out history, but such a model would be complex enough that it wouldn't be an optimization. At best it would mean that either dwarf more or adventure mode would be slower at the expense of the other, and make world gen faster at the expense of both. I don't think that would be a good idea.

Either simulate supply and demand for tables and chairs separately, or fix their relative price throughout history and treat them as one good.

I'm not saying you determine prices retroactively, just what, specifically was traded. 

The real-time calculations would include watching for shortfalls, and a rather abstract form of price calculation (which would really only manifest as a trade imbalance), and the shifting of probability pools between trading towns. 

The exact amounts of each good, and the exact conditions and qualities of each good are the retroactively determined things. 

I don't think you really even need "historical prices".  I doubt anyone cares what the price of milk was 300 years ago outside of extreme historical reenactors.  All that really matters is what it is when the player walks into the market, and what it will be in the future, if they choose to speculate.  (Probably not on milk futures, though...)

How do you watch for shortfalls of chairs if you only have an abstract furniture type in your simulation?

Equal value materials won't have separate S&D curves. But if you keep track of item type, and separately keep track of material, you haven't actually optimized anything. You'd have a list of items types, and for each item type a list of materials, which amounts to the same as having a single list of items, indexed by item type.

Actually, yes you have, with even that much. 

If there are 50 material types, and 50 types of tools, you are tracking 100 values compared to 250.  Even with the weakest possible optimization, you've already more than halved the amount of data you are updating.

Yes, but you are sacrificing function. Imagine that breast plates are less likely to get damaged than gauntlets. And imagine that a town's primary leather source changes during it's history, so that it gets leather from different animals, switching from penguin leather to lion leather. It should the be the case that the it has more penguin leather breastplates and more lion leather gauntlets. Now that's not an important use case, but on the other hand, the optimization may not add much speedup.

Beyond that, like I said with the car, you don't have to actually iterate this value for every single year.  As long as the actual conditions don't change, you can simply track a vague rate of surplus for the year, and assume a constant rate of trade that lets you skip over even performing an adjustment of the goods available.  You only need to stop and adjust for the years where something changes, such as when there are sudden labor shortages or trade routes collapse. 

Again, you don't even have to be exact - a player isn't going to recognize that there should be only a 4% chance of a monkey leather item, when the weighted averages, by simply using loose accounting with the weighting, results in a 5% chance.  How are they ever going to figure it out? 

It makes no more sense than complaining that the inside walls of a tower are only randomly generated when they walk within a certain range to complain about how imported monkey leather seems 25% too common.

I agree with all this, but these ideas are separate from aggregating items into categories, whether by material or type.

[NW_Kohaku]

How do you watch for shortfalls of chairs if you only have an abstract furniture type in your simulation?

First, I'm talking about abstracting the specifics - you can still be abstracting by tracking "chairs" in general, as opposed to "microcline chairs" having a completely separately tracked inventory from "orthoclase chairs".  I never said you had to abstract "furniture type", and wonder where you got that idea.  I get the impression that you and Sowelu are misinterpreting what I am saying with most of these comments.

The point of abstraction is that you only track the data you need to track.  If you need to track chair shortages, you track chairs.

Second, if we are talking about broader categories of types being abstracted, furniture would be the easiest one to do, anyway.  Furniture does not deteriorate, all furniture items are made of the same types of materials, and furniture types like doors, tables, and chairs are ubiquitous enough that you could easily just use a giant fungible mess and assume that a master stonemason could just as easily have produced a bunch of tables instead of a bunch of chairs that month, and it would make no real difference.  A "chair shortage" would come from the exact same set of situations as a "table shortage", anyway.

If you want to, you can still have a "chair shortage" as distinct from a table shortage by simply tracking when furniture in general is low, and then randomly determining that it results in a shortage of specific types of furniture more heavily than other types, and make a procedural determination as to which piece of furniture feels the pinch.

As such, it's not even a problem if we assume the problem case you are thrusting upon me, anyway.

Yes, but you are sacrificing function. Imagine that breast plates are less likely to get damaged than gauntlets. And imagine that a town's primary leather source changes during it's history, so that it gets leather from different animals, switching from penguin leather to lion leather. It should the be the case that the it has more penguin leather breastplates and more lion leather gauntlets. Now that's not an important use case, but on the other hand, the optimization may not add much speedup.

As I have said repeatedly, the probability pools for materials can shift in the abstract and retroactively trace changes as the need arises.  I don't see why anyone would ever want to make "leather breastplates" (which technically don't even exist) decay faster than gauntlets, anyway, but assuming that existed, then you would simply trace the gauntlets back the appropriate period of arbitrarily determined time back to the proper reference in the probability pool separately from the trace that takes place for the breastplate at the time that the data is needed.  That is no more difficult than making only one trace.

Further, even if what you fear were to come to pass, and there was a loss of resolution due to the abstraction, and for some terrible reason, the game were to simply declare a full set of lion leather, where, exactly, is the actual loss in gameplay?

How does the player even know when a leather gauntlet was made, now?  How can you track a leather gauntlet back to a specific hunting expedition, even if there was an exact and complete historical record of that event in worldgen, when that is not recorded in legends mode and never comes up in gameplay?  Do you even know if that animal was hunted or raised in captivity, for that matter? What are we losing, exactly? 

You're arguing against the solution to a real problem by inventing an imaginary problem tailor-made for the current problem to "solve". 

You also name no basis for your second claim, here, (that it would make no difference in speed,) when I have actually said why it would result in a speedup.  If, instead of adjusting every single value of the material-shape combinations for every game year that goes by, you instead abstract shifts in probability pools only as changes in the supply takes place, you could result in an order of magnitude of faster handling of the trade portion of worldgen, which is currently one of the major bottlenecks, alongside rampages and warfare.

[King Mir]

You've lost track of what you're argueing about. I think some of your ideas are good. I do take issue with your previous statement that any optimisation is necessarily worthwile, particularly the one I brought up.

How do you watch for shortfalls of chairs if you only have an abstract furniture type in your simulation?

First, I'm talking about abstracting the specifics - you can still be abstracting by tracking "chairs" in general, as opposed to "microcline chairs" having a completely separately tracked inventory from "orthoclase chairs".  I never said you had to abstract "furniture type", and wonder where you got that idea.  I get the impression that you and Sowelu are misinterpreting what I am saying with most of these comments.

I was the one who said that I would sooner abstract by types like furnature and armor than abstract by material types. Then I commented that such an optimisation could be a bad idea if it doesn't leed to speedup. You seemed to contest this, and say that you could do it without sacrificing features.

Second, if we are talking about broader categories of types being abstracted, furniture would be the easiest one to do, anyway.  Furniture does not deteriorate, all furniture items are made of the same types of materials, and furniture types like doors, tables, and chairs are ubiquitous enough that you could easily just use a giant fungible mess and assume that a master stonemason could just as easily have produced a bunch of tables instead of a bunch of chairs that month, and it would make no real difference.  A "chair shortage" would come from the exact same set of situations as a "table shortage", anyway.

If you want to, you can still have a "chair shortage" as distinct from a table shortage by simply tracking when furniture in general is low, and then randomly determining that it results in a shortage of specific types of furniture more heavily than other types, and make a procedural determination as to which piece of furniture feels the pinch.

As such, it's not even a problem if we assume the problem case you are thrusting upon me, anyway.

I agree that the relative quantities (and therefore prices) of chairs and tables are not likely to fluxuate much, which is why I suggested this idea in the first place. But they could fluxuate, because after all they are used in different ways, and not always together, particularly with market stalls. So bundling tables and chairs into a single furnature object would only be a good idea if it lead to meaningful speedup.

You're arguing against the solution to a real problem by inventing an imaginary problem tailor-made for the current problem to "solve". 

I'm argueing for accurate simulation where reasonable. Simulation is better than retroactively computing what goods should be, because it does not explicitly need to model observed economic effects, only economic influences. In order to, for example, retroactively model how the price of chairs and tables may diverge you would need an economic model of what would cause that. But if you let the seperate demand of the price of chairs and tables be part of the simulation, then the prices would diverge organically.

[NW_Kohaku]

First, I'm talking about abstracting the specifics - you can still be abstracting by tracking "chairs" in general, as opposed to "microcline chairs" having a completely separately tracked inventory from "orthoclase chairs".  I never said you had to abstract "furniture type", and wonder where you got that idea.  I get the impression that you and Sowelu are misinterpreting what I am saying with most of these comments.

I was the one who said that I would sooner abstract by types like furnature and armor than abstract by material types. Then I commented that such an optimisation could be a bad idea if it doesn't leed to speedup. You seemed to contest this, and say that you could do it without sacrificing features.[/quote]

OK, that's where the miscommunication is - I'm not saying that we shouldn't abstract by "shapes" (like furniture or armor), but that we should abstract shape and material type separately, and then combine them when they actually appear in game.  (That is, there are 200 tables in this town, and separately tracked is that tables have a 5% chance of being microcline.)

Second, if we are talking about broader categories of types being abstracted, furniture would be the easiest one to do, anyway.  Furniture does not deteriorate, all furniture items are made of the same types of materials, and furniture types like doors, tables, and chairs are ubiquitous enough that you could easily just use a giant fungible mess and assume that a master stonemason could just as easily have produced a bunch of tables instead of a bunch of chairs that month, and it would make no real difference.  A "chair shortage" would come from the exact same set of situations as a "table shortage", anyway.

If you want to, you can still have a "chair shortage" as distinct from a table shortage by simply tracking when furniture in general is low, and then randomly determining that it results in a shortage of specific types of furniture more heavily than other types, and make a procedural determination as to which piece of furniture feels the pinch.

As such, it's not even a problem if we assume the problem case you are thrusting upon me, anyway.

I agree that the relative quantities (and therefore prices) of chairs and tables are not likely to fluxuate much, which is why I suggested this idea in the first place. But they could fluxuate, because after all they are used in different ways, and not always together, particularly with market stalls. So bundling tables and chairs into a single furnature object would only be a good idea if it lead to meaningful speedup.

I'm argueing for accurate simulation where reasonable. Simulation is better than retroactively computing what goods should be, because it does not explicitly need to model observed economic effects, only economic influences. In order to, for example, retroactively model how the price of chairs and tables may diverge you would need an economic model of what would cause that. But if you let the seperate demand of the price of chairs and tables be part of the simulation, then the prices would diverge organically.

To that, I would say that a retroactive model is a more elegant solution than brute-forcing through simulation, and can achieve the same results with a properly constructed formula.

In fact, the methods of a retroactive model would actually add some of the functionality that a brute-force simulation would have to drop by necessity, such as actually gaining the ability to track price fluctuations retroactively (by retroactively reconstructing prices based upon their fluctuations in supply and demand) by having an abstract model tracing those fluctuations in supply and demand. 

Currently in legends mode, if you look up someone turned into a night creature, they are simply listed as a night creature (as in, "in the year 21, the twisted hag spouse Urist McVictim became King"), because the game simply overwrites what that creature is after the fact, and retroactive looks at history do not reflect a pre-night creature state.

So, contrary to my previous statement, abstract (retroactive) pricing models actually would give you the ability to see what the price of milk was 300 years ago, provided you input the functionality to extrapolate that data from the fluctuations in supply and demand, which can be tracked, provided you abstract the tracking of generation sufficiently.


(And as an aside, "arguing" does not have an "e" when you throw an "-ing" on the end of it.  I don't want to be a nit-picker, but when a poster makes the same spelling mistake twice in one post, it often means the poster is learning the language, and misspellings can become a bad habit that are hard to unlearn.  Likewise, "optimization".)

[King Mir]

...we should abstract shape and material type separately, and then combine them when they actually appear in game.  (That is, there are 200 tables in this town, and separately tracked is that tables have a 5% chance of being microcline.)

So how do you get 100 entries for 50 types and materials under that model?
With 200 chairs, 49 other item types, and 50 materials (on average) you should get 50*50=2500 entries. With the strait forward method, you get 200*50=10000 entries, assuming that chairs are an average quantity good. You're changeing which variables determine the entry list size, and maybe it's a little faster your way, but your previous math does not match what you're descrbing here.

To that, I would say that a retroactive model is a more elegant solution than brute-forcing through simulation, and can achieve the same results with a properly constructed formula.

In fact, the methods of a retroactive model would actually add some of the functionality that a brute-force simulation would have to drop by necessity, such as actually gaining the ability to track price fluctuations retroactively (by retroactively reconstructing prices based upon their fluctuations in supply and demand) by having an abstract model tracing those fluctuations in supply and demand.

I'm sorta sceptical, and you haven't described the details of how this would work enough for be to judge the viability of this idea. In short, I don't get it.

(And as an aside, "arguing" does not have an "e" when you throw an "-ing" on the end of it.  I don't want to be a nit-picker, but when a poster makes the same spelling mistake twice in one post, it often means the poster is learning the language, and misspellings can become a bad habit that are hard to unlearn.  Likewise, "optimization".)

Yeah, spelling is a doomed cause for me. I'm not learning the language and those bad habits are already established. Normally, they'd be caught by the spell checker, but right I'm using a pc that doesn't have it.

[windo]

Tracking probabilities is in no way better than tracking totals (both are just numbers). In fact, totals are more intuitive to use and thus it's better to use those in the code.

The abstraction bits are worth considering though.