The theme of this week’s development log could be “dynamic” because both Martin and Michi have been working on things that quite literally make the interface come alive. Our maps now support visualizations of live data on ship traffic and the commodity exchanges, featuring real-time price updates and trading, are starting to materialize.
My work on everything concerning commodity exchanges continued this week. I spent a bit more time than originally planned on test utilities to make testing complex entity interactions a bit less cumbersome. After that I went on to take out some minor adjustments to the existing UI components and wrote a few new ones that were optional during testing but will be required once people start to actually play the game. While it’s not too exciting to write order management tools and similarly thrilling features, it’s a crucial and unavoidable part of production.
Originally, I had planned to also start integrating the commodity exchange code and Michi’s visualization code, but it turned out to be a bit more complex than anticipated and some open technical questions still need to be answered before I dive in. So instead of rushing things there, I did a bit of “maintenance work” in other places, namely our cluster bootstrap sequence which ensures that a cluster of Prosperous Universe servers starts up the way it’s supposed to. It’s upsettingly fragile right now and nowhere near production-ready. I’m not done fixing it yet, but it’s already looking a bit better than before.
This week I fixed a feature that has been in the code base for a while but got neglected and eventually broke while we were doing the various refactorings of the last months. The feature is “visualize traffic” and with it working correctly the players should be able to see their own and other players’ ships.
Right now we have two different kinds of travel: Faster Than Light (FTL) and Slower Than Light (STL). STL is used when flying within a single star system. FTL on the other hand is necessary when traveling to other systems. The traffic within a system is visualized by little symbols that represent the ships. There are different colors for your own ships and ships from allies and third parties. We reuse the same symbols on the universe map to show the player’s own ships but not to show ships of other players, because there are going to be way too many ships to display.
So instead I reused the visualization I created in the last two weeks to display not the actual traffic, but a traffic statistic. Every flight (STL or FTL) for every system is recorded, counted and then displayed as a bar graph. The higher the bars the more traffic a system had in a given time span. I am not sure which time spans we want to use, but I guess ‘last hour’, ‘last 24 hours’ and ‘last week’ would be nice to have.
It seems like the team has made a few New Year’s resolutions. At least that would explain the frequent mentioning of automated tests in this issue of our development log…
I had a very productive start into the new year and completed large parts of the server-side code required for commodity exchanges.
As all areas of the game I’ve worked on recently, the commodity exchanges are a core feature and as such have existed in the codebase for a while. The commodity exchanges in particular were never even deactivated (like the production code) because I used them for my interface prototypes last year. But still, up until now they were missing a crucial functionality required for an actual release: Escrow.
So far, when a trade happened on a commodity exchange, all the broker did was to set up a contract between the buyer and the seller and the two parties had to then fulfill this contract by paying for the purchased goods and delivering them, respectively. As you can imagine, this can be cumbersome and – more importantly – quite risky. Contracts can be broken, after all. Therefore, the initial exchanges operated by NPCs offer escrow services: The seller has to deposit the goods for sale and the buyer has to deposit the maximum amount they’re willing to pay. Once a deal takes place, the goods are delivered immediately and the seller has their money in the bank right away.
Technically, the game now allows for all options: Purely escrow-based exchanges, simple brokers that only set up contracts and a mix of both (for example escrow for payments but a contract for the delivery). The reason for this is that players will eventually be able to operate their own exchanges and they will have to decide whether to offer escrow or not. There are advantages and disadvantages to either option.
Anyway, I got most of the server-side code done but I’m still busy completing a proper test suite for as many possible scenarios as possible. These things tend to become complex quickly, with several entities involved (buyer, seller, broker, …) and various complicating factors (trades in different currencies, insufficient storage capacity at the buyers’s end, trades with NPCs, …) making things…well…complicated. So this will keep me busy into the next week before I can get started on finishing the interface integration and hooking up the commodity exchanges to Michi’s awesome data visualization framework.
The last thing I worked on before the holidays was the server part of the universe map visualization. I told you in the last dev log entry that we figured out how it should work but haven’t had to time to implement it. This week I finished implementing it :)
It works like this: A data source (say a commodity exchange) calculated a new price for a product. It tells the newly created visualization actor about it. The visualization actor then accumulates these price changes from all data sources of that kind and, after a certain time, sends it to all clients that are interested in that information. All this is hidden from the client, it just receives price updates in regular intervals and can graph them.
Besides the visualization I fixed some bugs in space flight and the display of ships. It seems like intensive refactoring has caused some data formats to change so the client wouldn’t display and calculate these things properly anymore. Since we are usually focused on one thing when implementing something we tend to forget to test if everything still works as it should.
Maybe one of our early goals for this year could be to create a small staging environment for the game where a few players (and we developers) can test new features and see if everything works like it should. That way we instantly know if we broke something. Of course we are writing automated tests for the client and the server code, but it seems that most of these errors occur when the two have to work together. So eventually, we’ll have to set up proper, fully automated integration tests.
After a week spent out of office we felt like a regular issue of our usual development log wouldn’t make too much sense. Instead, we want to give you a brief outlook on what’s ahead for Prosperous Universe in 2017.
As mentioned a few weeks ago, we recently completed our first full year of development. While a lot of work was finished during that time, we had almost no actual in-game visuals to present in our logs. This will definitely change in 2017: We are more or less done with the boring groundwork and are busy implementing actual gameplay as well as the final interface. Once the latter is done we will finally be able to show you what Prosperous Universe actually looks like.
More precisely, our immediate milestone is the completion of an internal alpha version which we plan to open to a select few volunteers. PU’s learning curve is intentionally steep, but before we open the game to a broader audience we want to work out the most obvious kinks that could keep people from finding their way into the game.
After this initial round of testing we plan to launch Prosperous Universe into Early Access. At this point, all the most fundamental gameplay elements - production, trade and transport - as well as some crucial auxiliary features, will be available. Our idea is to continuously build on top of this foundation and deliver frequent updates which add additional, higher-level features to the game.
While all of this is going on, we’re going to ramp up our community efforts. We think that we need better means of communication than the ones currently available, especially once the first people start to play Prosperous Universe.
These are our next major milestones and we plan to reach all of them in 2017. But obviously, the timing depends on a plethora of factors. So stay tuned and make sure to follow us here, on Facebook or on Twitter. If you prefer to receive important news and infrequent summaries of our progress by email, feel free to subscribe to our newsletter.
With that said, Michi and I will return to our workstations and make sure that the year 2017 will be a prosperous one for our project!
We’re spending a few days of quality time with friends and family over the holidays and we hope you’re doing the same. That doesn’t mean we didn’t get some work done the week before, though. While Martin continued to complete the population aspects of the game, Michi worked on fancy visualizations for the various data that we want to display on our universe map.
That said, we’re taking a few days off of work now and will be back at it in 2017. We wish you Happy Holidays and a Happy New Year!
As planned, I continued my work on populations this week. The overall satisfaction of a population now has a direct influence on the efficiency of production facilities. The single needs that make up the overall satisfaction value fall into different categories of varying importance to the population. So if you do not provide enough water - obviously a basic need - the happiness of your staff will drop drastically. But if you don’t care about providing certain luxury items, the mood will sour a bit, but your production won’t grind to a halt because of it.
After hooking up the production systems to the new population code I went on to build the GUI for all of this. Firstly and most importantly, the production interface now displays the effective efficiency for any given production line. The view for a base on a planet provides you with a quick overview over population size, capacity and satisfaction. And last but not least, a dedicated population window holds detailed information about the satisfaction of the various tiers of your population down to the level of individual needs.
All of these components will probably require another round of polish - both in terms of visuals as well as tuning of the underlying formulas - but all in all, the new population system is functional enough to continue on to the next topic. As mentioned before: I’m trying to get all the important systems done to a point that one can actually play the game with all the features needed for an Alpha as soon as possible.
I continued to work on the visualization of the universe map. The visualization part on the client works pretty well be now. At every star position an extruded triangle can be rendered with one or more segments to represent one or two data points. The height might indicate a total value. I added animations so that the transitions between two values is not too abrupt. The following animation shows some random sample data and how the graph interpolates between various values. Keep in mind that this is just a demo, so no final colors or anything like that. Random data shown on the universe map
The server side part of this is a bit trickier. Say, for example, we want to track the demand of a certain material. The client needs to be able to tell the server that it needs this data and wants it to be updated every couple of seconds or if there are changes in the data. The server then has to add the client to the list of clients that are interested in that data and has to start collect the information. In our case the information source would be every stock exchange where the given material is traded. We have a good understanding of how we want to implement the behavior on the server, but I could not finish it before the holidays.
In this week’s devlog we explain how the planet’s populations work, why you will be able to mine liquid oxygen and a bit about the visualizations of the main map.
I continued right where I left off last week and started tackling the next topic on my list of things to get done for our next milestone: Populations. If you are a regular reader of this blog, you might have a vague memory of me talking about this topic before. Since then, more than 20 weeks have passed and our plan of how we want to model populations in the game has changed quite a bit.
A quick recap: The original idea was to model populations as proper NPCs. An AI would control their purchasing behavior based on a set of rules and needs. Players would then essentially purchase manpower from them to run their production facilities.
While this is very close to our ideal of how things in Prosperous Universe should work, it turned out to cause quite a few tricky problems. Most and foremost, these NPCs would be quite easy to “game”: Because a single NPC would represent the whole economy of a planet, the AI that controls it would have to be bullet-proof as to avoid price manipulations on part of the players. But even if we spent the time required to come up with such a system, there would still be the complexities involved in bidding for the available manpower and the delay it causes to anything a player wants to do on a planet. In some cases it might cause a complete loss of agency, for example when the required personell simply isn’t available in a place where you need it.
Especially the latter would be quite realistic and in fact something that we want to have in the game at some point. But right now, we are working on the very first version of the game. The foundation of everything to come, so to speak. In this stage, what matters is that players can actually do stuff. That they are constrained by the game world but not to the extend that they can’t do anything about their fate without mobilizing an alliance counting hundreds of other users (as would be the case if one had to colonize a planet with a full-fledged population just to get a certain production chain up and running).
So for now, we decided to drastically simplify the population aspects of the game. Firstly, populations are not NPCs anymore. Players can add habitation modules to their bases and thereby create their own pool of personell that’s available without being affected by or having to wait for things outside of their sphere of influence. Secondly, it’s now the players’ job to provide for the populations by producing or purchasing the goods needed by the colonists. This makes the markets a lot more lively and stable since many actual players instead of a single NPC will be buying consumer products.
This week, I added the first server-side parts of this, mostly those that deal with the simulation of the actual consumption of goods. Next up is the influence of the supply situation on the efficiency of the workforce as well as all the interface components required to communicate the desires of the people to the great leaders that will be our players.
This week I finished one last feature we wanted to have in the universe generation process. It involves the phases of the resources that can be mined on planets. We already defined quite a few resources when we did the first iteration of the material/product tree. They can occur as mineral, liquid or gaseous resources. Take oxygen for example: Under normal conditions (moderate earth like temperatures, around one atmosphere pressure) it is a gas that is generated as part of the atmosphere on some of the planets in Prosperous Universe. So far so good, but what about planets that have very high temperatures and high atmospheric pressures? Oxygen cannot occur in the atmosphere because it would become a liquid under these circumstances.
So again, I did some research, found out that phase changes can be quite difficult and behaves slightly different for various materials. Eventually I came up with an approximation that works well enough for the liquids and gases in Prosperous Universe. We won’t change the phases of mineral resources because in most, if not all, cases such high temperatures would be necessary that a human outpost on that planet wouldn’t be viable at all.
The rest of the week I spent working on the client side of the game, specifically the visualization of the universe map. A few weeks ago we showed you a screenshot from the editor: Screenshot from the world generator
The universe map will look similar. While a lot of stars can be found in a hexagonal sector only one star will ever be in one of the triangles that make up these sectors. The idea now is to use these triangles to display various information like distribution of resources, traffic, demands for certain goods etc. We will do that by extruding the triangles upwards and generate a 3d graph out of them. I am not quite done with that, screenshots will follow!