My First Agent Economics Model:

Below you will find displayed a demo of the agent economics model that I am currently putting together.
This is a fairly simple demonstration of the model to test some ideas and try and get the market system running correctly. While making this model, this turned out to be one of the more complex and tricky parts, and indeed has held me up by several days.
This Model consists of 3 separate programming object types which exist inside the applet and interact with each other.

What is it?
This model revolves around 3 'sets' of goods, if you wish, consider them as 'breakfast' 'lunch' and 'dinner'. Each good set consists of 5 individual goods, consider these as ingredients.
To begin with, each good is produced in the same quantity, which is how the 'consumers' like their meals. As the applet starts, this is 300 unit per cycle per good/ingredient (which actually enter the market as 3000 units every 10 cycles).
Consumers prefer dinner, resulting in this being the most expensive. This model contains 100 consumers who each receive a cash income of between 100,000 and 200,000 credits every 5 cycles, this isn't expressed particularly well in this model at the moment, since no 'income' preference is currently defined in their demand function.

The Demand function:
The demand function here is relatively simple, designed to demonstrate and test simple 'complement' and 'substitute' preferences. For simplicities sake, the preferences are defined at the goods level, the goods within each good set are all complements of each other, each good set itself is a substitute of the other. So if one particular meal becomes more expensive (such as is caused by limiting the supply of one of its ingredients), people demand less of the other ingredients in that meal and their price drops. However since the overall price of that meal has now increased the consumers substitute it for the other two meals and their prices have to rise to cope with the increased demand.
This demand function works using the idea of budgeting. The greater a consumer prefers something, the larger portion of their available budget they are willing to spend on it. However, if a good becomes relatively more expensive they must alter their budget to reflect this. The complement/substitute effect can therefore manifest itself as how they change the percentages of the budgets they have for each good. If a good is a complement, the increase in the percentage of the budget they have to allocate for a good of increased price offsets the budget they have for the other goods in that category, so they have less to spend on the other goods and can buy less, If a good is a substitute the result of an increase in price is to increase their budgets for the other substitutes so they can buy more.

The Market:
However, this is not the whole story. As I have already stated, the amount of goods available to purchase and consume at any given period of time is fixed, the fact that everyone wants to buy more of a good, does not mean they actually can. In fact they can only buy the goods that the market has to offer. The market functions to clear all the goods which enter it. This turned out to be one of the more tricky aspects to this model. This market functions by trying to maintain a certain level of stock of each good, again for simplicities sake this is a constant 10,000 units, which doesn't change with supply changes (although some interesting results can be seen if this is changed). The primary purpose of this model however is for testing, and introducing this makes it difficult to see that things are working correctly.
If the stock of a good is below 10,000 units, and the consumers are demanding more per cycle than is being made available, the price is increased for that good. If it is greater than 10,000 and the consumers are demanding less than is being made available each cycle, the price is decreased. If the stock level is around 10,000 and supply and demand is equal, the price remains the same.
The easiest way to see why any particular ingredients price is increasing or decreasing, is to examine the unit stock graph. When the markets for each good have reached a relative equilibrium, stock for each will oscillate around the 10,000 unit mark for each good.

The Good Price panes:
The applet has three other graph panes apart from the unit stock graph. These show the prices for each good set, and actually contain 5 individual lines in each. However unless you change the supply of one of these goods, the price for each moves in unison (since each good within a set has the same demand function). In order to see the effects properly I suggest you wait a moment until price and stock have stabilized; as the effect of substitution can be quite small. (Since a changing the price of one good set is distributed among the ten individual goods of the other two sets, and the complement effect within each good set works to offset any one price increase or decrease).

On to play time:
Play with it, the bar along the bottom allows you to control the supply of each of the 15 goods, select from the drop down box which good you wish to change the supply. Then click either the increase or decrease button to change the supply of that good. (which is actually done here by decreasing or increasing that goods 'time to market') i.e. instead of 3000 being delivered every ten cycles, an increase in supply is manifested as 3000 being delivered every 9. Each good/ingredient is color coded.

N.B. The applet requires the java sun VM v1.4 or above installed on your system

If the applet doesn't start displaying data, refresh this page....

Who, why? and what next?
© Mark Parker, aka mSparks.

Please direct any comments and suggestions to my message center, The graph display for this applet model uses the java graph class library written by Dr Leigh Brookshaw of USQ Austrailia Mathematics and Computing department You can get the source for this applet (provided under the GPL) HERE
The agent economics concept, which is well documented by Leigh Tesfatsion is a concept I have been working with since late 1998 (even if I only discovered that recently), specifically within the Artificial Intelligence area, started as a late night realisation of a fairly simple algorithm that potentially explains the very fabric of every interaction we see in our day to day lives. however, as with the extremely simple model you see above, that fairly simple algorithm is quite far from simple, in fact, its more of a nightmare. However, gradually, over the last 7 years, it has evolved into something of more substance than the two simple pages of html it took to get it down and explain it. That, for now, you dont get, but you can read more on how it fits with other AI systems/algorithms in the article I posted earlier this year.
Most of the AI testing to date has taken place so far within the AQ2:LTKTBM game, This model forms the foundations of the next generation of work that is going into the TBM_AI SDK, LTBTBM - Licence To Breed The Borg Matrix. This game itself is a fairly mammouth undertaking, but with the use of GPL tools, code and the content provided by the increasing pool of supporters its quickly coming into view beyond anything I ever imagined when I first wrote those fateful pages.

LTBTBM
LTBTBM is a huge world based simulator, which utilises distributed computing and is designed to greatly enhance the access to data useable by the TBM AI, this AI system is designed not only to run around maps killing the enemy, but perform complicated risk assessment and inginuity on virtually everything thats thrown at it - to start with this will probably just involve building up its economics dataset and allowing the AI entities to interact with each other based on these rules.
Not much is available for now, and theres still some way to go, but things are moving at a healthy pace, some early screenshots (taken before I came to study at Boston College) of the mapping technology it uses are available below, some of the artifacts in these images still need fixing, but most were fixed before I left - these images are all rendered in real time: