Michi (molp)

In devlog #535 I announced that we are looking into implementing dynamic market makers. Today I want to show you what we have so far.

So, to recap, the status quo is that we have around ten static market makers that have both an ask and a bid order placed. I tend to call them MMs with closed brackets. The commodities are basic consumables, basic prefabs, fuels and mineral construction granulate. Since these commodities are essential for all players and especially for new players these market makers have two goals: provide unlimited sell orders, so new players will always be able to buy these commodities at any given time. On the other hand they also provide unlimited buy orders so that new players actually can find a buyer for the items they produce.

Then there are the what I call open bracket market makers. There are 56 of them and they all just have the unlimited buy order. They can be found in many material categories, from basic stuff like ores and agricultural products to high-end categories like drones, energy and electronic systems. Their purpose is two-fold: for one, they provide means for new players to sell their products and be able to make money, just like the closed bracket MMs. Secondly, the MMs for high-end products provide a money faucet where new money is introduced into the economy and also encourage some players to build the necessary production chains and run the logistics to build these items.

Since the economy is inflationary for the most part, it happens every once in a while that the upper bracket of a market maker is reached. Usually that means that no one is producing the commodities anymore, because the margins get razor thin. There is no more room to increase the prices to cover production costs. In the past we adjusted these MMs manually. Note that these adjustments are global, for all MMs of this type, no matter the faction/currency.

Now we want to switch to a system that is more dynamic, both in terms of automatically changing the orders as well as only changing the orders in the currency where the limits are actually reached.

In our opinion the best closed bracket MM is one that players never need. Ideally, they should sit at the edges of the order book and their orders should not get matched on a regular basis. So, with the dynamic we introduce we take the average price of the last 10 days and the average between the upper and the lower bracket. The difference between these two values is how much "pressure" the market maker is subjected to. If the 10-day average price sits close to one of the brackets, the pressure is high; if it sits right in the middle, the pressure is low. We do this comparison every day and depending on how large the pressure is, multiply the upper and lower bracket by a factor. If there is pressure on the upper bracket, this will widen the bracket and also increase it, giving the average price new room. We'll do this until the average price sits back in the middle between the two brackets. To prevent too drastic swings the daily change is limited to 2%.

These changes are already live on the test server, but given the low CX activity, not much is visible yet.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

In devlog #535 I mentioned that I am working on the Dynamic Inflation Adjustments concept. The first step in this concept is to actually visualize the inflation, so we have a proper foundation to base everything else on. We decided to make this data available in an in-game command called INFL. Here is a quick preview of the work in progress:

The chart features two graphs: the inflation index is the yellow line, and its values correspond to the right y-axis. The graph always starts at 100% for the set time interval. The bar chart shows the relative changes from period to period. Values above the center line mark inflationary periods, those below deflationary.

At the top of the chart you can see various settings.

The first one sets the interval and allows you to choose between daily, monthly and yearly. Depending on the selection a series of periods is shown. There is no support for custom periods right now.

The controls in the middle select the currency.

The controls on the right allow you to select a set of materials. "All" will use every material and thus show an overall inflation index. It can also be limited to a selected material or material category. The last option, "basket", has a set of predefined baskets that differ from the material categories. While material categories alone already result in interesting data, the really interesting baskets do not align with material categories. To get started, I added consumable baskets for each type of workforce that contain basic and luxury consumables. There is also a basket for each type of production prefab. The agricultural produce basket contains everything produced in farms.

The command is available on the test server, but there is little data right now to view.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

Summer has us in its grip. Europe is reeling from a heat wave. Thinking is hard in this heat, but we made some progress nonetheless. But before I dive into it, let me remind you that PRO licenses are 15% off until the end of the month! There is not much time left.

In last week's devlog #535 I talked about dynamic inflation adjustments. I did start working on this, but there is nothing to see yet, so I'll postpone that to another devlog.

Instead, I want to quickly highlight what I also worked on this week. If you are a regular reader of the devlogs, you know that I regularly look into performance issues and try to fix them. The release of the last maintenance update uncovered a performance degradation in our data persistence system. That is a bit unusual, so it piqued my interest.

A quick reminder, we don't have a relational data model where entity data is stored in tables in rows, but rather an event-based one. Each "thing" in the game is an entity and for each entity we store a stream of events that alter its state. We do regular snapshots every 10k events, which greatly helps with restoring the state from the database. Only the events after a snapshot have to be applied to get to the current state.

The current universe is now 1952 days old. In the past, if we have been generous with the size or number of events, it hasn't been a problem. Now, some entities have collected so many events that the database runs into issues. The pacemaker is a prime example. The pacemaker is a central entity in the system that reminds entities to check if they need to update their state. If a company starts a new production order for example, the production behavior goes through the list of all production orders, finds the one which will finish next and sends a simple message to the pacemaker: wake me up once we reach this specific timestamp. The pacemaker persists these "ticks", as we call them. It now has well over 720 million of them. The pacemaker also uses snapshots, but I noticed that sometimes they would not be persisted. That was an easy fix, but the events themselves, even the ones before a successful snapshot, are not deleted. The main reason for that is that, if we ever introduce an update that renders the snapshots invalid, we can simply ignore the snapshot and restore the entity from the full event stream. If we had deleted the events, that would not be possible and fixing such an issue sounds like a nightmare.

Now we reached the point where we cannot ignore having millions of events for a single entity anymore. So we decided to implement a new system that not only keeps the latest snapshot, but also every snapshot in a retention window of 10 days. Every event before the oldest snapshot gets deleted, creating some breathing room for the database. In case we run into an issue, we can fall back on an older snapshot. In the beginning we will not roll this out to every type of entity, but only a few selected ones, like the pacemaker. The change is deployed on the test server and I am currently monitoring if we run into any issues.

I admit, that was pretty technical... but sometimes game development is just that. Thanks for reading if you made it that far :D

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

On Wednesday we shipped maintenance release 2026.06. As usual, you can find the full release notes in the forums. Here are the major changes:

Screen variables is a new feature that allows you to define a set of typed variables per screen. This can be used to build dynamic screen setups: for example, one could build a commodity exchange screen that has the order book, chart, order mask etc. Changing the commodity variable would change the contents of each command simultaneously.

We also added post-tutorial contracts. New players joining after the release date will receive another set of contracts that help them work towards a second base.

The PROD command was overhauled and now gives a way better overview of your production lines.

The update itself didn't go as smoothly as I expected this time. A few database performance issues surfaced, impacting the overall performance of the game. I have identified at least two separate issues that I want to address in the coming week. So far the game is stable and playable, but improvements have to be made.

I also looked into a concept document Fabian wrote a while ago, called Dynamic Inflation Adjustments. As many of you have stated countless times, having static values for the market maker bids and asks, which can only be updated manually, might not be the best option going forward. We are now looking into more dynamic options. The document basically has two parts.

The first one is about measuring inflation and visualizing it. This will be the foundation the dynamic part is based on. We might even make this data available in-game, we run an economic simulation after all. I take it many players would be interested in that.

The second part is about adjusting three things dynamically: the market maker orders, the faction contract rewards and the starting capital for new companies.

As usual, I will go into the details once I start with the implementation. I just wanted to leave this as a heads-up on what's coming.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

A quick update from Martin on the supporter packages: The ones that have tracking links have almost all arrived at their destinations. A few are still in US customs (looking at you FedEx). We are still working on getting the necessary buerocratic puzzle pieces into place to be able to send packages to the United Kingdom. Fingers crossed.

Martin also updated the perks page. It now shows the status of the perks and helpful links.

A while ago there has been a discussion in the forums about alternative Sodium recipes and other adjustments. Fabian got to work and added a few alternative metallurgy recipes that involve Sodium. They will be part of the upcoming maintenance release. Thank you very much for the suggestions!

I spent most of my week on a new feature that will make it into the maintenance update as well: screen variables.

This PRO-feature allows to define variables of various types per screen. The variables can be used in commands. Each variable has a selector that allows to quickly change its value and thus also the commands it is used in.

This can be used to build dynamic screen setups: For example one could build a commodity exchange screen that has the order book, chart and order mask etc. Changing the commodity variable would change the contents of each command simultaneously. Here is a quick example, as a video says more than a thousand words ;)

A variables can be referenced in a command by putting its name between % characters. Right now there are four types of variables:

• string: holds a string
• material: selects a material using the default material selector
• commodity exchange: selects a commodity exchange code
• location: uses the default location selector to select the natural id of a location

Many commands work with these variable types, but I already found a few commands that do not. The workforce command WF for example expects an id and doesn't work with the location, like the base command BS for example. If you find more, please tell me!

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Japanese has long been one of the most requested languages from our players, and seeing it come to life is a real milestone for us.

Prosperous Universe is supported in a growing number of languages beyond those we officially maintain, and that's only possible because of the players who generously give their time and expertise. Translating a game as detailed as ours is no small task. It takes a deep understanding of both the language and the mechanics, plus the patience to get every term just right.

To everyone who contributed: thank you. Your work opens the door for a whole new group of players to explore the game, build their companies, and take part in our player-driven economy.

If you spot anything that could be improved, or if you'd like to help translate Prosperous Universe into your own language, we'd love to hear from you. Our translation community is always open to new members, and every contribution makes the game more welcoming for players around the world.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Martin

Last time I made an appearance in an issue of the devlog was in week 529 and the topics are exactly the same. So let me cover the key points in the same order, too:

Firstly, I implemented exclusive download access for digital perks. Since last Thursday, supporters at the Galaxy tier and above should see a download button on the perk info page that allows them to download the secret soundtrack uncompressed and in high definition. As stated in issue #529, everyone else will be able to stream the soundtrack on all the usual platforms starting September 1st.

Secondly, Michi and I got together at simulogics HQ to pack and ship the 80 to 90 packages of the final batch of physical perks. Even though we upgraded our setup from "manually fighting the DHL online store" to "hacking together scripts talking to a shipping SaaS's API", this process did come with a few of challenges:

1. Needless to say, the...uhm..."change in policy style" in the US made shipping there incredibly more complicated and costly compared to last time. Apologies to anyone for whom this is causing trouble on your end. We tried our best to get everything in order, but it's a bit of a gamble and we can't really do much about the import fees charged by UPS/FedEx. Kudos to the people at the FDA helpdesk I had to call Friday night, though: They were really friendly and helpful ;-)
2. Apology number two goes out to our backers from the UK: Brexit means we get the worst of both worlds in that there are now customs checks (and duties) and EU-style bureaucracy. While the packages are ready, I'll have to apply for a UK VAT and EORI number before I can label and ship them...
3. We did actually run out of inventory towards the end of packing boxes because yours truly apparently has difficulty counting. For the less important items we packed a replacement instead. For the bigger ones Michi and I will be in touch with the affected supporters soon to discuss options. So...apology number three, I guess?

Anyway, I am glad this chapter will be closed soon. And finger's crossed I won't receive too many additional emails from customs agencies around the world!

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

I just came back from a vacation, so naturally this will be a short devlog. Nonetheless, there is something to report:

In the days before the vacation I have been implementing a small feature that is originally from the faction influence game design document. It was a self-contained feature with a small scope, so I decided to implement it anyway, although I am currently working on the upcoming maintenance release: faction com channels. There will be four new communication channels, one for each faction. Players will be joined automatically to the channel of their respective faction. The channels cannot be left, as they are auto-assigned, but they can be muted. The feature is available on the test server as a preview.

In my absence Fabian came up with a few additional recipes for RE and WHR that will make it in the maintenance release as well. The rationale behind the new recipes is to add new sinks for these materials, as the current ones are limited and mostly only for gateway related materials.

And, of course, there is a new economic report:

Click the image for the full report

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

After the recent election turmoils, multi-accounting and exploits, I was looking forward to do some "regular" development. Our backlog has quite a few bugs and quality of life entries that we want to release in an upcoming maintenance release. I created a topic on the forums for it.

One of the quality of life improvements is the overhaul of production overview command PROD. Right now it just shows a simple list of all the bases and their production lines. Taking heavy inspiration from refined PrUn, this is what it will look like:

The basic structure stays: It is a list of all bases, but the individual production lines show more information. The efficiency column helps to find production lines that run suboptimally, for example due to missing workforce consumables or other production efficiency factors. The slot column color codes how many slots of a production line have an active order. Green indicates that the production line runs at full capacity, yellow that at least one slot is unused, and red if there is no active production order. The last column has links to show the individual production line or the order management.

The production lines of a base can be collapsed into a single row, especially handy for players with a lot of bases.

Another helpful tool is a new toggle in the SFC command that allows to enable and disable the 'unload on arrival' flag, even during flight! This will be a PRO feature, as the underlying 'unload on arrival' is PRO as well.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

What a week! While investigating a potential multi-account issue with over 10 alt-accounts on Monday afternoon, I noticed that one of the alt accounts had managed to accumulate copious amounts of slower than light fuel in one of their ships' tanks. Since this should not be possible and I had confirmed the multi-account, I deleted all of these accounts. I then went on to find the root cause. After staring at the code for a while I realized that it was possible to create almost infinite amounts of SF fuel using the mechanism that allows transferring multiple materials. I quickly patched the issue and called it a day, since it was already getting late.

Shortly after I left the office I got pinged on Discord about suspicious activity on the Antares SF market. A player was buying and selling enormous amounts of fuel. I suspected that this was another alt-account which created the SF fuel before I patched the issue, but the respective company was just a few minutes old, so there was no way they could have obtained that amount of fuel. So, back to the office, I quickly deleted the account to prevent further abuse. I also started looking into other potential exploits, but wasn't able to find anything.

On Tuesday I didn't have too much time, due to some private appointments. That didn't stop the attacker though and I deleted another account. In the evening I sat down again to find the second exploit. Unfortunately I wasn't able to find it in time. In the early morning hours, while I was not yet in the office, another attack occurred. The attacker not only attacked the SF market, but also used the money to empty other commodity exchange books as well. After deleting that account I kept a close eye on company creations to prevent further damage, while I went through the event stream in the database of the previous attack trying to figure out the exact attack vector. After a while I struck gold and managed to replicate the attack. I won't go into the technical details, but it involved ship flights, which is why it took me a while to find and also why new companies without any PRO status, contracts, LM ads or anything like that were able to use the exploit.

After patching the second exploit we haven't had a similar attack since.

So what is the damage? The biggest outcome is that the SF market maker has created roughly 10 billion AIC during the attacks.

Not all of that has been added to the economy though: Since we deleted the accounts their funds left the game with them. The increase in money supply is visible, but not as dramatic as we anticipated:

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Martin

Hello, it's me, Martin! Whenever I show up in the devlog these days, it's usually about matters unrelated to the development of the game. And this time is no different: I am just popping in to let you know that there's some progress on perk fulfilment:

Firstly, Julian has wrapped up the "Secret Soundtrack" that's a perk of the Galaxy tier and above. Supporters will get download access to the original high-quality audio files. Everyone else will be able to listen to the ten tracks on pretty much all the usual streaming platforms. For now, the public release is pencilled in for the 1st of September. Exclusive download access will be available as soon as I have implemented...well...exclusive download access. Hopefully over the course of the coming weeks.

And secondly, the final batch of physical perks has been sitting in my office for a few weeks now and is waiting to get packaged and shipped. I dread the latter part, as it's become a serious pain to ship things to the US where most of our supporters are located. I am still in the process of figuring out how to do this in a way that causes as little friction as possible. As soon as I got a plan, Michi and I will likely meet up at simulogics HQ to finally wrap up this chapter, tentatively scheduled for "before the end of Q2".

Michi (molp)

After the previous two weeks' election turmoil (see #527 and #528), we decided to change the voting system to approval voting. In an election with this system, every voter can vote for as many candidates as they approve of. In the end, the candidates with the most votes will get into parliament.

Why the change? In the previous system with only one vote per voter, players needed to cooperate and plan a lot to get as many of their favorite candidates as possible into parliament. If everyone voted for last term's governor because they did a good job, that would allow other parties to enter parliament with a relatively low vote count. That is exactly the opposite of the desired behavior of many voters. With approval voting, the voter can vote for a set of candidates instead. Of course, given that we now hide the vote count during elections, this system also has its downsides: It is rather difficult to know who is going to be governor after the election. So far we have received more positive than negative feedback about the change.

I also added a new alert that reminds inhabitants of the upcoming election end 24 hours in advance. It seems to help quite a bit with voter turnout, but that might also be an effect of the whole Promitor election debacle and might fade.

Here is the latest economic report:

Click the image for the full report

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

I spent a lot of my available time this week dealing with the aftermath of the recent election on Promitor. See devlog #527 for context.

The first step was retrieving and looking into the actual voting data for Promitor’s term 67. We then aggregated the voter and candidate data with data from other systems we have, like account and payment data. It became obvious that there are many accounts that didn’t show any activity other than voting. All these accounts had in common that they had been created recently, had almost no progress in the game and very low activity ratings. The suspicion grew that these have been created for the single purpose of voting. To visualize the impact, I created the following graph:

We then decided that these accounts are definitely in conflict with our ToS and deleted them. Since two elected candidates had no votes left, we removed them from the parliament, effectively reducing it from five to three seats. That shifted the balance of power, and the taxes and fees were quickly reset to pre-election values.

I posted about these developments on April 23rd to give a heads-up and also to show that we are taking the issue seriously and are looking into it.

After that we received a lot of feedback, messages in the forums and on Discord, which we are very thankful for.

One of the most controversial topics that have been discussed is why we didn’t ban Euu, Tnn, and yfj911 outright. After all, it seems as if they orchestrated these accounts. While we do have our own opinions on that, we were unable to link the group to the creation and usage of these puppet accounts with absolute certainty. If we had banned them, we would create a dangerous precedent, where anyone could create a few fake accounts, let them vote for the political opponent and then have that opponent be banned by us.

Instead, we want to take a different approach and improve the election system to make it less vulnerable to election sniping. A small first step is to hide the current vote count during the election. That makes it harder to estimate how many votes are required to turn an election. But that also goes for everyone else. If the goal is to get as many candidates into office as possible, players would have to spread their votes across a range of candidates. While this might be justified for heavily contested elections like the recent one, it shouldn’t be something players have to do all the time. Instead, we want to change the voting system to “approval voting”: This basically means that a player can vote for as many candidates as they like, e.g. everyone they approve of. The x candidates with the most votes will then make it into parliament. I will look into this change in the coming week. We are also thinking about adding an additional notification a day before an election ends to increase voter turnout. Additionally, we want to increase the parliament size for planets with very large populations from five to seven MPs, as the planets have grown quite a bit since the introduction of the politics feature.

To be crystal clear about the rules regarding puppet accounts, we added a new section to the rules called “No puppet accounts”:

Players may not create, use, or arrange for others to create accounts that exist solely or primarily to serve another player or group. Typical examples include accounts set up mainly to vote for a specific candidate or to channel resources to one player or a group of players.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

I don't recall a day in recent years when I woke up to 15+ private message requests on Discord. Obviously, something was going on. After checking the servers were doing fine, I started reading. If you have been out of the loop or haven't read Discord over the last 48 hours, here is what happened:

The election on Promitor ended two days ago with members of the 琉璃主权资本 (FOXV) corporations winning a majority of 3 out of 5 seats. Almost immediately, the new government raised production taxes across all industries to the allowed maximum. Also, 25 million ICA were transferred from the government's account to the governor's private account.

To affected players, these actions were completely unexpected, as they were not mentioned in any of FOXW's campaigning. Also, I received many messages claiming that throw-away accounts (or multi-accounts) equipped with gifted PRO time might have been used to interfere with the election. At this time we can neither confirm nor deny these accusations.

Assuming there weren’t any rule violations in play, taking over a planetary government in an election and changing the rules is within the limits of the game's rules. As is the withdrawal of government funds. Under regular circumstances, we consider this emergent gameplay and see it as a desirable part of PrUn’s non-combative gameplay.

At the same time, we haven't seen a switch of power and a change in policy of this scale before. Critics have voiced their opinion that the players (especially the inhabitants of Promitor) currently do not have any option other than waiting for a new election and lobbying for change. There is no 'vote of no confidence' or re-elections in the game yet. We will use this experience as well as the feedback we have received from both supporters and critics of the current system to further refine the political features of PrUn in the future. Also note that more political features are planned in general, such that eventually, a “withdraw funds” motion might not be required anymore, for example.

Last but not least, one more clarification concerning the accusations of using multi-accounts / throw-away accounts to interfere with the election: If they were confirmed, these actions would be in clear violation of the guidelines and our terms of service. We started an investigation with the goal of finding out whether the election was interfered with. If we find clear signs of illegal behavior, we will take action accordingly. Please allow us some time to collect and analyze the evidence.

On to the regular devlog topics: last week I continued the implementation of the post-tutorial contracts. Below you'll see examples of what these contracts might look like, and the motivation behind them.

This contract introduces the faction contract offers and asks the players to fulfill at least three of them. We believe faction contracts can offer additional income and keep new players busy. They'll interact with PrUn more often and get to know it and its interface better.

The 'buy consumables' contract serves as a reminder that buying goods from the commodity exchanges, especially consumables, is something that most players do regularly.

The next contract requires the players to demonstrate that they can earn money. Commodity exchange sales, contract payouts and income from shipping contracts all count towards the 25k goal.

Having a satisfied workforce supplied with the necessary luxury consumables can be the deciding factor for turning a profit. We think it is important for players to know about this feature going forward.

This contract is not really a meaningful contract at all. It is rather meant for the players to think about where and how they want to expand their company. Given the countless options for a second base, we cannot create a set of contract conditions that direct the players. Instead, we simply add a condition to wait for some time (24h) and give them instructions on how to proceed finding a good spot. Please note that the blue texts in the preamble are links that will open the respective commands.

The last contract in the series will provide the necessary materials to start a new base. Since we don't know where the players will settle, this doesn't include the additional building materials required for planets with extreme environmental conditions. We are currently thinking about replacing the individual materials with a single core module kit, to prevent potential abuse of these starting materials.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

In the last devlog #525 I mentioned that I want to tackle a stability issue that was introduced with the deployment of the influence report. I am happy to announce that the servers are stable again! No more nightly restarts of individual servers or the whole cluster. I now stagger the influence transfers over half an hour. First are the companies, transferring their influence to the planets, then the planets to their respective systems, and once in a while the systems transfer influence to the factions. Now that this issue is resolved, I can finally concentrate on other things.

As you might recall from devlog #524 we are investing some design and development time into the new player experience. I am now working on the post-tutorial contract series, here is what I wrote in #524:

The post-tutorial contract series continues where the existing introductory contracts from the faction officials end. The goal is to guide the player to establish a second base. We want to achieve that by offering contracts that dive a bit deeper into the game mechanics that are relevant during early game: building construction, fulfilling faction contracts, ...

The first contract in the series reminds the player that they should keep scaling up their base. It looks like this right now:

The contract will be immediately available after the trade tutorial and the accompanying contract have been fulfilled. The following contract is all about faction contract offers, and it'll require fulfilling three of these offered contracts. This means that the faction contract offers will, starting with this contract, now be received in parallel to the post-tutorial contracts. Before the post-tutorial contracts, the factions started sending offers as soon as the last introductory contract was fulfilled. Implementing this required a bit of work, as this parallelism wasn't supposed to happen in the original implementation.

I implemented a cut-off time as well: companies that have been founded before the cut-off time will not receive the new post-tutorial contracts. The cut-off time will essentially be the release date of the new contracts.

All in all, there are seven post-tutorial contracts, and with the initial setup out of the way, I hope that the implementation of the rest will go quicker.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

It has been a short week, I had a few days off over Easter, and yesterday was a public holiday here in Germany. Nonetheless, at least a short devlog is in order.

Hard to believe, but the first quarter of the year already lies in the past. Time really flies, as they say. Here is the third economic report of 2026:

Click the image for the full report

A while ago I deployed the faction generation to production (also see devlog #521). It is not visible for players yet, but we want to collect some data first to refine the game design and get a feel for the numbers. We have an internal reporting tool that can generate faction influence reports of all planets, systems and factions. This is what Fabian primarily uses to improve the game design. This week I added a few more fields to the report and some aggregated values that Fabian requested.

Unfortunately, transferring the influence from companies -> planets -> systems -> factions has lead to some server instabilities that I have yet to solve fully. In the first implementation the influence was transferred every day right before midnight. It seems that naive implementation was a bit too much to handle for the servers, and after a while they restarted, kicking everyone out of the game in the process. I decided to stagger the influence transfers on each level over half an hour. That did help a bit, but the real culprit was a sync mechanism that tried to update all connected clients every time a new influence value arrived. Imagine a planet like Promitor for example, that has more than 2000 bases. Around the same time all of these bases send their daily influence update to the planet, and the planet would update everyone that subscribed to Promitor updates for each of these updates. That gets out of hand pretty quickly. It is better now with the staggering, but I still want to disable the automatic update and only send one update once the influence transfer is complete. I plan to implement and deploy that later this week.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

We are currently looking into how to improve the new player experience. One point of criticism that we often hear is that the tutorial is too short and doesn't explain in detail how the game works. After the tutorial is over, it can feel like being thrown in at the deep end, with only a slight hint on how to continue from this point on.

To improve the situation, we are currently working on three things: a post-tutorial contract series, improvements to the existing tutorial and a new tutorial that takes place before the company creation.

The post-tutorial contract series continues where the existing introductory contracts from the faction officials end. The goal is to guide the player to establish a second base. We want to achieve that by offering contracts that dive a bit deeper into the game mechanics that are relevant during early game: building construction, fulfilling faction contracts, buying consumables, making money and managing the base. The final contract will provide some of the building materials for a second base. We also hope to increase the player retention by giving the players more to work with during the slower early game. The contracts have been designed by Fabian and I hope to be able to implement them soon.

Fabian is also working on a new tutorial that takes place before the founding of the company. Right now the situation is a typical chicken-egg problem: To found your first company, you have to know at least a bit about the game already to make a good decision. Over time, we changed the layout and information being displayed on the company creation screen so many times to improve this, but the underlying problem stays the same. The option to liquidate and start over with the newly acquired knowledge is there, but it has to be discovered by the players, or mentioned by other players. The community is very helpful here, but not all players want to interact with other players. The new tutorial is designed to show new players what the game is about, how the core mechanics work and what to expect. Fabian is currently researching how other browser games handle this, but given that our target audience is not a casual player, it is challenging to decide how "hand-holdy" the tutorial should be.

This week I implemented three improvements for the existing tutorial. The first one is an extra step during the first tutorial, highlighting the NOTS button in the upper right. We noticed that there are some cases where players didn't know about the notifications and got stuck. Since the post-tutorial contracts, the existing introductory contracts and the regular gameplay make heavy use of notifications, it seems like a good idea to highlight them.

The second change also has to do with notifications. The second introductory contract has a pick-up condition for some additional materials. Since the next introductory contract can only start once the previous is done, it is important that the players fulfill the pick-up condition. It is also important that they learn about these contract conditions. That is why I added a new notification that fires if the player doesn't pick up the materials, e.g. the condition becomes pending.

Finally, in the flight tutorial we mention the commodity exchange station as a good destination for a first flight. The flight screen has the station in a tile and highlights it. The tutorial states that the player should take note of the station code, as they might need it later. Once the tutorial progresses to the SFC command the player is asked to enter the code. At this point we don't show the code anymore, which is not helping.. So I implemented a change that will show the comex code. Implementing this was a bit more work than expected, since the station code is dependent on what faction the player chose and the tutorials didn't provide support for dynamic data so far. I'll deploy these changes later this week.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

While the week before was mainly about identifying performance issues, this week was about fixing them. In the last devlog (#522) I wrote:

The next candidate on the list of potential causes is the way we handle scheduled commands. A command is, simply spoken, an action that the player (or a system of the game) sends to an entity and expects it to do something. An example would be "transfer x units of z from inventory a to b". A scheduled command is an internal command that can be executed right now or in the near future. For example, if we have the segment of a flight, the fleet behavior will schedule a command to end the current flight segment and start the next one, at the time the flight segment ends. The behavior will then get a notification from an internal pacemaker once that time has arrived and can execute that command.

Determining what the next command for an entity is can be costly: we have to go through all behaviors of an entity (ships, contracts, bases, ...) and determine what needs to be updated next. I improved the logging around scheduled commands a lot, and I am sure I will find some performance bottlenecks.

The logging I deployed last week to find the performance bottlenecks revealed that there are two issues:

• There are several behaviors (subcomponents) of the company entities that have rather large execution times
• In some entities the individual behaviors keep below the threshold, but all behaviors added together are taking very long to complete

Since both of these issues are related, I decided to take the time to go through all behaviors of the company entities and to improve the performance of all of them where possible. The idea was that when the individual behaviors get faster and use fewer resources, so does the entity as a whole. Additionally, we can also save some time and resources from a reduced load on the garbage collector.

The worst offenders where the population, workforce and rating behavior, so I started with them first. I implemented a mix of caching strategies for all three. Let's look at the rating behavior because it is the easiest to understand. The rating behavior is simple: it keeps track of the current rating and when it is time to check for the next command, it re-calculates the rating and compares it to the current one. If there is a difference, it schedules a command to update the rating. The calculation of the rating is complex, it considers all relevant contracts, the valuations of these contracts' conditions and finally crunches the numbers to return the rating. Doing this everytime we need the next command is a waste of resources, as the rating rarely changes. Instead, I introduced a flag that marks the rating as dirty, requiring recalculation. There are only a handful of events that will mark a rating as dirty, mostly contract-related. This simple change reduced the load induced by the rating behavior to a fraction, which is a positive. The downside, of course, is that we now have to be extra careful when adding or changing things that should trigger a rating update, as it won't happen automatically anymore.

You might wonder why we didn't implement such a flag from the get-go, and the answer is, because we didn't need to. In the early universe, with way fewer players, it wasn't really a problem to burn a few extra CPU cycles. Our main concern always was memory, but now with additional players and an older, larger universe, the CPU resources became just as important.

While being at it, I also improved the loading times for chat channels and the COM list. They should load quite a bit faster now.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

This week I finished implementing the most important transfers of influence:

• from company to planet
• from planet to system
• from system to faction.

You might remember that the plan was to deploy these changes, see how much influence is being generated and transferred over time and use that information to adjust the influence system (and maybe its game design). Fabian will take care of that, and I can work on other topics in the meantime. We haven't implemented any visible changes for the influence system yet, so don't worry, if you don't notice any changes just yet.

In order for Fabian to retrieve the necessary planet, system and faction data, I implemented a CSV report that can be triggered by an internal tool. I hope that nothing explodes when these reports retrieve the data, as they touch every planet, system, faction and population. That is a lot of entities to speak to in a short time, so fingers crossed.

Remember last week, devlog #521, when I said that I was happy with the recent performance changes because they lead to fewer server pod restarts? In the forums players wrote that the game still feels sluggish and sometimes actions can take several seconds until the green "action succeeded" notification shows? I rarely see such delays, but then again, my company is small compared to what others have built. I decided to dig deeper into this topic. To find performance bottlenecks and then improve it, it is necessary to be able to measure the performance first. That way I can be sure to make the changes in the right spot and actually improve the performance.

My first hunch was that snapshotting could be a cause of the delays. After every few thousand events an entity has written to the database, we create a snapshot of the entity. That allows loading the entity back from the database after a server restarts way faster. During snapshot-taking all actions that are being sent to an entity are stashed for later execution and that would perfectly fit into the problem description I had: players perform several actions, they all seem to hang for a short while and resolve at the same time.

The analysis of the resulting data showed that snapshotting can be slow for larger companies, in some cases it can take up to 1.5 seconds to write a snapshot to the database. Since snapshots are only taken every few thousand events, there has to be something else causing the delays.

The next candidate on the list of potential causes is the way we handle scheduled commands. A command is, simply spoken, an action that the player (or a system of the game) sends to an entity and expects it to do something. An example would be "transfer x units of z from inventory a to b". A scheduled command is an internal command, that can be executed right now or in the near future. For example, if we have the segment of a flight, the fleet behavior will schedule a command to end the current flight segment and start the next one, at the time the flight segment ends. The behavior will then get a notification from an internal system once that time has arrived and can execute that command.

Determining what the next command for an entity is, can be costly: we have to go through all behaviors of an entity (ships, contracts, bases, ..) and determine what needs to be updated next. I improved the logging around scheduled commands a lot, and I am sure I will find some performance bottlenecks. The logging is already deployed, and I should have proper results by next week.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

The work on performance-related issues in the last weeks has paid off: Today I checked the uptime of the Server pods again, and the last server restart has been 11 days ago. A single pod decided to restart 9 days ago. I am pretty happy with the result, as we had almost daily pod restarts only a few weeks ago. It's not perfect though: our logs indicate that some actions still take quite some time to finish, for example, mission calculations sometimes take up to 1-2 seconds. That is not ideal, and we'll continue to improve that in the future. If no breaking performance issues surface, I'll continue working on other topics for now.

This week I continued working on the faction influence (see also devlogs #517 and #519), especially the generation of faction influence. Right now we envision three major sources of influence generation:

Workforce satisfaction: The company's workforce generates a certain amount of influence each day. The generation is dependent on the workforce size, its satisfaction and type. Pioneers will create the least amount of influence, scientists the most. Once a day the generated influence is sent to the planet the base is located on.

Government participation: A player will also generate influence for participation in a government. The amount of influence depends on the type of office (governor / member of parliament) and the size of the governed planet's population. I am currently in the midst of implementing this type of generation. Each company/player can only generate influence for one specific office, and we want to allow players to choose which one it is. We also could generate influence for all offices a player has, but we feel that could potentially lead to players just trying to grab an office for the influence without intention to actually participate in the government. This type of influence is also sent to the planet once a day.

You might be wondering for which faction this influence is being generated, the planet's or the player's? If the planet belongs to a faction, it is always the faction, no matter of the player's own faction affinity. If the planet doesn't belong to a faction, no influence is being generated at all.

Faction contracts: The last type of generated faction influence comes from the faction contracts. The higher the contract's faction reputation, the higher the generated faction influence. This influence is sent directly to the faction that sent the contract. We might allow players later to accept contracts from all factions, not only their starting faction.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!

Michi (molp)

March is here, which not only means that the weather in Germany gets nicer, but also that we have a new monthly economic report for you ;)

Click the image for the full report

This week I looked into the servers' performance once more. I noticed that we were running at almost 90% heap usage. In and of itself, this is not bad per se, but it resulted in frequent runs of the garbage collector, which would use up CPU resources. In order to see if having more head-room regarding the heap would reduce the garbage collector cycles, I added another server to the cluster. It did definitely help with heap usage, but it consumes another critical resource: money. So I took a snapshot of the heap of one of the servers and started looking for potential optimizations. Eventually I found something: Many entities in the game have a reporting behavior that allows us to track game-related events (think company creations, tour completions, ..). We cache some parts of these events, so the database we send these to doesn't receive the same event twice or even multiple times. It turned out that we kept everything, instead of just a few-days worth of events that are necessary for that behavior to work properly. Over time some entities collected a notable number of events :) After deploying a fix and only keeping what is really necessary, the behavior is significantly leaner now.

I was also looking into another performance-related issue: The servers' logs contained a warning from time to time that a message could not be serialized because it exceeded the configured maximum size of a few megabytes. This was a rather odd log message, because usually our messages are rather small. There are a few exceptions, of course, like the message containing the information about all star systems. It took me a while, and two deployments of additional logging, to find the culprit. The CXM command shows commodity information across all commodity exchanges. It has a mandatory commodity ticker parameter and an optional planet parameter. If the planet parameter is specified, an additional column shows the distance from the specified location to the commodity exchange. Instead of not requesting any planet information if the planet parameter is not set, the command tried to acquire the full planet list with the details of ~5000 planets. Not only does it take time to collect that data, but it also creates a lot of garbage along the way that has to be cleaned up, unnecessary additional stress for the garbage collector.

The work on the faction influence foundation is coming along as well, I hope to be able to go into detail on the actual generation in the next devlog.

As always, we'd love to hear what you think: join us on Discord or the forums!

Happy trading!