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.

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!

Michi (molp)

This week, the work on a small maintenance update continued (also see the recent devlogs #509 and #510). We plan to release the update early next year, a proper release notes topic in the forums will follow.

Usually, the maintenance updates contain bugfixes and small improvements. One of these improvements is something many players have been asking for a while: additional storage buildings that focus on either volume or weight. Up until now we just had a single storage facility adding 5000t and 5000m³ of storage capacity. With the maintenance update we'll add four more:

• STA Auxiliary Storage: will add 2500t / 2500m³
• STV Volume Storage: will add 2500t / 7500m³
• STW Weight Storage: will add 7500t / 2500m³
• STE Extensive Storage: will add 10000t / 10000m³

The new storage buildings will be especially interesting for players who want to optimize their area usage. STV, STW and STE will require Rhenium-based alloys as a construction material. The new buildings are live on the test server, by the way.

After the gateway release we received two change requests: The gateway construction progress should be visible in the GTW command and gateways shouldn't be shown as operational when they are still in construction. I fixed both issues. The progress will be visible as a percentage number.

When Martin was trying out the new Steam version, he opened the game in a rather small window and noticed that during the company creation process, the buttons for progressing to the next step (and going back to the previous one) can be hidden if the content of the step is too large. Although there are scrollbars, it might not immediately obvious to a new player how to progress. I changed the layout to a sticky footer layout that will always show the buttons.

Archiel recently presented a proof of concept for moving multiple inventory items at once in the forums. We really liked the idea, so I also started prototyping to see how hard it would be to implement into the existing inventory controls. It is far from done, but here is what it could look like:

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

Happy trading!

Michi (molp)

As stated in last week's devlog (#509) I started looking into smaller issues, bugs and maintenance issues.

One of these maintenance issues kept me busy almost the whole week. I implemented snapshot support for populations and planets. What does that mean? All entities in the game create an event stream that is being persisted to the database. An event is anything that changes the state of the entity. For example, a new population report is being generated, workforces are assigned to bases and so on. As you can imagine, after a while lots of events pile up for every single entity. Each entity only has to keep its state in memory during runtime. However, once an entity is being loaded from the database, say after a server restarts, the whole event stream has to be processed to get to the entity's latest state. In case of large planets and populations, this can take up to two minutes in extreme cases. Of course, the required CPU time is not available to other loading entities, and as such the whole performance is degraded. To fix that, we added entity snapshots. These snapshots are taken in regular intervals, for example, every 5000 events, and also stored in the database. Loading an entity now only requires loading the snapshot and every event that happened since taking that snapshot.

Implementing snapshotting for the populations and planets was tricky, as the respective code is old and sometimes not immediately compatible with the snapshot process. I also took the time to write many unit tests to make sure that events are being written to and read from the database in the correct way. It would be rather unpleasant to have a population or planet with an incomplete or corrupted snapshot.

We also released a new Steam version. One of the most requested features for it was support for changing the font size. Depending on the monitor's resolution, the font size was tiny for some players. It is now possible to change the font size, or more accurately the zoom factor, with the CTRL - and + shortcuts, just as in any browser. A very positive side effect of this deployment is that Steam thought that the game was inactive since we didn't upload any new game files. This happened, although we submitted news articles, regular updates etc. Anyway, the banner warning players about the inactivity is gone now.

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

Happy trading!

Michi (molp)

On Wednesday we released the gateway update. For an update that long in the making the release went relatively smooth. Right after the update, when the server booted up for the first time, we ran into a persistence error in the database. Luckily, this was just a minor error, and after a reboot to add some diagnostic code and another to fix the issue, the servers were up and running. Of course, over the next hours a few more bug reports came in, but I was able to fix them relatively quickly. There was one rather annoying bug, where APEX would load properly, and it would require several page reloads to finally be able to get in. I found the underlying issue on Thursday and patched. There are still some open tickets to look into; it seems the update broke a few things in the mobile version. I'll do that later this week.

We also hosted a live stream on Wednesday evening to talk about the release, 10 years of PrUn and to give an outlook on what's to come next. In case you missed it, you can watch it here.

The coming week, I'll look further into the reported bugs, go through our backlog and do some maintenance work. Due to the server restarts on Wednesday, I noticed that it takes quite a while until all systems are working and responding after a restart. There is definitely room for improvement!

Since it is December already, we have a fresh economic report for you as well:

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!

today we released the Connectivity update. Here is an overview of what's new!

Gateways

The gateways release is finally here!

Gateways are the first type of massive infrastructure that can be built by planetary governments. Gateways allow the establishment of a network of faster-than-light links between systems that haven’t previously been connected. It’s time to create new, efficient trade routes or shorten the distances to those far-out systems.

The new GTWI command enables planetary governments to design and plan gateways with precision. It provides all key statistics at a glance, ranging from possible jumps per day and linking radius to construction and upkeep costs. Whether establishing new connections or upgrading existing ones, GTWI offers the insight needed to make informed decisions.

Several new motion types allow you to put your plans into action. Commission trusted companies to construct the gateway, handle its weekly upkeep, and supply Vortex Fuel for its operation. Then, lean back and watch as the statistics on successful gateway jumps begin to grow and with it your revenue.

With gateways, you can profit from faster connections between trading hubs and outer regions. They simplify logistics and trade operations, but time is money, as they say, and operators will charge a transit fee for each jump.

You can find out more about infrastructure and gateways on the respective handbook pages!

Changes and Fixes

• The address selector shows little icons next to the address, indicating the type:
• Ship repairs can now be performed on commodity exchange stations as well.
• During mission planning flights that take longer than 24 hours are highlighted in red.
• Fixed a bug where the address selector is not reachable when creating contracts with many individual commodities.
• The active CoGC program is shown in the system information command SYSI.
• PLI and SYSI show the expected yield of a resource per day, per resource building
• Added a notification about the creation of a pickup contract when CX orders match, but there is insufficient storage space

You can find the release notes in the forums.

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

Happy trading!

Michi (molp)

On Wednesday we'll release the gateway update (called Connectivity). Naturally, I spent most of the week preparing for it. The release will happen on Wednesday morning, and if everything works as planned we'll have a nice and relaxed live stream in the evening :) The live stream will start at 20:00 CET and you can watch it here.

Since there is so much to talk about in this live stream, 10 years of development, the gateway release, upcoming features and the next 10 years, we'd love to hear what you are most interested in. Feel free to post your topics and questions in this Discord thread or in the forums. We'll look through it before the live stream and try to answer as much as possible.

Quick reminder: PRO licenses are off 15% until the end of the month!

I also went through the backlog of our issue tracker this week and tried to fix and implement as much as I could. We are going to release these changes with the gateway update.

• Ship repairs can now be performed on commodity exchange stations as well.
• During mission planning flights that take longer than 24 hours are highlighted in red.
• Fixed a bug where the address selector is not reachable when creating contracts with many individual commodities.
• The active CoGC program is shown in the system information command SYSI.
• PLI and SYSI show the expected yield of a resource per day, per resource building
• Added a notification about the creation of a pickup contract when CX orders match, but there is insufficient storage space

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

Happy trading!

It's hard to comprehend how much time has passed, but Prosperous Universe has been in development for 10 years now! We already wrote about this fact in the 500th weekly devlog and elaborated a bit on why this devlog (#507) is actually the 500th devlog. Devlog numbering aside, there is no single day we can refer to as "the start" of development. So instead we want to start the 10-year-anniversary celebrations with this very devlog!

Upcoming: Releasing the gateways

If you have been reading our devlogs over the course of the past weeks, you surely noticed that the upcoming gateways release is almost done and currently in the testing phase. So it is our pleasure to finally announce its release date: November 26th, 2025. As usual, there is a forum topic with the release notes and further details. We'll answer your questions regarding the release there as well.

Birthday present: 15% off of PRO

Although we discounted PRO licenses with the recent Colonization release, we strongly believe that another discount for the celebrations is in order. PRO licenses will be discounted 15% starting today until November 30th.

Birthday party: Join for the livestream!

We also plan to host a live stream with the team on the day of the release. The livestream will be held in the evening hours CET, an exact time and link will follow. We want to talk about 10 years of development, the current state of the Universe and give an outlook on what is to come in the future.

A brief tour of 10 years of PrUn development

The first commit to the codebase dates back to September 28th, 2015. Martin and I had many conversations about restarting the Prosperous Universe project in the weeks and months before that. Yes, you read that right: restart! Martin prototyped Prosperous Universe years before I joined the company, but the prototype never saw the light of day. So in fall 2015 we started all over again, together.

Many months of programming and planning and designing followed. We lay the technical groundwork for everything to come. Here is the first screenshot I could find from that time. It shows the APEX interface. Back then, we already had floating windows, but no tiling system. The idea was that the maps (be it the universe, system or planet map) should always be visible in the background. A bit like EVE, if you will.

At that time, the only visible signs of life of the project were our weekly devlogs. At first, we just wrote them for us, as a kind of journal, but we were able to grow a small following via an email newsletter.

It took a while, but in 2017 we were able to start our first alpha version. This was a closed test of what we had so far, and we invited friends & family and a few players we knew from the AirlineSim community.

There were two more closed alpha tests in 2017 and two more in 2018. All of them were rather short-lived and focused on individual features that we added.

Our first public release happened almost exactly 7 years ago, three years into development. We called it "First Access", since we felt the game was still more an Alpha rather than an Early Access product. Devlog #156 has all the details. For the first time we allowed players to create an account via the website and join the game; in contrast to the invite-only alpha tests before. We also started to sell the supporter packs to help cover development costs.

In 2019 we switched the business model to free to play. While it was possible to buy the smallest supporter pack during the "First Access" phase to gain permanent access to the game, we knew that this wasn't going to be sustainable in the long run. Devlog #190 has more on that topic. The most important point for us is: free to play just means that the game is free to play, no further microtransactions, no pay to win game mechanics.

The switch to free to play was followed by many feature and maintenance releases: Prelude, Expanse, Presence, Populous, Ignition. We added the administration centers, elections, warehouses, shipping ads, population infrastructure, ship building and so much more.

It all culminated in 2021 with the game entering into its "Early Access" phase. We reset the universe, generated an even larger universe map than in the versions before and added the fourth faction: Antares Initiative. By the way, this is now the eighth universe, and since its start, there has not been another reset.

Not long after the start of the "Early Access" phase we went on Steam. Although the game is no natural fit for Steam, given it is a browser- and subscription-based game, we still dared to allocate a good chunk of our development time to make PrUn compatible with Steam. In the end it was worth it: we have increased visibility through the store page, and a significant number of sign-ups come from Steam.

After the Steam release we continued with the content releases: Convergence, Prestige, Liquidity, Realpolitk and Colonization. The Transmission release sticks out a bit: It didn't add a lot of new content but rather new localisations: We translated the game into German and set up the technical foundation for community translations. These have been a roaring success as we now have complete translations in Simplified Chinese, Japanese, Russian, Finnish, Spanish, as well as ongoing translation efforts in many other languages. These translations help with the visibility of the game and by forming stronger player communities. We are very thankful for all the effort the volunteers have been and continue to be putting in!

Wrapping up and looking ahead

So what’s next? As mentioned above, the release of the gateways is just around the corner. But if you’ve been following along for the past decade or so, you know that we’re not stopping there: Our roadmap is long and our plans are elaborate. We will discuss these in more depth in the upcoming State of the Universe livestream, so make sure to mark your calendars (reminder: November 26th, 2025, evening time CET, exact time to be announced). For now, all we want to say is…we’re looking forward to and are ready for the next 10 years of Prosperous Universe development!

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

Happy trading!