An attempt at mapping using economics.

[Crayons]

So with all that laid out. Do you have any ideas how I could bias the choice of a house build position ? It has to be done using numbers I have right now at the point of the build not a speculative AI thing about where you might think there is best chance of limiting the travel to and from the house. For example I could keep a long term weighted average of all the positions he has been so that its keeping a constant center of gravity type position of his routes and try to put the house as close to that as possible. That kind of thing ?

I've have been thinking about this! However I can't really come up with anything you won't have already considered, I imagine. The following is likely very obvious but it's my thought processes...
Most of this is stuff I think you have on your "to do" list, and I'm really looking forward to seeing them arrive !!

Salent points?
I think a fundamental is the decision of profession.
In times of yore a persons workplace was also his home.
Most of a person's time is taken up with work (and sleep) - he cuts down trees every day but probably only goes to the "shops" once a week (say).
"Refined" products are easier to transport than raw materials.

So a person will generally live next to his raw materials. That is biased by
a) the quantity(/quality?) of raw materials present - ie. how long he can work the site - this is forward thinking but not really speculative - the quantity is measurable
b) "distance" from his customers - this is based on the "road value" factor - time and effort. This may be significant if aspects of "perishability" of the goods is considered. Grain can be transported further than bread. Bread goes "off" faster, for example.

What should transpire, I would imagine, is a radial pattern. Mining/forestry - any non-perishable product can be as far from the centre as it likes - proximity need is more about "shopping".
Long term perishables producers, eg. farms are closer.
Short term perishables, eg. processed foods, fish etc are even closer

So what is at the centre? The place where all this is traded.
Why is that place there? Because in the grand scheme of things that's where the next echelon of trade progresses. I call to mind the history of Stilton. It got its name from where it was distributed from, not where it was made.

On the detail side of house placement.
I think you might want to introduce building "sides" and "separation" - people don't generally build immediately in front of or behind someone else's house - I imagine there would be some sort of shouting involved! A "separation" factor would probably be required - this would be dependant on profession? A farmer is likely to shout much more about crowding than a blacksmith
One exception to this would be at cross roads, where building (say) one space away and behind someone else is "OK". I would imagine that the major of the two roads would get populated more first....? At some point adding to the end of this becomes "too far" compared to living on a "side street". A crossroads represents a minor "plus" factor for placement as it adds "value" in terms of ease of access, I guess.

Expansion
How a farm doesn't end up in the middle of a town that grows around it? Well, for this you need land values. A "close in" farmer will sell his high value land and eventually move? I'm unsure about this.

Ultimately, I think the town has to have that focal point - the market. That, in turn, needs the external communications links.

"Common Land" - I thought I'd throw this one in here. Market's and parks and some other spaces could be designated as Common Land, this should add a certain extra permanency and protection for such spaces...?

Like I said at the start, I can't help you on the code front, but I hope this sort of logical assessment is useful?
cheers!

[Redrobes]

I started to code up the bartering but ran into a problem cos I only have the list of items per person one at a time. So the longer I do this the more I think Talroth is correct and that I need a general repository of items. Theres a coding technical problem with that with the way I have implemented it so this post is one for the C++ coders.

I was using standard template library (STL) vector class and thats convenient because it overrides the '[' and ']' operators to allow quick indexing ops. Great... but, if you want to specify the location of an item in some array then you need to specify the array and the index for it. There are quite a few of these arrays and so this is a bit of a problem. For example you might have to name all the arrays and then go and search which array you mean via some switch statement. Thats horrible. The obvious solution is to just have a pointer to the item you want to keep track of and screw which array its being held in. So thats what I did when I coded it up. Theres been this nagging little demon sat on my shoulder tho and it keeps reminding me that there is a big big problem with this. The issue is that if I add or remove any item from any array then it might invalidate the pointer because behind STL vector it reallocated the whole array if it gets too big. So pretty much, going with this idea I have to ensure that all items have been added to the array before I start grabbing pointers and I mark items I delete with a tag which says deleted but not actually remove it from the array. So ok cool.

But now I need to get pointers to other peoples items which will change if I now barter stuff so that when I calculate the next guys stuff it will change from the last time. If you see what I mean. Maybe its possible to code around this but I threw the towel in at this point and said oh sod this STL vector crap, it has to go and changed all the code from using the '[' and ']' operators to using the full iterator notation which is a real pain cos its so wordy and kludgy. So once that was done I binned the vector class and switched over to the list class. The advantage of the list class is that it never reallocates the items in the list so you can grab a pointer to them at any time and as long as you don't delete the item then the pointer is safe. But changing items in the list does not affect the other items in the list so all pointers to them are now ok.

I measured the completely unexpected drop in speed. Ok I expected a little drop cos you have to jump via a pointer from one item to the next but in general I am traversing all the items in lists in sequence so I am not continuously running through them in some random order. Perhaps a 2x speed loss. I was totally taken aback when I got about 10,000x speed drop !

So I dunno now. I think something very lame is going on and I may have to drop STL and use my own implementation of lists. I know that I can write a list class maybe a few times slower than vector but not this amount. When I do that then I can have a central repository of items where I can add and delete from it and keep hold of the pointers to items for reference later. I think there's something very broken with the MS STL list class.

So its being worked on a bit but not in the mapping sense for a mo while I get this knocked into shape.

[Redrobes]

Im getting a bit of break from the day job which might not last but whilst it does I can continue on this for a bit more. I rewrote a large chunk of it to handle a pool of items and now that I know what everyone can see I implemented the bartering thing and that seems to be working ok. It does not happen too often but then I am only implementing a small number of people so it would probably increase with more people. The problem with this app is debugging. Its iterative and spread across many people. You have large sets of items which changes on each turn. Oh well.

I have another anim but its a lot like the previous ones.
http://www.viewing.ltd.uk/Temp/CG/Economap/Anim8a.avi

[Crayons]

Sorry RR, I meant to reply earlier but I've been away for a bit!
It's still looking magnificent, but I think the road usage alement is still a bit weak. I feel that in order to gain some sort of permanence to roads they should have a much more beneficial effect for using them over "cutting your own path". Basically, at the moment the roads are what I'd call "out of focus" - the added "value" of worn paths needs a steeper gradient, as it were, to tighten up the focus?
I can imagine, for example, a situation where a new resource is starting to be used and an existing road can take you partway there for next to no effort and then you need to "cut" a new path at an angle from that to reach the new destination. If, in this example, the existing road has a usage value of zero then you'd go up that and then cut a road at 90 degrees from it to your destination? Reality is a number somewhere...
Please keep up the good work! I think you may be getting somewhere really useful for road layouts even if you might be having second thoughts about the economics???

[Redrobes]

I know what you mean and I am in agreement with you in principle. I deliberately added the blur to the roads to try to smooth out the difficulty of travel across terrain so that we would get more curvy roads and better layout otherwise it all looks like a US city block or strong 45deg lines going everywhere. The idea is to take the final generated terrain with the blurry roads and then put it through a procedural texture generator which should paint them in a nicer sharp version. Maybe I should show that happening. It would also paint the trees with a tree texture, water with one and so on so it looks like a proper map. I think the res might have to be bumped up a bit tho.

I knew before I started that this would be a right bitch to program and it really is. You get odd funnnies happening at many many iterations into the sim then you make a slight change and the whole sim is then different and the funny goes away and you cant reproduce the effect again. Then a bit later something else funny happens. Its more of the nature of iterative programs rather than economics that is the issue.

The basis of what could be generated is definitely possible. You could still make a full history of the town and people and have them all named and have all their interactions to the others all mapped out but the limit to its possibilities is down to the complexity of the program and how much complication can be modeled before the programmer goes insane

I'll run a sim and show the kind of final map I had in mind tho cos maybe people are getting the wrong impression that these output movies and pics are thought to be the final map. They are just the debug version of it showing as much info as I can manage to squeeze onto an image in one go.

[Korash]

This is very interesting, and I was following it until a while ago.....I don't have the time to read back atm so I will ask instead of reading for the answer.....Is farming taken into account at all in the economics of the programming?

[Redrobes]

Yes, when they are hungry then they look for food. When none is available then they would either try to barter for some or else as a final resort they would probably plant some seed. The reason I say last resort is that the program works out how long it will take before the food turns into harvest so they can eat it and its quite a long time. So when they plant seed they have to wait for it and may spend their turn tending crops using their farmer skill. When the crops get to about 50% then they cant be tended after that and they have to wait for the final harvesting. The reason for that 2nd phase is that if not then they would plant seed and stand over it like a vulture tending it to death until it harvested. When they are unable to tend the crops then then cant do any more so they plant more crops. So this way it generates multiple fields of crop. The thing is tho that once the first field harvests they eat some and carry the rest. Then the second field harvests and they don't need it so potentially they can sell it. So in effect you will only see one or two fields being worked at once unless every one is hungry in which case there is a mass planting. There is no intelligence enough to predict that the market for crops will be high so lets start planting before anyone is hungry. This might be mitigated when there are many many people to average the demand out or else if there is a mill that is a constant need for crops (grain). Maybe if they valued stored harvest then they might sell it to the grain mountain even if it all goes to waste. Perhaps that is a real reason why its done in real life. You must support the mechanism to generate crops in the times when the market does not demand it in case the market rises in the future. Anyway, that bit of it is not in the program, hence not too many fields at once.

[ravells]

I've been following this thread although much of it is beyond me. It would be really cool if you could run this sim over a world generated in Fractal Terrains to generate cities, towns, villages etc and other 'human' elements on the map.

[Redrobes]

Yes that is its primary purpose. I think you would need to run it once per village / town or city but in principle the idea is make up the world using a procedural method, extract bits of it using a shader that gives rock, trees, water (sea and fresh) and land (plus I might add gradient in the future too) and then let this app make the man made bits of it and make the map + store it all in a database so we can access all the people in it too.

[v4nz]

Hello!

This is a really cool thing you're doing here... has there been any progress this year?