With Martin on vacation, the rest of the team continues to work towards finalizing Populous, integrating FTL measures into ship building, and forming a valid ad strategy for Facebook.
This week I was able to transform the rough ideas and sketches (presented last week) into a concrete visual representation of what the mobile interaction of APEX flow will look like.
Based on the feedback from the team, I need to iterate and fine tune the designs. So look forward to those!
I can finally see light at the end of the tunnel when it comes to implementing the features for the Populous release. While there are still some larger ones left I’d estimate that we have finished at least two-thirds at this point.
This week I implemented the workforce reserve pool. If you follow the devlogs you might know that building a habitation module will not increase your base’s workforce after Populous is released. Instead a workforce request will be sent to the population and once every week the whole planetary population is redistributed according to these requests.
But what happens when one builds a production building during the week? How will it be staffed? This is exactly what the workforce reserve pool is for! When the workforce distribution happens a certain amount of workforces of each tier will not be distributed but rather assigned to the reserve pool. We will set this value to 10% initially and see how well it works out.
When a building is erected, a similar request is made to the workforce, but this time the workforce is taken from the reserve pool. The request is fully met if a) the reserve pool is large enough and b) the requester has not requested more than 5% of the pool’s total workforce. The last condition is obviously there to prevent a single player draining the pool too quickly and everyone else having to wait until the next general workforce distribution to get some workers.
The screenshot below shows the modified build option. The numbers in parentheses show the available reserve workforce that will be assigned immediately when the corresponding building is constructed.
In the last devlog, I gave an overview about all the things I’m working on when it comes to the ship-building update. Today I want to go into a little more detail on one of those aspects: the reworked FTL flight model. As always, everything is in flux and subject to change, but here’s the current gist of it.
For a ship to be able to perform FTL jumps in our PrUniverse, it has to surround itself with an FTL field. This field is created from a number of emitters placed on the ship. Each emitter can span a certain volume. Now, for the first iteration of ship building, ships will just have to have a set number of emitters that together span at least the ship’s total volume. Later on when we introduce the ability to create your own custom ships in a visual editor, the positioning of these emitters will play a vital role and be a part of every ship’s design.
Back to FTL flight though. Let’s say your ship has enough emitters to create a big enough FTL field. Next, those emitters need power provided by the ship’s reactor. The power needed to get the emitters going (and the resulting charge time) will be the minimum power you need to invest to perform an FTL jump at all (with minimum speed). Any unused power available beyond that can be turned into “overcharge” to increase your jump speed. The amount of overcharge you want to use is what you will be able to manipulate in your ship’s flight controls.
As you can see, it’s all pretty straight forward, but given the interplay of the different ship parts it’ll create quite a few variants. You want to build a huge ship with lots of cargo space? You’re going to need many emitters and a high-power reactor with long charge times (in case you don’t want to become known as the “space snail”). On the other hand you’ll also be able to build smaller and faster ships to get to distant regions more quickly, and of course all kinds of in-between hybrids. It all comes down to your overall strategy!
From my previous discussions in the devlog you might have remembered the HVCO (high value content offer) that I am developing for Facebook ads. If you don’t recall, basically it is an article (other forms such as video, consultations, free demos etc. are also used) that is developed to answer burning questions that a potential customer might have. The business provides such information to warm up the audience that is unfamiliar with their products. Since the audience now has something of value, they are more inclined to trust the business and look at their products or services. It’s often equated to wining and dining your less informed audience before asking for marriage (the sale).
Initially I wanted to do the HVCO on economics since PrUn is heavily based around the subject, being an economic simulator. I kept circling back to the primary question of, do we actually provide a product that would serve the needs of people interested in this topic. For the economic questions the answer would be no. People interested in economic theories and wanting to know how they work are not necessary interested in a game, which is primarily what PrUn is. So I went back to the drawing board and thought about what people that play PrUn might be interested in and what we can actually deliver with a game. I decided on writing an article around the subject of “How Space Colonization Would Actually Work” (title not finalized). By writing this type of content I will be able to explain realistic theories on how humans can colonize space and link them back to the pillars of PrUn: planet discovery, production, trading, shipping, and politics. I think that people who find these topics interesting are great candidates for new PrUn players. We can also provide a solution for these people who want to dig into these topics more since the game revolves around these themes. Lastly, I want to create landing pages for each of these pillars since they will also help us expand our website and improve our SEO ranking.