-
Notifications
You must be signed in to change notification settings - Fork 16
v0.2 Update 3: Reboot 2
February 10, 2025
So one major issue I had with the sim was the volatility of the job market. Agents will run out of money and switch jobs in mass. The system was too volatile and needed to be tuned. Since then I've added a bunch of new things I want to jot down.
- Reworked bid/ask logic
- Reworked price belief updates
- Added a bunch more graphs
- Added inspector views of each agent, their cash, hunger states, inventory, and bids and price beliefs
- Lots more graphs to the point I no longer need to dump the data to Tableau
Originally, I wanted to manipulate the bids and prices of each agent in order to create some training data. But I quickly realized that 1. there would need to be much more data then I could possibly create and 2. I was not making sane decisions. So instead it became a way for me to inspect the AI on each round, and this way I could very easily spot issues with the logic and make on the fly tweaks. I was able to get to a point where I can run for 80+ rounds without anyone going broke. Once I got to this point I added banking, which messed up everything again so I am considering disabling this for now and add back player controls to turn this back to a game.
The quality of life metric for determining bids was nice but I couldn't equate food vs other commodities and the different quantities that an agent needs as input to their production. This is something I might come back to reevaluate. But I've since pivoted to a system of determining number of bids and asks similar to the original paper, but I started with one or two conditions and slowly build them through trial and error.
Agents will now bid for food first if they are out of food, and alternate bidding for food vs bidding for batches of inputs, that is the number of inputs needed to produce one batch of output. A batch is defined in the recipe for the output. Food, for example, needs two wood and one tool, and generates ~10 food output. So an agent will try to bid up multiples of 2 wood + 1 tool. However, the bidding process is not all or nothing so an agent may get partial offers. So the next round, the agent needs to bid in quantity such that, if successful, will result in full batches of inputs in its inventory. If it had 1 wood already, it might only bid 1 additional wood and 1 tool. It may have enough cash to bid multiple batches of inputs, so it must take current inventory into account to maximize the utility of its disposable cash.
One issue I just found is that, when alternating between bidding for food vs bidding for inputs, it may not have enough money for a full batch of inputs but has enough money for more food, so it ends up bidding many units of food but no inputs, starving it self of future production and sales. I can try to break out of the loop if that happens.
The main limitation of this method is all agents will try to consume to the fullest, so the only time someone will get super rich is if it is unable to consume everything. I'd like to add back in the QoL metric so the more inventory someone has the less likely it will buy more.
Asks and bids need to respond to price fluctuations, supply and demand, and how much it managed to trade the last round given units offered at what prices. So far I've separated the quantity asked/bid from the price of those offers. Mainly because I don't have a cohesive way to compute both at once, though I'm bleeding the two together in one or two cases, such as when an agent has 80% of the money to bid on something, so I'll manually override the prices such the agent will make the bid but at lower prices. The agent may not be able to trade, but sometimes the ask prices are much lower so things will work out better then if the agent didn't bid any.
In general asks are maxed out and I haven't seen a need to reduce that any.
I've taken out the price belief range and just stuck to a single price. The reason is it's just another variable that adds to the headache of debugging. I have to worry about the price level as well as the spread of the range. I just stuck to a single number now and it's been working out ok.
I'm taking into account supply and demand as well as the min/max/average clearing and bid or ask prices. This is to snap agents to sensible prices if they ever go too high or too low without them having to hunt around for several rounds (incrementally raising or lowering prices until it gets more items traded).
There is a separate logic for buying and selling prices.
Buyers adjust their prices based on fraction bought. If none was bought, the offer prices are too low, assuming there is some non-zero supply. Prices will still rise even with no supply just to signal to the market that there is stimulated demand. But prices will rise rapidly if there is demand and especially if the agent is starving. I added a days starving counter for this. It's better than a negative food tracker because the counter is reset as soon as it gets any food. This increases the survivability of agents so they don't die off too quickly. People are resilient.
Buying does not take into account current inventory so far, which really is necessary so agents will bid less if they have a lot. This helps create the effect of the rich hoarding cash.
Sellers adjust their prices based on sold ratio. The more it sells, the higher it can raise its prices. The lower it sells, the lower it'll drop the price. If it sold none, it will drop the price logarithmically (not exponentially, cause then prices will go to 0 or negative quickly) depending on its number of days starving.
I finally added banking a couple weeks ago and it's been a lot of fun. I hardcoded the terms of loans, the interest rate and term of each loan. The bank has a .1 fractional reserve ratio, meaning it needs to have 10% of its assets in deposits (can only lend 9x what it has). Keeps an accounting book of each agent's loans. Each agent can have some max number of loans and max quantity of debt. Once the agent maxes out then it may end up defaulting unless it manages to pay back its loan real quick. Each agent also deposits excess money back to the bank to fuel future loans. Each round the bank withdraws from each agent their deposits to make loan payments. That means some agents will end up broke and won't be able to buy what they need.
I think a better implementation is for the agent to reserve that payment, but can optionally dip into it to buy food for one more round if it has outputs to sell, that way the agent can survive for an extra round? This isn't so meaningful since agents automatically borrow when short on money. But since it pays back at the beginning of the round, it will only borrow money if it doesn't have enough to pay back, vs not enough money to both buy what it needs and pay back.