Michi (molp)

The work on routes continued this week. I implemented a new command (RTE - route executions) that keeps track of all ships that are currently assigned to a route. Here is a first draft of that command:

For each ship that is assigned to a route, it shows the route, its status, progress through the route's waypoints, current destination and current step. I added a small indicator so it is immediately visible if the route execution is blocked by something. In that case the indicator will be yellow. In other cases it'll be green. As usual the list is updated automatically as the execution progresses. Clicking on the ship's name will open the RTE command with that ship's transponder code and show a more detailed view of the execution:

In the upper section we have the same information as in the list view, but with an additional flight field. Clicking it opens the ship flight controls SFC and thus the current flight of the ship. The progress section is a similar to the route editor, but without the buttons to actually edit the route. An indicator on the waypoints and steps shows where the execution is currently at. Right now the command doesn't really tell why a route execution is blocked, it could be missing fuel for a flight, no funds for a gateway passage, not enough fuel to refuel, etc. I am pretty sure that we can make this more specific in the future.

I also implemented a lot of smaller details, for example: the normal ship controls, like aborting a flight, setting 'unload on arrival' etc., will not work while a ship is assigned to a route. Additionally routes now loop, if the corresponding flag is set for the route. If a user loses PRO status while a route is being executed, the route will finish the current execution, but not start a new one.

We also have the latest economic report 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)

It has been a while since the last devlog: I have been on vacation! Now I am back in the office and continue where I left off. This week the work on the route feature continued. I implemented the logic that actually executes a route. After a ship is assigned to a route it creates a copy of the route and starts executing it. It flies to the respective waypoints, executes all steps, continues to the next waypoint, and so on. Right now only the happy path works, ie the route execution is not blocked by any issue. By the way: We use a copy of the route, because we don't want to lock the route while ships are assigned to it and allow changes. Once a ship finishes the assigned route and the route is set to repeat it will create a new copy and thus execute all the changes that have been made in the meantime. This is a compromise, of course, but it removes a lot of edge cases and confusion.

I implemented the refuel step as an example to test the execution of steps. Similar to custom contracts, I decided to use an overlay to allow players to edit the steps. Here is an example:

The refuel step is defined for either STL or FTL fuel (if both are needed, two steps are necessary) and the source of the fuel can either be a local store or the ship's cargo hold. It is possible to specify a minimum and maximum amount of fuel that is being transferred. In order to not have to worry about different fuel tank sizes of the assigned ships, it is also possible to select "capacity" for either value. That means that the refuel step will try to fill the tank to its capacity.

There are cases when a step cannot be executed: In this case for example when the selected store doesn't have enough fuel to transfer the minimum amount specified. We haven't decided exactly what to do in such a case, but the options would be:

• stop the route execution and send a notification about the issue
• continue anyway
• wait until fuel becomes available

Depending on how one is using the automatic routes and depending on the actual step type, all three might make sense in some circumstances. I am still thinking about how to best implement that.

Here is a video of a small test route with a refuel step. You can see that the flight is planned and started automatically, the ship consumes fuel, takes fuel from the station's warehouse, and then plans and executes the flight back to Umbra:

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

Happy trading!

Michi (molp)

I have written a lot about inflation and dynamic market makers over the last few weeks, and this week it was finally time to let them loose. All market makers that are based on a closed bracket, meaning they have a standing ask and bid order, are now adjusted dynamically based on the price development of the last 10 days. I described the concept in more detail in devlog #538, if you're interested in finding out more. So far we haven't encountered any major problems — there was just a small rounding error. Usually the price band of a broker gets adjusted when the market maker order changes. In some cases this adjustment was rounded in the wrong direction, and until we fixed it, it wasn't possible to match the market maker order because the price band was a cent lower or higher than the ask or bid order.

Currently, a group of players is using government motions to set the base establishment fee to its maximum (10 million currency units for planets in non-faction space) to effectively create "private" planets, making it very hard for regular players to found new bases. The base establishment fee was once introduced to compensate players, or groups of players, for their effort in building up infrastructure and workforce populations on new planets. It was not meant to be a means to lock out other players entirely. From what we have gathered so far, this group is trying to do exactly that. We are monitoring the situation and might reduce the maximum of 10 million to a lower value.

Besides the elevated amount of community work I have done this week, I also looked into a new feature: shipping routes. It has been on our roadmap for a long time and there is also a game design concept for it. Over the course of the last few days I built a first prototype of the UI. The routes and their waypoints and steps are already stored on the server, but they lack detail, and the steps are not executed yet. I still felt like sharing what I have so far, in order to spark a discussion about the feature and get early feedback.

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

Happy trading!

Michi (molp)

An already short week (I had a couple of days off) got even shorter due to database issues. After a regular maintenance update, the servers' performance was unusually bad. It took a while before I realized that the database was also struggling. Sometimes one of the three database instances would even get killed due to failing a liveness check (a regular check that makes sure the database is still there and responding). That of course didn't help with the performance, as losing a database instance means that a third of all game objects (users, companies, admin centers, planets, ..) have to be reloaded as well, putting additional strain on the system. In the end I found out that there was a rogue game object that kept writing to the database in a tight loop. I admit, that was a bug I introduced, and it was somehow enough to send the database over the edge. After fixing the underlying issue, I looked into the database configuration and found room for improvement. We'll change how much memory is allocated for various parts of the database and will also reduce the load introduced by the liveness checks I mentioned. It turns out these checks are not free at all, the way they are wired up right now. I'll deploy these configuration changes over the course of the next updates.

We are currently also ramping up our marketing efforts, looking for YouTube channels willing to add a sponsored segment to their videos, similar to what we have done in the past. This of course also takes away a chunk of time from actual development work, but will help the game as a whole in the long run.

A new month just started, so there is a new economic report 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!

Michi (molp)

This week I deployed the change in the retention factor I mentioned in last week's devlog #539. After a few days we saw a drop in the number of taken plots. It is not much, but it is a beginning. Just today, in the weekly team meeting, we discussed two other measures we will roll out later this year.

I also deployed the new inflation index command INFL:

In devlog #537 I described how its controls work and what the graphs show. You can now give it a try yourselves.

Besides the dynamic market makers, we'll also use the inflation data for two other control mechanisms: starting capital and faction contract rewards.

Similarly to the market makers, we have adjusted the starting capital and contract rewards every once in a while to account for inflation. I implemented a mechanism that takes the inflation data and adjusts these two values once a week. Instead of being based on a single commodity or basket of commodities, as makes sense for a single market maker, starting capital and rewards are based on an average across a given currency.

We'll collect a bit more data and then activate the three control mechanisms.

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

Happy trading!

Michi (molp)

This week Martin, Fabian and I met in person in the simulogics HQ. It has been a while since we last did that, so naturally there was a lot to talk about. Right now I don't want to go into the details, but I can say that we reprioritized the upcoming features a bit. While we still think that the faction influence feature would be a great addition to the game, we reduced its priority to look into a few other things before that. Fabian will now start working on a design document for a feature that will redefine the very start of a company. We are thinking about letting all new players start in a specific location (this might be the remaining generation ships) and only once they've gotten to know APEX's interface, have to make a decision where to build their first base. This actually helps with two issues we face: The learning curve is a bit more gentle and the whole plot situation is defused as well. This is now in the idea stage and I am eager to see what Fabian comes up with.

Talking about plots. Given my limited time this week, I decided to work on the automatic company liquidation. Usually, depending on the license status, we allow a certain amount of inactivity before we announce and execute the company liquidation. The announcement happens in the form of an email, as this is the only way to reach the players. With players coming from Steam this doesn't work in many cases: Steam doesn't provide an email address for the players and if they don't deliberately choose to complete their simulogics account, we have no means of contacting these players and telling them about the upcoming liquidation. Hence, we decided that we'll allow 200 days of inactivity and a 30-day deadline for these players before actually liquidating their inactive companies. This is obviously a very long time. There are many players who just start the game and notice that it is not for them. In the worst case they might block a planetary plot for more than 200 days.

To combat that, I implemented a new retention factor that is based on actual activity. For example, if a player's last activity is on the day they joined, the 200-day retention is cut in half. If they never built a base or started a flight: cut in half again. That way I hope to vastly speed up the liquidation of actual inactive companies. The change is already live in production, and we should see first results in about a week.

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

Happy trading!

Michi (molp)

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

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

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

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

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

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

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

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

Happy trading!

Michi (molp)

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

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

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

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

The controls in the middle select the currency.

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

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

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

Happy trading!

Michi (molp)

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

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

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

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

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

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

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

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

Happy trading!

Michi (molp)

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

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

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

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

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

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

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

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

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

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

Happy trading!

Michi (molp)

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

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

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

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

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

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

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

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

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

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

Happy trading!

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

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

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

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

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

Happy trading!

Martin

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

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

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

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

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

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

Happy trading!

Michi (molp)

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

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

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

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

Click the image for the full report

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

Happy trading!

Michi (molp)

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

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

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

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

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

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

Happy trading!

Michi (molp)

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

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

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

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

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

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

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

Happy trading!

Martin

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

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

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

Michi (molp)

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

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

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

Here is the latest economic report:

Click the image for the full report

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

Happy trading!

Michi (molp)

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

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

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

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

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

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

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

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

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

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

Happy trading!

Michi (molp)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Happy trading!

Michi (molp)

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

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

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

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

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

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

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

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

Happy trading!