Updates on all fronts with Fabian highlighting more details on Populous, Michi explaining auto-provisioning, and Martin exposing the reason for a new anti-botting fee.
I was able to build upon the topics that I discussed last week so not much new information to report here. The new press release is ready to go and will coincide with the new maintenance update for new press contacts. I also worked on some SEO ideas for the website in order to make the homepage longer and more content-rich. Tracking SEO is bit tricky since the changes take a while to see any real effect so I am looking at it each week to see if there is any positive or negative results that can be concluded. I also worked on the new WII-era image that I spoke about last week, and I’m happy to say that it is turning out a lot better than I had hoped so I hope to share it on social media soon!
My quest to refine the concept for the next named release “Populous” continued this week. I added a few mockups, filled some gaps regarding certain low-level questions, and updated the design doc to be in sync with the formula overview spreadsheet I created and tweaked last week. Now that I’ve mentioned some of the working parts of the concept throughout the last few devlogs, I’d like to present you with the plan for the overall gameplay loop this time around. Please enjoy this flow chart!
There’s a lot going on in the details of the relations between these elements of course, but in short it works like this: Each planet holds a certain population (the total workforce of all players on the planet). Populations express specific needs depending on how many workers of each tier are present. Needs are filled depending on the planet’s environment and (mostly) the planetary infrastructure players have built so far. The expressed needs are then compared with the need fulfilment provided to determine the population’s happiness. (As an aside, the unemployment rate will also play a role here as a penalty or, in fact, an “open job opportunity” bonus if there are more workspaces than workers.)
Finally, a population’s happiness determines whether it grows or declines and thereby feeds back into its size. And from there the cycle starts over. (On another side note, there’ll be a few special rules for workers “levelling up” to the next tier under certain conditions. Also, engineers and scientists will need educational infrastructure to spawn in the first place.)
This week I finished the last remaining issues on the list for the upcoming maintenance release (release notes). The release will probably go live on Wednesday 22nd of April and its main focus are the enhancements of the new player experience I mentioned in the last few devlogs.
On Thursday I added the last new feature: auto-provisioning of shipping ads. This has been a much requested feature because when it is being used haulers that accept a local market ad will able to pick up the shipment right away. Here is how it works. When the principal creates the shipping ad she can select an inventory from which the materials should be provisioned once the contract is being closed:
If the materials are in the selected store when the contract closes, the provisioning condition is fulfilled immediately. If the materials are added to the store at a later point, but within the deadline, the materials are provisioned automatically as well. The selection of an inventory for auto-provisioning is entirely optional.
This week I added a feature to counteract “bot-like behavior” on commodity exchanges: Order deletion fees. The decision to add this wasn’t an easy one. In principle, adding penalties like this usually means punishing fair players just as much as the ones they are supposed to hit. So Fabian put a lot of effort into striking a balance in the design of the parameter. What I have implemented now roughly works like this: Within a certain timespan, you are allowed to delete a limited amount of unfilled or partially filled orders for free (filled orders aren’t affected). Once you exceed the limit, you will have to pay a 5% deletion fee based on the remaining volume of the order (remaining amount times limit). The reasoning behind this is that what annoys players isn’t the fact that a bot plays the game, per se, but the bot’s behavior. Which is usually something like immediately undercutting orders by a tiny amount, requiring people to constantly adjust their orders as well. The fee doesn’t prevent this behavior, but it makes it very costly. Obviously, we will watch closely how the feature affects the game and will adjust the parameters if needed.