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!

Michi (molp)

Unfortunately, the support work I talked about in last week's devlog #518 didn't get much less, but there's at least light at the end of the tunnel. The email situation with Microsoft is not yet resolved. We are waiting for their feedback at the moment. We added a note to the sign-up form, saying to contact us when setting up an account with a Microsoft-related email address. We are still hoping that the block will be removed soon.

The wave of automatic company creations has ebbed down a bit. We still had to remove quite a few accounts, but it was less than last week. If you still see suspicious accounts, please let us know.

The performance update to the leaderboards was successful, but is currently negated by another performance issue with a non-/slow-responding company that I have yet to investigate fully. During the investigation I found something that suspiciously looks like someone trying to snatch a plot on a full planet by trying over and over again until they hit that brief moment where a plot gets free due to a company liquidation. I have yet to confirm the exact details, but given that I saw 10,000+ tries, I can only assume this was automated, which is, of course, not permitted by our ToS.

Besides all that support and performance work, I have been able to start working on the faction influence feature mentioned in devlog #517. As you might know, I sometimes start with the UI part of a new feature. However, given that the goal right now is to evaluate the faction influence generation for another round of balancing and adjustments of the game design document, there won't be much to see for a while. So naturally, I started with the backend work first. I still want to talk about this work in the devlogs, so I'll try my best to shed some light on what we're building:

Right now I am implementing faction influence pools. They are basically a (technical) way to accumulate faction influence points. Planets, systems and the factions themselves will have one. In the end they all collect faction influence points from various sources, but they slightly differ in their behavior. I'll go into the details once I am implementing these behaviors, but here is an overview: The planets' pools collect the faction influence from the players and (more or less) immediately transfer them into the system pool. The systems keep their influence and accumulate it, as they need the influence points to be above a certain threshold for the system to continue to be part of a given faction. At the end of an influence period the influence points up to the threshold are removed, and the rest of the points are being transferred into the respective faction pool. The faction can then use the points to perform motion-like actions. Influence periods are 14 days long and synchronized between all planets, systems and factions.

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

Happy trading!

Michi (molp)

I spent way more time doing support work than I would have liked.

Unfortunately, Microsoft still hasn't unblocked our email provider, and we still cannot send emails to players with Microsoft domains like hotmail.com, outlook.com, live.com and so on. This is especially bad for new players, as new accounts need to confirm their email address with a confirmation code sent to their email.. Some players wrote to our support address, and I sent them the link for the account confirmation in return. The by far larger part of the affected players are the ones that don't get in touch. To reach them, Martin compiles me a list of bounced (not delivered) emails every day or so, and I go through it, looking for emails with the account confirmation link. I then send out the confirmation links manually. Although I can send them out in batch, tt is a cumbersome process that eats away my time, but necessary until we are finally unblocked and the automated systems can take over again.

Then, there is the Promitor/Avalon election drama. From what I've heard, the elections are regarded as historic, as they might shape the policy of the Hortus system and the Insitor region. It seems some interest groups are using unfair (and forbidden) measures to gain votes: We noticed that a few days ago, many new accounts and companies were found with the sole purpose of gaining a voting right in the elections. I deleted them all. Then a second wave of automatically created accounts trickled in over the weekend. A few moments ago we deleted 126 accounts. During the deletion process, votes are deleted as well, so I hope the damage done is minimal. Finally, I received a message that someone offered real money for other players to vote in their interest. I would like to take the opportunity to point out the rules of Prosperous Universe:

• One account per person: This means no account sharing and no multi-accounts. Especially no spam accounts
• Humans only: The creation of the recent spam accounts seems to be automated, we cannot tolerate that
• No real money trading: It is not permitted to pay another player in real-world money for actions they take in the game. That includes voting!

We will continue to delete accounts that don't follow these rules.

The overall performance of the game has been degraded over the last week. I noticed that the leaderboards are at least partially contributing to that. Today I patched them so that they use less memory and perform most of the actions asynchronously, meaning that even if they are slow at times, they don't block other game entities. There is still a larger issue buried inside the code of the leaderboards, but that is a task for another day. I hope today's changes will make the situation at least a bit better.

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

Happy trading!

Michi (molp)

This week saw the release of the recent maintenance update. It went well for the most part, but there was an issue that was promptly pointed out to me that required a hotfix. For a brief time it was possible to send STL-only ships to other systems, even though they don't have the engines for it. I tried to fix it as quickly as possible, as I feared that this bug could potentially strand ships in neighboring systems and create a pile of support work for me. Luckily, I just received one report so far of a ship that was sent out-of-system by accident.

So, what's next? I will now focus on a new feature called Faction Influence. Fabian has written (and rewritten as you'll see in a bit) a game design document for this. In a nutshell: It is about faction-wide politics and allowing factions to spread their influence to more systems than just the existing faction systems.

The work on this started sometime last year, and we presented the idea first to our supporters. Here is a forum topic from September 2025 that explains the concept in detail. It is available for everybody now. We received lots of feedback on the draft and are very happy about that. It showed that the majority of the community dislikes the strong competitive character of it. Fabian took all the feedback and came up with another draft, which you can find here. The main change is that the competitive character has toned down quite a bit. It is still possible to change a systems faction affinity, but there will be no direct, hostile take-overs.

Balancing a feature of this size can be hard to get right on the first try, which is why we are trying a different approach this time. We'll try to release parts of the feature gradually, so we can collect feedback and data to help us guide design and balancing decisions. For example: Faction motions will require money and influence. Influence will be measured in influence points and these will be generated by players of the respective factions. Right now, workforce satisfaction, faction contracts and participation in planetary governments will create these faction influence points (FIPs). I think it would be a good start to implement the generation and collection of FIPs and release it to get an idea how many FIPs will actually be generated. From there we can work on the balancing and at the same time implement other parts of the feature.

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

Happy trading!

New Storage Buildings

We've added four new specialized storage buildings to give you more flexibility in managing your planetary infrastructure:

• STA Auxiliary Storage: +2500t / +2500m³
• STV Volume Storage: +2500t / +7500m³
• STW Weight Storage: +7500t / +2500m³
• STE Expansive Storage: +10000t / +10000m³

Multi-item Transfer

A long-requested feature is here: select multiple materials at once and drag them to another inventory. No more tedious single-item transfers! (More details in the recent devlog #512)

Other Highlights

We've made several tweaks across the board:

• Better company creation UI on smaller screens and more robust screen selection.
• Simplified FX trading by removing the upper half of the matrix (brokers and manual commands still work).
• New player experience improvements: FREE license players can accept custom loans (payout + installments only), 1.5x starting materials, luxury consumables in intro contracts, and faster first production/flight.

Plus a good number of fixes, including better handling of infrastructure upgrades/fuel/upkeep and allowing STL-only ships through gateways.

You can find the full release notes on the forums.

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

Happy trading!

Michi (molp)

Just as last week, the work on the upcoming maintenance release continues. The difference this week is that we plan to release the maintenance update on February 3rd. You can find the updated release notes on the forums.

My work this week has been a mixed bag of bug fixes, release preparation and removing technical debt.

Let's start with the bug fixes: I finally tackled a state-out-of-sync bug that has been there forever. It occurs when you open a commodity exchange price chart for any material, close it again, wait for some time, during which trades happen and open the price chart again. The trades that happened during the time the chart was closed are not visible on the chart. The fix will be available with the maintenance release.

While working on commodity exchange related code, I also changed the implementation of the CXP and CXPO commands' average price field. It wasn't really showing an average but rather the latest price. I changed it to a weighted average that goes back the last 10 days.

In the SFC command, I tried something new: The route preferences when starting a flight are now saved locally in the browser on a per-ship basis. So, if you regularly fly a certain route with one of your ships, you'll get the same route preferences preselected as on the last flight with that ship. I hope that saves a few clicks in mission planning.

The recipe for the upcoming STE storage building has been adjusted as well: it will not require HCBs but rather more ALR and WRH.

Of course, the usual preparation for a release had to be done as well: writing release notes, a Steam news post, integrating the latest translations and so on.

Finally, I was able to remove some technical debt: There was some code that was specifically responsible for loading planet data, and it was still used in a few places. It became obsolete a few years ago when we implemented a data framework that can handle many different types of data (systems, companies, ...) but somehow we forgot to remove this old code. I finally did remove it, and it felt so good :) The little joys of a programmer ;)

We also have an economic report ready for you:

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)

The work on the upcoming maintenance release continues. You can find the release notes on the forums. I'll add more items to the release notes as I implement them.

Similarly to the speed-up of the first production order I talked about last week in devlog #514 I implemented a speed-up for the first flight. The argument is the same: We want new players to see as much as possible of the game during the first game session. The first mission in SFC will have this additional note field:

Over time, we have received many complaints that FX trading is too complex, given that there are two FX broker for every currency pair. For example, you can buy and sell using the CIS/AIC broker, or AIC/CIS. In the real world there is usually only one pair, with the higher ranking currency functioning as base currency. We don't have a ranking system for currencies in the game, so I decided to disable all brokers in the upper half of the FX matrix. Please note that these brokers and currency pairs are not gone, but not accessible at all from the FX command. If you want to delete existing orders or have a look at the order books, you'll have to enter the necessary commands manually.

Other than that I was pretty busy fixing bugs, most of them of rather technical nature. There was one bug, for example, that would prevent any player that was not part of the construction or upgrade of a gateway infrastructure from accessing the upkeep or fuel stores of a gateway if they became a contractor via a fuel or upkeep contract.

I also fixed the GTWT command. It showed an error when no gateway identifier was present. The identifier is now mandatory. Talking about gateway traffic: The counter showing the number of jumps in the last 24h didn't reset at all. This will also be fixed with the upcoming maintenance release.

Some years ago we had a player that accepted any LM ad they could get their hands on, without the intention of fulfilling any contracts at all. To counter that, we introduced a contract limit, preventing other players from doing the same in the future. Some players do run into the contract limit from time to time due to long-running loan contracts. We increased the limit in the past, but really needed a better way to limit the acceptances of LM ads. Instead, I implemented a rate limit for LM ad acceptances, effectively limiting the number of ads that can be accepted in a given time frame. To find the right rate limit, it would be interesting to hear from you how you use the LMs and what the limit should be, so your workflows will not be affected by the limit.

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

Happy trading!

Michi (molp)

This week I continued working on the upcoming maintenance release. You can find the release notes on the forums. I'll add more items to the release notes as I implement them.

The new player experience is something that we want to improve regularly. There have been countless discussions about it, both, in the community and also in the team. For this round of improvements, we focus on a few key elements, as there is not enough dev time to re-invent the early-game. One of the most common complaints we receive from new players (mostly in the form of negative Steam reviews but also on Discord) is that the game feels too slow and that there isn't enough to do in the first few sessions. We totally understand that, but there is only so much we can do about it. If we artificially speed up the game for new players, they'll get used to that speed and might expect the game to stay that way forever. That is why the "grant new players a slowly fading 1000% production efficiency boost" idea is off the table for now. Instead, we want to make use of existing mechanics and apply one or two speed-ups very deliberately.

In the early days of a fresh company the growth can be almost exponential. That exponential growth can feel very slow while still being in the "flat" section of the curve. Every bit that pushes one to the right will make it faster. There are players and corporations from all factions now that offer (free) loans to new players. This is an immense boost for the newbies and also a great way to hook them to the game and let them be part of the community. To make it easier for new players to accept these loans, we decided that players with the FREE license will be able to accept loan contracts from now on, without having a BASIC or PRO license. This will only work for contracts where the FREE player is the borrower and the contract cannot have any other contract conditions than loan installments and loan payouts.

We also want to speed up the early game for players that didn't receive such a loan offer or simply haven't heard about it. I increased the number of initial buildings each profession can build and also added more starting materials. The introductory contracts received from the faction will now also contain a few luxury consumables for increased production output. Although these measures are tiny in comparison to a large loan, every player will be able to use them without any interaction with the existing player base.

Talking about speed-ups: I haven't implemented that yet, but plan to do so the next days: We noticed that a large portion of new players drop out of the game relatively quickly, without finishing the first production order or even the whole tour/tutorial of the game. So the change we have in mind is that the very first production order and the very first flight should be relatively short, only a couple of minutes or so. There will be an extra hint in either the tutorial or maybe even in the PRODCO command. We hope that this change might keep players to stay longer in the (first) game session and thus be able to see the next part of the tutorial and more of the game in general.

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

Happy trading!

Michi (molp)

Quite a few days have passed since the last devlog. There are five operational gateways now, two pairs are up and running and providing their jump services between Circe and Montem and between Hephaestus and Griffonstone. While setting everything up, the responsible players found a few bugs that I am currently looking into.

One of the bugs concerns inventories that belong to the infrastructure but are being used by companies: construction, upkeep and gateway fuel stores. They work as expected when dragging materials from a ship to them, or the other way round, but using the "unload" or "unload on arrival" actions will cause a loss of material. This is due to the way they work: Access to them is only granted for a limited time and for specific purposes, for example, a contract to provide gateway fuel. Behind the scenes an inventory transfer action will check if the infrastructure owns the target inventory and tell it about the transfer. In the case of the "unload" actions, this doesn't happen, and thus the transfer will not work properly and result in unexpected behavior.

There are also a few other bugs that I am currently looking into. The goal is to fix them all and release a maintenance release by the end of the month. I prepared a release notes topic in the forums for this maintenance release. It will also contain the new storage buildings and multi-item transfers I wrote about in the last devlogs. The release notes are not complete yet, I'll add more as I go.

Of course, we also have a monthly economic report for you. We added a new panel to the top showing the active companies by faction. Active in this context means every company that had at least one user interaction within the last 72 hours.

Click the image for the full report

Finally, a reminder: We phased out the physical perks in the supporter packs at the end of the year. In order for us to be able to send out the last goodie bags, we need you to tell us your shipping address and other details. If you bought a supporter pack that contains physical perks, please fill in your details in this form. If you already filled that out, please double-check that the information is correct. Thank you!

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

Happy trading!

Michi (molp)

The Holidays are almost here, time for a last devlog in 2025.

I have been working on the new multi-item inventory transfer I wrote about last week. It required quite a bit of refactoring to get it working. Especially the mobile inventory transfer threw a wrench into things, as I almost forgot about it, and it handles inventory transfers slightly different than the regular inventory transfer. Nonetheless, it is mostly working now, and I was able to reuse much of the code for both transfer paths. On the server side, everything is now a multi-item transfer, that can be used for both regular and mobile inventory transfers.

I had to re-implement the logic of the drop targets (AMT, 1, 10, .., HLF, ALL) and even added two new drop targets: MAX WGT and MAX VOL.

AMT still works like before: It just opens a new buffer with the MRTA command. AMT is only available when a single item is selected.

The number drop targets are now based on the stack with the most units. If I select 1000 for example, 1000 units of the largest stack in the selection will be transferred, then, if there is still room in the target inventory, up to 1000 units of the second-largest stack will be transferred and so on.

The HLF drop target is only available if half of all the selected stacks will fit into the target inventory.

MAX WGT and MAX VOL work similarly as the existing MAX drop target, as they try to fill as much as possible of the selection into the target inventory. The WGT variant first sorts the selected stacks by weight, starting with the lightest. As much as possible of this stack is transferred, and then the next-heavier stack is considered. This also goes on until the target inventory is full. The VOL variant works similarly but sorts the stacks by volume instead.

In case you recently received an email, warning you that your PRO time is about to run out, that is Martin's doing. He is working on our email system:

For the past two weeks, I spend a good part of my time on implementing a new system within our account management service that supports exactly that sort of thing: It allows to define arbitrary types of notifications, under which conditions they need to be generated, how often a user should receive it at most etc. I brushed up our email templates, standardising their content, making sure they are internationalised and they contain the right information besides the actual message. Last but not least, I invested quite a bit of effort into tooling to properly test these things, including making sure that each notification works in all the different languages we support and that they are really only sent under the circumstances we intended.

The first two notification types implemented so far are a “credits exhaustion warning” for AirlineSim and a “PRO license expiry warning” for Prosperous Universe. But we’ll add more types over the coming months. If you have a good idea for what might be useful to users, please let me know! And before you ask: Of course you will be able to disable any of the non-transactional notifications if you don’t wish to receive them :slight_smile:

You can find his full devlog in the AirlineSim forums.

This week the universe saw the first two gateways being constructed! This is no easy feat, so congratulations to everyone involved!

Finally, I want to thank you all very much for playing Prosperous Universe, for your support, for being so friendly and forming the best game community I have ever seen. 2025 has been a blast, looking forward to 2026!

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

Happy trading!