• Development Log Week 66

    Account management systems and usability improvements probably aren’t the most exciting things to read about on our dev-log. But the fact that this is exactly what we’ve been dealing with this week can only mean one thing: We’re making good progress on our way towards a version of Prosperous Universe that’s actually playable!


    As mentioned before, we are getting closer and closer to an internal Alpha milestone. Once we reach it, the plan is to slowly grant access to a select few testers to gain early insights into how the game works and feels like when there’s actual activity in the game world. But to make this possible, some work on rather mundane backend systems needs to happen first.

    So that’s what I did this week: We already have a battle-tested account management infrastructure in place for our existing game, but it’s become out-of-date in a few respects and misses a few feature that we’d like to have both for Prosperous Universe as well as other projects. Because it is such a central piece of infrastructure, just rewriting it from scratch is not an option right now…it would just take too much time to get it right. Therefore, we went with a compromise: I added a new API to our current account management system that offers the functionality we need but uses our existing systems to provide it. At some point in the future, we can switch the underlying technology and the API will remain unchanged.

    I got the backend-side of things done this week. For next week I plan on completing the integration into Prosperous Universe and rolling out the changes to our account management systems.


    My focus this week has been usability again. Last week I told you about the context menu that appears when hovering a star or planet and helps to see what kind of actions can be taken. We have had a similar idea for the content tiles itself: Each tile can have a list of context commands that will open new tiles that are somewhat related to the current tile. That way the players don’t have to remember commands and can visually navigate from content to content.

    Here is an example. Say the player has opened the system map and wants to see more information about a certain planet. She can click on the planet and a tile with the planet’s information (PLI) will open. After buying some goods on that planet she decides that she wants to transport them to a nearby system. First step in doing that is to check if there is a ship in orbit of that planet. There are many ways to find out if there is a ship: She could check the fleet (FLT) tile and go over the list of ships to find one at the given location, or she could open the fleet tile with the planet parameter (FLT -p1234) to only get ships at that planet. While all these methods work it is still a bit cumbersome. This is where the context commands come into play. In the upper right corner, right within the tile controls is the list of context commands. In the case of a planet information tile there are three context commands:

    • System (MS yxz) to open a tile with the system map to which the planet belongs

    • Inventory (INV p-123) to open the inventory at this planet

    • Fleet (FLT p-123) to open the fleet tile, filtered by ships that are in orbit of this planet

    We hope the context commands will make it easier for players to navigate within the system and to find new commands and their usages they might not have been aware of.

  • Development Log Week 65

    The first internal alpha milestone is coming up in a few weeks, so it’s time to wrap up the important tasks and add at least a bit of polish.


    I had the pleasure of spending the first two days of the week in beautiful Prague, so it was a short one for me. Nevertheless I was finally able to combine the commodity exchange feature and Michi’s visualization code. As a result, you can now view supply, demand and trade activity for a material of your choice on the universe map. Whenever a trade happens or orders are placed, the map visualization is updated in real-time.

    This is already super cool and fascinating to watch in and by itself, but it’s also exciting for another reason: This was the final major item on my list to complete the core parts of the commodity exchange feature. Following our current roadmap, this leaves only two major tasks I need to complete before we reach our internal Alpha milestone: Foreign Exchange, so players can trade currencies, and an integration with our existing account management systems, so we can start granting limited access to the game for early, closed testing. Exciting times ahead!


    With our internal alpha milestone coming up I spent most of my time on fixing little bugs, things that we put on our “we’ll fix that later” list and usability issues.

    Last week I told you about the command system we have in place for the tiles. It allows to type commands to open up specific tiles, for example ship information, fleet information etc. There was still a bit work left, so I finished that this week. The command interface is meant for players that have some experience with the game.

    For everyone else it was quite hard to get into the game up until now, because you basically had to know what you are doing and there are quite a few actions that are almost only possible if you know engough about the command system. This has to change obviously when we want to show the game to other players and let them play. This week I started to work on these usability issues.

    There are two issues I focused on this week: Context menu and tile state.

    The context menu is available in the universe and in the system maps and tells you whether a planet or system has a commodity exchange or if you have a storage space there. The items are now clickable and will open the correct content tiles.

    Tile state is the very technical term for the fact that changes in (for example) map settings should be persistent even when tiles are split, moved and of course if the players log out they expect to find their settings as they left them.

  • Development Log Week 64

    After six days of meeting, reading, talking and experimenting our simulogics ops meeting is over and the quietness of our offices feels eerie.


    Not much to report from my side this week. We started with the final days of our long ops meeting and, as we had hoped, managed to actually get a physical cluster of three machines running. Well, kind of. There are still a few teething problems, but those were to be expected. Part of the reason we start running this kind of infrastructure way ahead of any actual launch is to get to know its quirks and pitfalls.

    We also spent some time integrating our newborn test cluster into our existing Continuous Integration pipeline. So once the final issues are worked out, we will be able to restart our development game worlds after every new build without any interaction on the part of the developer.

    But that’s about it…the rest of the week I had to take care of non-PU stuff. Lot’s of that will be going on over the coming weeks, so I hope to be able to squeeze in as much work on PU as possible despite having to earn some money :)


    After the quite successful and fun ops meeting at simulogics HQ I traveled home and continued my work on the client. Right now there are a lot of issues regarding usability and polish we want to address until the first release.

    If you are a regular reader of our devlog you might know how our interface works. If not here is a introduction in a couple of sentences: The main area is divided into smaller tiles that can show a certain content of the game. These tiles can be opened, closes, moved, resized and a layout of tiles can even be stored. Usually if you clock on something, say a ship, a new window (we call it a buffer) opens up with the ship details tile in it. You can then either close this buffer, get back to it later or drag it onto a tile.

    There is another way to open specific content in a tile: the commands. An empty tile will just show a command line where the player can enter commands to open the corresponding tiles. For example to open the before mentioned ship dialog the player has to type SHP id where id is the beginning of a valid ship id. Up until now only one parameter was supported. This week I generalized the concept and now multiple parameters are possible.

    For example: To display your fleet you can type FLT and you’ll see a list of all your ships. To show only the ones at a given system use the s parameter like this: FLT s-id.

    The commands are a nice way for experienced players to get things done very quickly in Prosperous Universe. Of course we will add buttons and links to be able to use everything without using commands.

  • Development Log Week 63

    Hey guys, sorry for the late and very short dev-log this week. We’re having an extensive 6 day meeting to discuss and set up the technical operations of Prosperous Universe. Fortunately, we are accompanied by our long-time admin Sven who’s already responsible for running all the servers over at AirlineSim. Michi and I would be rather lost without him when it comes to ops, so a massive “Thank you!” to him!

    We still have two days to go, but results look promising already. In fact, we’ve ordered the first batch of servers, so if everything goes according to plan, we might have an actual multi-node test server running on more than one physical host soon.

  • Development Log Week 62

    The development of Prosperous Universe gained momentum this week: We worked on very technical things like the servers’ cluster setup and monitoring as well as user interfaces and gameplay relevant topics. Feels good, let’s keep it up!


    I wanted to finally get done with the whole commodity exchange topic this week, but the “maintenance work” I started last week turned into a far larger project than I had anticipated. Turns out our server runs just fine in the test and development environments we’ve been running it in for well over a year now but it breaks down in a sad and miserable way the very moment it is confronted with an actual cluster setup like we expect to see in production. We were aware of this to some extend, but we’ve been putting off work on the required improvements in favor of feature development for months. So this week I finally stopped procrastinating and started to get it over with. Everything is already a lot more stable than a week ago and the invested time is definitely paying off. But I’m still not quite done yet. Some edge-cases still need to be looked into and I should probably prepare our systems for a few more failure scenarios to be expected in production.


    Last week I started to fix the visualization of FTL and STL traffic in the universe map. There was only one thing missing that I added at the beginning of this week: a toggle to switch between various time ranges. So right now the traffic data is available for the last hour, the last twelve hours and the last day. This is an arbitrary setting at the moment we might change it to some values that will make more sense in the game later.

    I kept working on the user interface for most part of the week. There has been an open issue on how we want to display the map controls in the universe and system maps. In the end we decided that we want have maps that are specialized by topic, e.g. navigational, political, economic. That way the amount of controls per map is rather small and clear. After doing some groundwork, namely writing button and button group components, I was able to quickly rewrite the old map controls. Some work is left for the next week: We want to be able show various data from the commodity exchanges like current price, traded volume etc on a per system and per material (e.g. traded good) level. Therefore the map controls need to allow a selection of material.

    There is one more thing I was working on and off this week and that’s visualization of technical metrics of our servers. Since Prosperous Universe is a distributed system with many nodes working together monitoring these computers in a efficient fashion is crucial as you can imagine. Fortunately we don’t have to re-invent the wheel here and there are quite a few solutions available. I looked into them and setup a test server that monitors our database.