(I have a Patreon to support my open source projects, of which this is the one that is currently getting the most development time. I also have my stock-flow consistent modelling module, as well as my research platform that I use to generate the charts for my blog. All use Python, although I do my plots in R.)
The code is split between two GitHub projects: “agent based macro,” and “space trader”, both available at my project page: https://github.com/brianr747. The agent-based macro project is aimed to be the “serious” agent-based model simulation engine, while the “spacetrader” project uses the engine to build a hobby video game. Currently, the only working model is in the space trader project, but once I have an adequate model, I will put it into the agent-based modelling project so that it is available as a stand-alone entity. Since everything is extremely rough, I almost no user documentation, and so it requires some Python expertise to get anything to work.
Model Interaction Overview
The figure above shows the (primitive) client screen. There are two planets (green circles), and the player controls a spaceship (blue square) that can fly between them. The player can buy/sell the only commodity (“Fud”), and the cash available and ship inventory is shown at the upper right.
The player only sees the prices (and size of the best bid/offer) at the current planet.
The objective is to buy low and sell high. (Spoiler: this is rather easy to figure out with one commodity and two planets.)
Keyboard commands are used to control the simulation.
Underlying Model Description
The model is a hybrid between a pure agent-based model and an aggregated model. Some “agents” are in fact aggregated sectors. They exist on “locations,” of which there are two in the game simulation. In a Earth-based simulation, they could be cities, countries, regions.
The agents/entities that exist are as follows.
Markets. All transactions go through (wholesale) markets, with each location having a market for every traded commodity. Adding direct agent-agent transactions might be more realistic, but it is not clear how much it would change things for algorithmic agents. One hoped-for change is to create retail agents that buy their stock from the wholesale markets, and then sell their goods to households. (Right now, households directly purchase from the wholesale markets.)
Central government. Exceedingly minimal now. Issues a fiat currency, and runs a Job Guarantee. Currently does not impose any taxes, since the Job Guarantee charges for its output. (Adding taxes is easy, and will be done relatively soon.)
Job Guarantee. All workers not employed in the private sector work in the Job Guarantee. The Job Guarantee produces food, and sells it at a profit (which acts as a tax). The private sector is currently quite small, so the Job Guarantee was filling in for it in the initial iterations of the model. I expect that the Job Guarantee will iterate towards a version where only some workers produce food, and the remainder are doing “good deeds” that are not sold in the markets. This would mean that the Job Guarantee sales revenue is much smaller, and it will act more as an automatic stabiliser. The Job Guarantee produces food since it is a stand-in for non-discretionary purchases by the household sector, and this gives the government a stockpile to lean into attempts to corner the market by sneaky agents.
Private sector producers. They hire workers, and produce food. The assumption is that private sector producers apply more capital, and thus have a higher output per worker. (The production function is linear: multiply the number of workers by a productivity constant.) This higher productivity is needed to allow the private sector to have a chance to grow versus the Job Guarantee output. (The simulation starts with all workers in the Job Guarantee, and the private sector ramps up employment.) The behavioural functions for these producers is absolutely minimal. One thing that will need to be added is their ability to pay dividends, as they would otherwise hoard ever-increasing amounts of cash.
Travelling agents (space ships). The agents that transport goods between locations. They currently do not employ workers, since the assumption is that they would have relatively small crews versus the food production units. Currently, the only travelling agent is controlled by the player. AI-controlled travelling agents would need to add “profitable trading opportunities” logic.
The labour market currently uses a deterministic drift to and from the Job Guarantee and private employers. Private employers offer a wage that is 10% greater than the Job Guarantee wage. One possible change is to have a random “job search” model where workers jump around between potential employers, and so the private firm wage offer logic would need to be beefed up. However, with a single good economy, it does not make too much sense for there to be much wage disparity between firms.
With just the few additions noted above, we end up with a minimal model that describes a mixed economy with private producers and a Job Guarantee.
Extensions
Multiple commodities. The framework already supports multiple commodities, it is just that the simulation does not refer to the other ones. My initial plan is to split household consumption between a non-discretionary good (food) and discretionary good (space brandy?) that absorbs consumption volatility. This then allows a more interesting consumption function. Then, we would need something that acts as a capital good needed to construct new production units, so that the model can get a proper business cycle.
New production agents that have inputs other than labour.
Headquarter agents that act as the corporate parent of multiple private sector agents. These headquarters would need to be staffed with cubicle dwellers, and so this would create a need for skill divisions within the labour market.
Multiple currencies. Currently not supported, but I think currency support needs to be added very soon. (Adding it later would be a nightmare.)
These extensions would allow quite complex simulations. Most of them appear to be relatively straightforward to add, with only multiple currencies looking awkward. The bulk of the work at this point is getting more complex behavioural functions.
Code Clean Up
Since it was unclear to me what structure would work, I went with the “build something that works first, then refactor” strategy. However, I will need to start refactoring relatively soon, since the changes affect how new features are implemented.
Event handling. The simulation runs via putting timed events into a queue, and then processing them when their timers hit. The event handling works, but the way in which data are passed is a mess. I need to clean the data management up. (Most of the existing events did not have much data being passed, so the problems did not crop up until I added ones that did.)
Class structure too deep. As soon as I made some decisions that narrowed the applicability of a class, I subclassed it. I may need to collapse some of those classes.
Distinction between server and simulation. I may need to look at the split between “server” and “simulation” in order to get client-server operation working.
Unit tests. I covered some low-level algorithms, but I made no attempt to cover events. I will have to think about unit test strategies once I have done some refactoring.
Future Plans
I hope to get more coding done over the coming month, with an eye to putting the project in a state where it is easy to pick up and add new features. After that burst is done, I will return to sporadic updates.
I expect that there will be two work streams.
Some “serious” simulations used to illustrate some issues that do not show up in aggregated models.
Putter around with my hobby space trading empire game.
No comments:
Post a Comment
Note: Posts are manually moderated, with a varying delay. Some disappear.
The comment section here is largely dead. My Substack or Twitter are better places to have a conversation.
Given that this is largely a backup way to reach me, I am going to reject posts that annoy me. Please post lengthy essays elsewhere.