• Development Log Week 70

    For our 70th week of development, Michi and I met up at simulogics HQ again to spend a total of 5 days planning and scheming!

    World Building

    With more or less public play tests coming up soon, we need to get the world of Prosperous Universe finalized. By this we mean the factions present in the game world as well as their background stories. There will be five different factions that each come from a different background back on Earth and any new player will have to join one of them during sign-up. For now, the differences between the factions are purely in the story, but we might add actual differences relevant to gameplay at a later point in time. Think certain production bonuses or different starting conditions.

    Ship Editor and Construction

    It’s been a while since we posted concept art like this to our Facebook page:

    Modular Ships

    It has always been our plan to have fully modular ships in Prosperous Universe, mostly for two reasons:

    1. Everything in PU needs to be produced by someone. Splitting up ships into components makes this a little bit easier.
    2. We want players to be able to construct their very own, purpose-built ships with very different characteristics.

    This week we sat down to finalize the concept for this major feature so Michi can get started on implementing it over the coming weeks and months.

    Content & Balancing

    There will be hundreds of different materials, items and resources in Prosperous Universe and setting up any kind of production chain involves building a base, feeding a population and sourcing materials. You might even have to haul fuel, resources and supplies half-way across the universe. So what would a new player need to get started in this world? They need enough construction materials and supplies to be able to set up a base and maintain an initial population for a few days without having to immediately purchase more on the market. They need at least one ship and enough fuel for a few long trips. They should also be able to actually do something during the first hours of gameplay and to expand their operations within a few days at most. To achieve these goals, we tweaked the production tree and other parameters. Most of the work to get all of this to “feel right” will have to take place during Alpha and Beta testing, though, with balancing based on actual feedback from players.

    Business & Roadmap

    Last but not least, we had to deal with a few less interesting but nonetheless important business-related topics. This included detailing our roadmap for the coming months and work on our new website which we plan to launch before early alpha testing commences. We also thought a lot about our monetization and launch strategy and came up with a hybrid between an Early Access model and a crowd-funding campaign which we want to start later this year.

    So this is what we have in mind: We’ve been working on PU for more than a year now and although we still have a (very) long list of features we’d like to add, we feel like it is time to get the game out there. Since we expect the project to evolve quite a bit during it’s first months after release, we feel like an Early Access-like model would work very well for us in that we grant access to the game early and then add new features and improvements continually over time. This way, anyone who wants to take an early look at the game can do so by simply purchasing game time. For anyone who wants to support our development beyond that, there will be a variety of crowd-funding-like tiers that will offer different perks ranging from a simple mention in a list of supporters to physical merch like shirts, art prints and more.

  • Development Log Week 69

    This week we prepped for our simulogics HQ meeting next week and polished the chat system.


    Michi and I will meet at simulogics HQ for all of next week, so I tried to get as many distractions off my to-do list as possible. This means that besides some planning and minor bugfixes I mostly worked projects other than Prosperous Universe, so once again, no noteworthy news from my side in week 69.


    Last week I split the old Chat window up into a channel list and a channel tile. I spent most of the week on refining both elements.

    For starters I had to get rid of some code that only made sense in the old version when only one chat could be active at any time since all chats have been in tabs. There has been the distinction of leaving a channel and passivating a channel. Passivation would remove the chat’s tab from the component and put the chat into a list of recent conversations. The user didn’t receive any message notifications for passivated chats. The reason to implement passivation was of course to be able to reduce the amount of open tabs in the chat component.

    The passivation concept doesn’t make any sense in the new tiled approach. Instead we removed it and replaced it with a button in each channel to mute the conversation.

    It works like this: Imagine you have a lot of channels you participate in and in the current screen there is the channel list, two private channels and one group channel. Whenever a new message arrives the new message notification will show. If you hit the mute button of one of these channels because you don’t want to get notified each time someone writes a message in the very busy group channel it will get muted. The channel itself will remain visible and you will still be able to receive new messages. That way you can keep an eye on the channel but won’t be flooded with notifications. In the channel list the channels are now being sorted by last activity. Muted channels appear greyed out and their sort criteria is not the last activity but the timestamp they were muted. Muted channels will slowly move down in the channel list.

    Besides these bigger changes I added quite a few minor improvements like styling, date and time formatting, pluralisation of messages etc. pp.

  • Development Log Week 68

    When switching to a new user interface one should always make sure that every aspect of the game has been migrated, or else you’ll end up writing a devlog about how you adapted an age-old system to the new design.


    Unfortunately, I had to meet a deadline on a customer project and I spent all of this week on that. So other than a bit of organizational stuff and some reading on infrastructure topics, nothing to report from me this time.


    Sometimes in long running projects like ours it can happen that a piece of prototype design or code sticks around for a long time and no one updates it in the coming design iterations. That is exactly what happened to our in-game chat system. We wrote and designed it quite a while ago, but then somehow forgot it. When we were revisiting what features we want in our alpha milestone it came to mind again.

    Originally we designed the chat to exist in a single window which had tabs for the different channels and a fixed tab for the chat controls (to add new channels, for example). When we switched to tiles instead of windows no one updated the chat. The chat still works in a tile, but having tabs within a tile doesn’t feel right. The tile becomes to heavyweight.

    So this week I redesigned the chat and split it up into two main tiles: the channel list (COM) and individual channels (CHA). The channel list contains all active conversations, regardless if it’s a private conversation with a single other user or a group channel. Every entry in list shows the participants of that channel and if there are any new messages that have not been seen yet. Clicking on an entry will open the channel tile. It basically contains what has been in a single tab before: the message list, the user list and the prompt to enter new chat messages.

    When creating a new channel the player has to define a channel name or channel participants. The necessary UI elements have been in an extra tab before. We decided that the channel list should not have that clunky UI visible all the time so we had to come up with a new method to show the elements only when needed. The channel list now has a few buttons to create new channels and each will open an overlay of the tile which contains the UI elements to enter the name or participants. The overlays are bound to a single tile, so they can be open while doing something else in another tile. This is important since most other solutions for this problem would have involved opening new tiles in buffers, which can get unclear when doing too much.

  • Development Log Week 67

    Sorry for releasing this issue of our development log so late, but we were busy polishing Prosperous Universe until the last minute. Not saying we’re crunching…just maybe working a tad more than usual. We really want to get that Alpha done, though!


    I dealt with a diverse range of topics this week:

    First, I continued where I left off last week and connected Prosperous Universe to our account management backend. This went surprisingly smoothly so I had more time left than originally planned.

    That extra time was spent on something that I had been planning to do for weeks but never got around to: Rebuilding the “frame” of our UI. We’ve been talking about our tile-based UI on this blog quite a few times in the past, so you probably have a rough idea of what it looks like. Essentially, everything you can do and see in PU happens in a tile. So obviously, the more tiles you can fit on a single screen, the more you can do and see. I had this idea stuck in my head for ages now that I wanted to have the frame to be as slim as possible and to allow players to completely hide any parts of the frame they don’t need. I also wanted their preferences to be stored with each screen - a view of tiles a user can save - so whenever they switched to a different screen, the frame would still be configured the way they left it. This allows for maximum utilization of screen space and looks rather awesome in fullscreen mode with a multi-monitor setup. I hope to be able to show a photo of such a setup soon!

    Last but not least, I took care of a few smaller issues that were bothering me but so far didn’t have as much priority as or main features, namely some design adjustments in our login and company registration process as well as a few helpers around commodity exchanges. At the moment, it is almost impossible for someone who has never seen PU before to do anything in the game, simply because they’d have no idea where to look. Obviously, this has to change before we can let external testers have a go at the soon-to-be-completed alpha version, so more of this “smaller stuff” will be dealt with over the coming weeks.


    I am still working on minor issues and improvements that have been piling up over the past months of development. One particular thing is the state we display when a ship charges its faster-than-light engines. The flight model works like this:

    If you want to send a ship to a distant star system, you select a route and how much reactor power you want to use and hit the send button. Right before the ship starts the actual flight to the next system it has to charge up its FTL engines and that can take a while (depending on what kind of engine you have).

    Up until now the ship would have been listed as in transit from the moment you hit the button until it reaches the next system. The icon in the map would switch to indicate that the ship is in transit but it wouldn’t move because it is still charging. This was quite confusing, so I changed it. There is a separate icon now to represent the charging state and the list of ships will display it as well.

    In my opinion these little details are essential for a good game. They help to keep the player in the suspension of disbelieve and indirectly explain the underlying game mechanics.

  • 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.