published on May 17, 2021 in devlog
KI-448 has been officially named "Hermes"! Fabian talks more about a local government's role in infrastructure projects and Michi explains how data is managed in Prosperous Universe.
Fabian (Counterpoint)
Last time I talked about how governments will be able to use a new tender platform to have infrastructure built for them in the future. But, there is also going to be another case of infrastructure being built and owned by private companies. In this case, local governments will still have an influence through the local rules. For example, they might limit the price range an infrastructure owner is allowed to set for the infrastructure's usage, or they may only allow a certain number of a specific type of infrastructure to exist within their jurisdiction (yes, infrastructure competition will be a thing too).
However, there's quite a big difference in how the money flows. Since the government can't just collect usage fees themselves for an infrastructure they don't own, the infrastructure owner will instead have to pay taxes to the local government. Depending on how high these taxes are, some places in the universe will turn out to be more attractive to build certain types of infrastructure than others. Ultimately we want to allow for different types of taxes as well (e.g. fixed amounts per time / per usage or a percentage of the infrastructure's revenue). In short, there will be more ways for governments to differentiate themselves from one another.
Michi (molp)
I don't have much to add to this week's devlog, as I am currently writing the backend part of the data collection that will eventually be used to display the data on the maps.
Nonetheless, I want to give a little glimpse into how data is handled in the game. As you might know we use an actor model for almost everything in the game. That means every entity in the game (companies, users, commodity exchanges, admin centers, planets, ...) is an actor with its own state (i.e., data). If a player wants to display the data of a planet for example, the PLI
command in the client send a request to the corresponding planet actor, which in turn replies with the planetary data. On top of that, a subscription is created that keeps the client in sync in case the state of the planet data changes as long as the client displays that PLI
command.
While this way of fetching data works very well for single entities, it does not scale well when we want to display information on a universe-wide scale. Right now, we have something like 4000 planets in the game, and imagine that we would have the map show resource concentrations in all systems. That would flood the servers with requests. Instead, I am currently working on a data collection and aggregation framework that runs on the server and takes queries from the client (for example: "show me all H2O resource deposits") and returns the data in a single response.
Nick
Last week was a short week for me since we had a holiday in Germany on Thursday and then I took Friday off as well. However, I was able to work on a few things like getting things ready for our first foray into the realm of affiliate marketing. I am hopeful that this will yield some good new user acquisition for us since I worked out a deal where we will only pay for the users that choose to acquire a PRO License. This is in stark contrast to YouTube Ads and other platforms where we pay for each click, regardless if a user becomes a player or not.
Congratulations to our new named planet, Hermes (formally known as KI-448b)! Thanks to all that partipated in this month's "Name a Planet" community event. We will be doing this every month, so don't fret if your favorite planet didn't get chosen.
Happy trading!