Hello and welcome to the 19th development diary of Grey Eminence!

Today, we’re continuing the series of dev diaries dedicated to trade. In the previous edition, we gave a high-level overview of the structure of the trade system (markets and infrastructure) - now, we’ll explore two of the most important processes within the system, pricing and transactions.


At any time within a single market, each good has a particular price - determined by the previous monthly iteration of that market (so pricing updates monthly, same as logistics). This price drives the behavior of all economic actors within that market for the next iteration - and that behavior in turn impacts the price for the iteration after that.

So, how exactly is the price of a good calculated? We mentioned before that it’s primarily driven by supply and demand, represented by production and consumption respectively in each market. The more a given market produces a good compared to consuming it, the lower its price will be (and vice versa), which sounds pretty straightforward and it is.

However, since markets are interconnected and form larger long-distance trade routes (especially in the first half of the game, prior to railroads unlocking multi-province markets), the pricing formula also considers imports and exports. This helps us solve the problem of linking a source of goods to a distant sink that might be multiple market connections away: without considering imports and exports, intermediary markets wouldn’t be able to adequately move goods along the chain without first building up massive stockpiles.

The exact parameters of the pricing formula are still subject to change, but at its core it’s essentially the base price (which is static per good depending on its supply chain complexity) multiplied by a ratio of the difference between production+imports and consumption+exports. As an example (with non-final variables), if a good has a base price of 1, but its consumption+exports outpaces production+imports by a factor of 5, the final price in that market will be 5.

There are a couple of balancing mechanisms we’ve added to the pricing mechanism to make it more resilient to major fluctuations and shocks: for any given iteration, the new price is clamped to be within +/-50% of the old one. Of course, this won’t prevent price spikes due to genuine shortages, but it does provide just enough leeway to smooth out minor disruptions caused by temporary issues such as re-routing of goods flow due to embargoes.


Fundamentally, the pricing system exists to enable transactions - between the merchants of a given market and their suppliers/customers, or between the merchants of two connected markets. These transactions move goods around and facilitate the entire economic process of the game, so they’re an important process to get right. Note that we’ve gone through multiple iterations of the transaction system - and the one described above might not be the final one - but we’re confident that we’ve arrived at a pretty satisfactory solution overall.

Let’s start by covering local transactions - those that occur within a market between its merchants and either suppliers or customers. As we confirmed previously, each market has its own stockpile for each good. This stockpile is owned by the merchants of that particular market (in the case of multi-province markets, the stockpile is considered to be owned jointly by all merchants in the market’s constituent provinces). Whenever a building produces goods, it immediately sells those goods to its local market’s stockpile. Similarly, whenever a population (or building, or character) consumes goods, it buys them from its local market’s stockpile.

Thus, local transactions always occur via the merchants, who serve as permanent middlemen by design. Due to their omnipresence, merchants cannot refuse local transactions - they’ll always buy/sell from/to local producers/consumers at the current market price. As compensation for their inability to consent, we’ve added a slight markup to the price of all local transactions in favor of the merchants. This ensures that they’ll always have a small baseline level of profit, which ensures that local economies (particularly subsistence ones, which predominate in 1356) can run smoothly. While the markup is currently fixed (and, as usual, is subject to change), we’re planning on linking it to one of a country's economic laws, but that’s a topic for another time.

Now we’ll continue on to external transactions, which occur between two connected markets. Here we’ll find significantly more consent than in local transactions - in fact, external transactions are always voluntary and are always driven by profit. During each iteration of the trade system, each market scans connected markets looking for profitable import trades (accounting for transport costs, tariffs and so on). Similarly to the partial fulfillment we utilize in consumption/production, once all such import requests are aggregated, they’re fulfilled entirely (if stockpiles permit) or partially in proportion to their size (if stockpiles are insufficient). Crucially, it is the importer who pays all initial costs - and thus takes on the risk of his stockpile being less valuable in future iterations of the trade system.

This relatively simple (and purely local/neighbor-aware) behavior allows for the organic emergence of long-distance trade routes spanning dozens of markets. At each step along the way, local merchants import goods at a profit, without ever being aware of any information beyond their immediate surroundings. Of course, this does mean that changes in supply/demand take time to propagate across the network and re-routes require a radial propagation across all connections (rather than magically knowing the next-best optimal path after the one that just closed), but nevertheless the system produces surprisingly realistic outcomes considering its input data.


That’s all this time around! We’re continuing to work on getting the closed alpha ready, but due to our limited funding we’re doing so at a reduced pace. Considering the current speed of development, we feel that it’s safe to rule out a 2023 release for the game - though we remain optimistic that with time our community will grow to the point where we can reasonably finish the game without external financing. In addition, we’re also once again temporarily suspending the release of new dev diaries - our top priority is the closed alpha and we need to concentrate 100% of our resources on it.

Thank you for reading and for your unwavering support through these challenging times! As always, we’ll be happy to answer any questions and to chat in our Discord[discord.com] - and you should also make sure to join our Subreddit, and to follow us on YouTube, Facebook[www.facebook.com], Twitter, and our website[www.nestinars.com].

Hello and welcome to the 18th development diary of Grey Eminence!

In today’s edition, we’ll be taking a look at one of the most anticipated mechanics in the game, trade. It is the crown jewel of Grey Eminence’s economic simulation - a process that transforms an otherwise static world of disparate populations and goods into a massive, interconnected network that ebbs and flows like a living organism.


The fundamental unit of the trade system is the market - by default, a market is composed of all tiles owned by a country in a single geographic province. Those of you who have read our previous dev diaries will notice that this is the same definition as the one we’ve used for political provinces - and that’s exactly right, in 1356 markets and (political) provinces are one and the same.

Each market has a market capital from which all its connections originate (more on that later) and a stockpile of every trade good in the game - including of goods that cannot be produced locally. Once per month, each market resolves the consumption and production requests of its constituent tiles by either drawing from or filling up its stockpile of trade goods. This process happens in two steps:

1. Essential consumption & buildings production
   
2. Discretionary consumption

All requests are fulfilled proportionally. For example, if a single market has 100 food in its stockpile, but its population and buildings request 200 and 300 food respectively, each request will only be fulfilled at 20% (100 / (200+300)). Continuing the example, since there would be no food left in the stockpile, 0% of discretionary food requests would be fulfilled.

By delaying discretionary consumption, we ensure that a population (with enough money) won’t starve or be left without fuel until shortages become so widespread that they affect production as well. Additionally, this also makes production more resilient to sudden spikes in discretionary spending, preventing for example an army returning home with loot from starving its local industry of inputs and breaking supply chains due to their newfound lavishness.

The market UI might look intimidating at first glance, but it gives you all the information you might need to know about what’s going on in a given market - with additional breakdowns on-hover of most numbers. Selecting any particular row in this UI causes the relevant market overlays (e.g. goods price, stockpile size) to display data only for the selected trade good, making it easy to visually navigate through the local and global economy. We’ve made numerous revisions to this UI and will likely continue iterating upon it in the future, so the design isn’t final.


Of course, the raison d'etre of markets isn’t merely to match supply and demand locally, but rather to resolve local imbalances by importing or exporting goods from other markets they have a connection with in order to turn a profit. This is where logistics comes in: while we assume that all tiles within a single market can function as a single economic unit (at least on the order of a single month), different markets require a connection in order to trade with each other.

The most basic type of connection - and the only one we’ll cover today - is overland trade. This connection is automatically established between a market and all its neighbors. For each such connection, the fastest path between each market capital is used - notably, the path accounts for terrain, climate and infrastructure, so it might not be the geographically-shortest one.

Infrastructure is one of the main ways you can interact with the logistics system - building up roads allows you to direct the path through which trade will flow (which you’ll definitely want to keep out of enemy hands). Additionally, infrastructure greatly reduces the transport costs for moving goods, which makes trade more efficient and more profitable. Our design departs from other grand strategy games, since we do not artificially limit the volume of trade that can flow through a connection due to its infrastructure - instead, we rely on the profit formula to balance what amount of goods are profitable to move in a single month. For example, a player-led Russia might try to build up its eastern frontiers centuries before the invention of railroads, but such an endeavor would require exceptional profit margins to make carting tons of goods across Eurasia by horse profitable.

Speaking of railroads, they provide a unique mechanic that changes the way markets are structured: any of your neighboring provinces connected by railroad automatically become part of a single unified market. Thus, once you unlock railroads and start building them, you can create arbitrarily-large overland markets, greatly simplifying your internal logistics. Going back to our previous example with Russia, even with roads stretching from Moscow to Vladivostok, goods would take as many months to flow from one city to the other as there are provinces between them (since each iteration of the overland trade system moves goods only between neighboring markets). A railroad connection would not only reduce transport costs significantly, but would also make all constituent provinces part of the same market, allowing goods to move from Vladivostok to Moscow in a single month.

The current logistics overlay has lots of room for improvement. Currently, all connections are drawn the same - in the future, we’ll scale the width of a connection’s line to the volume of trade going through it, while its color will signify the level of infrastructure (none/roads/railroads) it has.


A logistics-based trade system would be incomplete without realistic goods pricing to drive it - after all, it is price that determines profit, and it is profit that spurs the movement of goods. We won’t get into the minutiae of the pricing formula and the actors that are involved in it (that may or may not be the subject of another trade-related dev diary), but for now we can confirm that the price of goods in each market is determined primarily (but not exclusively!) by their supply and demand. Not a shocker, we know, but we felt it’s worth putting that in writing.


Thus far, we’ve ensured to create each system included in the base game with system-level moddability built-in and trade is no exception. As one of the most interconnected systems in the game, editing how the processes connect to other game systems will require precision, but is doable. And, of course, content-level changes like adding new goods or adjusting trade-related variables like transport costs can be done inside the world editor.

However, going forward, we’ll unfortunately have to reduce the system-level moddability with which we’re building Grey Eminence’s systems. Adding such features increases the development time by at least a factor of 2 - and while we’re proud of the reception our recent alpha gameplay trailer received and are immensely grateful for your continued support, we won’t be able to maintain an acceptable development pace with our current resources without reducing the dev time we spend on moddability. That said, this doesn’t mean systems will be fully hardcoded going forward - you can always disable what we’ve built and implement something yourselves using our usual modding paradigm. Obviously, it’ll be more difficult than modding existing systems that were built with moddability in mind, but it’s still a possibility.

Thank you for reading! Rest assured, we’re working hard to get the closed alpha ready as soon as possible. While it’s still too early to give any specific date (since, after all, our resources are always in flux), we’re hopeful that it won’t be too far into the future. In the meantime, you can look forward to the next dev diary on April 1 (no bamboozle, that’s just how the dates lined up) and you should make sure to join our Discord[discord.com] and Subreddit, and to follow us on YouTube, Facebook[www.facebook.com], Twitter, and our website[www.nestinars.com].