Growing The Economy

Hello Everyone!

I’m AGM, one of the other developers for Conquer Space, and in this dev diary, I’d like to discuss some of the new changes to the economy we’ve been working on.

City Creation

In between now and the last dev diary the game has received a pretty large change in scope. Instead of playing an advanced empire with FTL technology in control of their homeworld, which is expanding across several procedural generated star systems, players are now playing an earth-based nation, expanding across the solar system.

One of the byproducts of this switch is a lot of the economic systems were trapped in “Dead Code” and had because of this was broken. The main reason for this is that the code that initialised the starting economy was part of the Lua code that generated the starting system. Since this was no longer there, the player effectively started with no economy.

One of the first steps I took was adding in a basic initializer for the current economic state where a data-defined number of cities are randomly added to the surface and have the necessary components and entities to represent their population and industry added.

Markets now exist on the city level but are much more flexible than they were before. Since all they need is a market component attached to an entity, moving them to any level, like planetary or system-wide is much easier.

Types of production

The existing production system had 3 different production models: mining, farming, and your typical “recipe” based production. Each had its own custom UI subwindow on the production screen and had its own custom industry list as well. When it came to logic, only mining was fully implemented and it just spawned n amount of goods which slowly scaled to meet demand. There were a very large number of components associated with this. For example, you had a component for each type of production, and then a component for each resource type’s impact on the global resource stockpile. In additon, there were some

I was largely able to consolidate these into two main components. A production type component that is attached to the production entity and functions as the where of production, and a free-floating “recipe” entity and component that indicates the “what of production. Much of the existing production behaviour could be achieved and the new system supports not only multiple inputs and outputs but also the option for separate modifiers for each input and output. For example, if you wanted to emulate mine, you could simply have a recipe with no dedicated input good. I retained production categories as an enum instead of a component as they are now used exclusively for UI grouping where each production category uses the same tab and window function, but with the production type serving as a filter. Eventually, we’ll move the production type to a JSON file which creates an entity, like recipes so modders can implement custom recipe tags but for now the system is flexible on the logic front which is what’s important.

Resource Ledger

As previous blog posts have mentioned, Resource ledgers were an important part of the economic system. A vast majority of my time working on this update was spent improving the resource ledger system, and they are now a critical component.

They now fully support overloaded math operations with doubles or other resource ledgers which allows for very dense, much more readable, and higher performance. In addition, we added a few functions that can clamp, overwrite, or safely divide unit ledgers to help make ledger logic simpler and more consistent. Now the economic systems code contains all of the program flow, while the resource ledger code contains all of the standardized data processing code. This also means that any optimizations we apply, like say if we found a better way to add two ledgers together, will benefit most of our systems code.

The most important thing is they all now use proper data protection, which the previous implementations largely lacked which makes things much safer to use. For example, if you wanted to implement a PID control loop to control industry size, I think you could do it in about 5 lines of very readable code. An interesting quirk of the system I chose to keep is the system is “left-handed.” This means that A + B does not produce the same result as B + A since the resulting resource ledger only had the keys present in the left resource ledger. This has much better performance and matches the typical use case of the resource ledger.

Consumption

Probably the most interesting thing I worked on for the PR is how pops consumed resources. The existing model only had pops consuming two, hardcoded resources food and consumer goods. Pops would try and buy enough food to meet their needs and if they had money left over they would buy consumer goods.

I decided to go for a simple Keynesian model for consumption.

Consumption is now defined in the JSON instead of being hardcoded. Populations have a minimum amount of each good that they will consume (a, or the autonomous consumption). If they don’t have enough cash, they will go into debt to purchase enough. This way we can better replicate modern, debt-heavy societies and the fact people would rather go into debt than starve to death or become ascetics. As their income rises, their personal consumption of certain goods rises proportionally also rises (b, or their marginal propensity to consume).

To prevent overconsumption we will probably have to implement a third term which functions as a cap for marginal consumption and overall. With these systems we can actually implement something like Vicky styled tiered consumption, with life needs being goods with high autonomous consumption, everyday needs being more marginal propensity focused goods, while luxuries are represented as goods with only marginal consumption and only a small amount of it. We can have pop strata define their consumption as a modifier or pair of modifiers for their minimum and maximum consumption of each good.

This system provides both a good amount of realism compared to the more static consumption systems of other games and a huge amount of flexibility for modders. The final goal is to offer similar levels of quality for the rest of the economic systems.

Hop on the discord to discuss your thoughts, or better yet open a PR. We always need the help.

Discord

Repo

<EOM> AGM-114

tags: dev-diary - economy