Monday, October 30, 2017

A Programmed Trade System

I've been approached by a programmer who, reading the recent posts, has expressed an interest in making the trade system into a program.  We're just discussing it, right now.  No time lines have been set.  Only the scantiest of details have been discussed.  There is enough for him to try out a few things, to solve some up front problems.

We'll probably be looking at some kind of beta stage, as a problem solving tool.  And, whenever that comes to light, I'll probably have to take down the trade content on the Patreon account, since if the auto-trade system works, people might look at those files and see how to duplicate our work.  That's a very real thing, but it won't happen for a while.  In the meantime, I'm going to continue working on upgrading things, particularly as I have reformatted everything and worked out an interesting availability system.

Just now, I'm tagging items according to the climatic classification that each market city exists in, according to the Koppen system.  I'm hoping this will narrow the distribution of certain agricultural resources in my system.  For example, looking up "olives" would probably tell me that they're grown in a warm, Mediterranean climate, but that wouldn't be very helpful.  On the other hand, by tagging every market in my system where olives originate, I can get an exact distribution for olives and everything else, helping me build an availability system not only based on what climates have access to olives, but which ones don't.  And that applies to every other product as well.

I was also thinking of making a mirrored distance table - the table that calculates the distance of any given trade city from every other - for the winter period, which would involve finding all the calculations for very cold regions (specifically, humic micro-thermal climates, like most of Canada), doubling or perhaps trebling the distance between markets to simulate the decreased likelihood of trade during the winter months.  This would just mean that when I wanted to calculate a city when my game was taking place in December, I'd simply go to the other table and use that.  No doubt, northern products would increase in price and decrease in availability (and thus disappear from my equipment list), while places that made use of northern trade routes, such as the Baltic Sea, would have to ship through more southern cities and ultimately that would increase the price and lower the availability of many things that yet originated in relatively warm climates.

Work, yes, but the results could be fun.

So, still thinking, still developing.  I still have many ideas.

4 comments:

  1. This is really cool, and while losing access to the trade table would be unfortunate, I for one would be extremely interested.

    I hope this works out.

    ReplyDelete
  2. Very cool. A program that did a bunch of the work of setting up your trade system would be a great tool.

    ReplyDelete
  3. This is very exciting news. I wonder if some of the path-finding work for calculating distances between trade cities could be done through an online API like that of Google Maps. It's a bit beyond my programming knowledge, but they seem to have some kind of capability to use custom map tiles, which might allow path-finding on fantasy maps:

    https://developers.google.com/maps/documentation/javascript/tutorial

    ReplyDelete
  4. Colour me interested. If you can make the trade table into an easily used program for managing trade for third parties, I would definitely be interested in paying for it.

    ReplyDelete

If you wish to leave a comment on this blog, contact alexiss1@telus.net with a direct message. Comments, agreed upon by reader and author, are published every Saturday.

Note: Only a member of this blog may post a comment.