I’ve been building a 3D life RPG on my own in Godot 4, using GDScript. There’s a free prototype on itch.io, and I wanted to share some of the work behind its economy and NPC systems.
The game has three playable characters for this MVP: a farmer, a merchant, and a mercenary. I’m trying to give each a different daily routine within the same town. Farming, running a stall, and exploring a dungeon all need to work with the same inventory, money, and market systems.
Eventually, I want a questionnaire to assign the player’s profession. That part isn’t implemented yet.
One problem I’m working through is how much of the town’s economy to simulate. I have a broader Python model for checking the setting and a smaller economy running inside the game. They operate at different scales, so connecting them takes more than copying numbers across.
The Python model uses no external dependencies. It compares household income, taxes, cash and in-kind income, and living costs across eleven political and economic regions, with the game’s town included as a separate local sample.
I run four conditions across those twelve entries: baseline, bad harvest, trade disruption, and population pressure. That gives me 48 combinations to compare.
These are independent scenarios with assumed inputs. They don’t simulate a whole world trading with itself over time. Their purpose is to help me spot inconsistencies in the setting.
For example, the current reference basket in the home kingdom comes to 168G per day for a household of four. That includes food, housing, fuel, clothing and tools, and medical spending averaged over time. It’s a balancing assumption, and the physical quantities behind that basket still need work.
The accounting checks are more definite. The script checks that pre-tax income equals post-tax income plus tax, cash and in-kind income add up correctly, and central and local tax revenue match the total. It also checks that total income stays constant in the scenario where population rises by 25% while production stays fixed.
Those checks tell me whether the arithmetic is consistent. They don’t tell me whether I’ve chosen good assumptions.
The garrison is a useful example. The town has around 2,000 residents and a registered garrison of 120. Under the current model, annual town tax revenue is about 4.68 million G. Compensating all 120 at the assumed local rate for 240 working days would cost about 6.22 million G.
The more detailed budget proposal separates 40 full-time personnel from 80 serving on rotation. That brings annual compensation to about 4.15 million G, still almost 89% of the modeled tax revenue before other expenses.
Part of that compensation can be paid in grain, but grain still has a cost. The surrounding countryside and the lord’s estates need their own accounts too. I can’t count them as extra funding without also accounting for what they produce and contribute.
The setting already includes royal support having stopped three years ago. The model helps me work through what that means for the town’s finances.
Inside the game, the economy is smaller and more concrete. Daily processing already connects NPC work, production, food purchases, debt repayments, and shipments to market stock and funds.
Wheat, bread, and bandages use this system. Other goods still use simpler restocking rules, so there isn’t a complete production chain for every item.
NPC customers have persistent wallets and inventories. A cash purchase reduces the customer’s money. A credit sale creates a debt and a player receivable; it doesn’t immediately give the player cash. Repayments come from the NPC’s funds and can only be collected once.
The market also recalculates prices one item at a time during a bulk transaction. Selling twenty items increases stock as the sale proceeds, so you can’t sell the entire batch at the initial price. Purchases work the same way in reverse.
For goods with variable prices, the underlying market price has a floor of 0.4 times the base price and no explicit ceiling. Buying stops when stock runs out. Fixed-price items such as seeds have separate rules.
I’ve written headless tests for cash conservation, inventory changes, save/load consistency, and repeated processing of the same day. There are also checks that advancing several days at once produces the same state as processing them individually. These are the kinds of errors I want to catch before judging whether the economy feels good to play.
The NPC numbers need some explanation. I have a generated pool of 1,000 named NPCs for the wider world, but they aren’t all walking around the town.
The current economic data contains 689 profiles, with the selected player character excluded when a new game starts. Daily market activity uses a rotating sample of up to four NPCs per region. That’s separate from the smaller cast of named characters who physically follow schedules in the 3D town.
Those characters have work locations, patrol routes, and trips home. Their movement uses pathfinding and local avoidance. Going home currently means walking to a home destination and then being hidden outside; it doesn’t include a full indoor sleeping routine.
Keeping those layers separate lets me work on persistent customers and debts without putting hundreds of moving characters into a small market.
The prototype is free on itch.io, for Windows and macOS, in English and Korean. It’s still rough. If you try it, I’d like to know where you stopped playing and whether you’d come back.
I used AI tools for parts of the assets and code. The design, economy systems, NPC structure, and scenarios are my own work.
For anyone who’s built something similar: how did you connect a broad economic model to a much smaller playable market? I’m especially interested in how you chose the scale of NPC demand and trade volumes once players could buy up stock or sell large quantities into it.
