It's been really hard to keep our mouths shut about this over the past few months: Lacuna is launching on PlayStation 4/5 as well as Xbox One and Xbox Series X/S on December 21st, and on Nintendo Switch on December 28th!
The game will be the same across all platforms, but if you've been holding out for its console release or want to give it another go, treat yourself this Christmas! There will be a 20% launch discount on Xbox and Nintendo Switch as well.
Read all about the consoles launch and more on our blog.
This might be my final update to this thread. Our next game is already in the works, I'll start a new development log once it's been announced!
Our game studio DigiTales Interactive (creators of Lacuna) is looking to grow from 4 to 6 people, starting with our next adventure game project early next year. We look forward to your applications!
Please note that the 'contract work' flair isn't perfectly accurate. This is a regular employment, but part-time.
Working at DigiTales
We do our best to make DigiTales a good place for everyone here. Jobs are varied and creative, and everyone has their own responsibilities. We sometimes play and/or party together, but we respect each other's boundaries. (We're not 'family', your family's your family!) Work hours are flexible. We managed to make our first game crunch-free and release it on time, let's make that a trend. We offer many office amenities including two adorable pugs, a shared floor with some other cool indie devs (but our own office), and home office every Wednesday. Also, Saarbrücken is great! It's a vibrant, young, friendly, and relatively cheap city to live in. If you need to move, we'll help you find a place. We look forward to hearing from you!
No matter which position you are interested in, it's a plus if any of the following applies to you. If you do not check some or even most of the boxes for a position (except for legal requirements) but feel like you are right for the job, please apply regardless! Your skills and personality are more important anyway.
Able to speak, read and write English and/or German more or less fluently.
Interest in video games, particularly adventures.
Not (too) allergic to dogs since our QA department consists of two pugs.
Prior employment, experience, or interest in game dev, including different disciplines.
If you have a portfolio, work sample, or prior shipped project(s) to show off, that's the most interesting stuff you can send us! (Please avoid sending huge files via e-mail, though.)
We value a diversity of opinions and positions as much as any other type of diversity. However, some 'opinions' are dumb and wrong, and bigots don't have a place at DigiTales.
Our game studio DigiTales Interactive (creators of Lacuna) is looking to permanently grow from 4 to 6 people, starting with our next adventure game project early next year. We look forward to your applications!
Working at DigiTales
We do our best to make DigiTales a good place for everyone here. Jobs are varied and creative, and everyone has their own responsibilities. We sometimes play and/or party together, but we respect each other's boundaries. (We're not 'family', your family's your family!) Work hours are flexible. We managed to make our first game crunch-free and release it on time, let's make that a trend. We offer many office amenities including two adorable pugs, a shared floor with some other cool indie devs (but our own office), and home office every Wednesday. Also, Saarbrücken is great! It's a vibrant, young, friendly, and relatively cheap city to live in. If you need to move, we'll help you find a place. We look forward to hearing from you!
No matter which position you are interested in, it's a plus if any of the following applies to you. If you do not check some or even most of the boxes for a position (except for legal requirements) but feel like you are right for the job, please apply regardless! Your skills and personality are more important anyway.
Able to speak, read and write English and/or German more or less fluently.
Interest in video games, particularly adventures.
Not (too) allergic to dogs since our QA department consists of two pugs.
Prior employment, experience, or interest in game dev, including different disciplines.
If you have a portfolio, work sample, or prior shipped project(s) to show off, that's the most interesting stuff you can send us! (Please avoid sending huge files via e-mail, though.)
We value a diversity of opinions and positions as much as any other type of diversity. However, some 'opinions' are dumb and wrong, and bigots don't have a place at DigiTales.
Thank you very much! I'd love to tell you more about the GOG approval process, but our publisher handled that side of things entirely. We only needed to submit a build a few days ahead of the game's launch, which was manually approved by someone at GOG. We used their Build Creator tool, which looks complicated at first, but is actually really fast and simple to handle after you did it once. That's all I know, unfortunately.
At long last, Lacuna is out now on Steam and GOG! We can hardly believe it ourselves. Thank you all so much for your support thus far, and for patiently awaiting the game's release. Check it out:
If you want to support us, please consider recommending the game to your friends and leaving a positive review. If you're on the fence about getting it, remember that there's an hour-long free demo both on Steam and GOG.
You know us, we have a new trailer for every occasion, and the release is no different!
The game actually came out over two days ago, but there was so much going on since release that I didn't have time to post the news sooner. It's sitting at 96 Steam reviews already, 96% of which are positive. On its first day alone, the game sold a four-digit amount of copies and had over 5.000 viewers on Twitch. Needless to say, we are extremely happy about this very favorable reception.
We are also really, really exhausted. The weeks leading up to the release were very stressful, and we're only slowly recovering. We'll be around for a few more days to monitor the forums and release patches if needed, then we're going on vacation for a bit. We'll be back in mid to late June to start pre-production on our next project, which I'll open a new thread for.
It contains the same levels as the demo we released during the Steam Game Festival earlier this year, but there are two major differences: 1. It is much more polished, featuring new art, music, sound design, and mechanics. 2. It has a dedicated page, so you can leave a positive review if you liked it. This way!
That's right, screw "summer 2021". We're pulling what's called a reverse Duke Nukem Forever and releasing the game earlier, less than a month from now! If you haven't already, wishlist Lacuna here.
We hope you enjoy the Prologue and we can't wait to share the rest of the game with you!
2020 has been an eventful year for many of us, for better or (mostly) for worse. Here at DigiTales, we were able to hire our first full-time employees in January, and we officially announced our debut title Lacuna in summer. We have been relatively quiet about it ever since – until now!
ALMOST CONTENT-COMPLETE
With Lacuna being a linear game that only has a handful of mechanics, a large part of our work has been the implementation of its complex story. The flowchart below provides a high-level overview over all the scenes, cases, central clues, and ways in which the player may influence the development and outcome of the story. I blurred it to avoid spoilers:
The very first version of the story existed all the way back in 2015, and the chart has evolved alongside it ever since, finally hitting version 1.0 the other day. Now all that's left is some fine-tuning like tweaking the wording, refining the character arcs, and sneaking some more world building into the dialogs.
In terms of the story's implementation, we have good news to share as well: It's all in the game already except for the finale and epilog! We're expecting to finish the story's implementation up within the next three months, with a projected word count of about 60.000.
DEMO EARLY 2021
That's right: Lacuna will get a free demo! It's hitting Steam in early 2021 and will be available in English, German, Korean, Simplified Chinese and possibly more languages at launch. In fact, its translation is already in the works. If you don't want to miss it, come back to our Steam store page some time in February.
PLAYTEST SIGN-UP
We're running a big playtest over the holidays, which will include the first two of Lacuna's three acts. If you want to help us out as a tester, please sign up here. Please make sure to only sign up if you'll be able to commit a few hours between Christmas and early January. If you've registered before, you're still on the list! Unfortunately, we cannot guarantee that everybody who signs up can be included.
VISUAL UPGRADES
In light of the upcoming demo, we've taken another hard look at Lacuna's visuals and decided that they could be even shinier. More specifically, we decided to add character portraits, cutscenes, and a bunch more VFX.
These are the portraits of most people you will encounter in the demo. Each of them has a set of facial expressions for their respective dialogs. The portraits are being created by the amazing Martina, who has been nice enough to make some time for us between her projects at Radical Fish Games.
One thing we noticed while playing other adventure games for research was that occasional cutscenes go a long way in setting a mood, breaking up the pace, alleviating visual fatigue, and just increasing the perceived overall quality of a game. That's why we asked the incredible Weilard to create six beautiful animated cutscene sprites for Lacuna. He finished the first one the other day:
But that's not all. Additional particle, shader, and other visual effects created by our fantastic shader magician Simon over the past few months have elevated Lacuna from a pretty pixel art game to a veritable visual feast, if we may say so ourselves. Leaves blown by the wind, fog billowing on the water, fire, smoke, rain, leaves, reflections, and more really bring its atmosphere to life.
NEXT PROJECT
Even though we will be working on Lacuna for a few more months, we already need to think about what we'll do next in order to avoid too much downtime between the projects. That's why we've already cooked up a new concept we're going to turn into a prototype next year. To that end, we recently received €20.000 in funding by Game Base Saar (a local funding program)! Here's a tiny sneak peek, we don't want to give away too much:
I almost feel bad for writing this, but 2020 has actually been a good year for us overall. The death, despair and political turmoil around the world have of course affected us and the social isolation is getting us down, but we're also aware of and grateful for the privileged positions we're in. We were able to switch to home office indefinitely without fear of exposing ourselves to the virus every day or losing our source of income. We worked on our game full time, which is a dream come true, and mostly managed to stick to our deadlines, a rare occurence in game development and much more so for a debut project. I'm really proud of what we've achieved this year despite everything that 2020 has been throwing at us, and I can't wait to see what we can do once things are back to normal.
Anyway, make sure to sign up for the playtest if you want, and keep an eye out for Lacuna's demo in early 2020. Also, subscribe to our newsletter to get future updates like this delivered to your inbox! We use it very sparingly, promise.
We wish you an adequate holiday season given the circumstances. Things are about to look up, I'm sure of it. Stay safe, merry Christmas, happy New Year, see you in 2021!
The game is not going to have an Early Access phase, we're planning on a full release right away. We run regular closed playtests to avoid nasty surprises as best we can.
Lacuna devlog #1, pt.2 Detective Game Design: Puzzles vs. Story (Practice)
Puzzle example This has been a lot to take in, but hopefullly it'll all become crystal clear when put to concrete use! The following is a level the player encounters early on in Lacuna. It won't reveal much of importance about the story, but it will spoil the solution to this one puzzle, so consider yourself warned.
Since this is essentially the game's first puzzle, it won't contain some of the difficulties added later (like a large number of channels communicating potential evidence). In harder cases, the player will need to have paid attention to testimonies, news articles etc. from earlier levels to arrive at the correct conclusion, and some cases span multiple levels. Not this one, though; all the information required to solve it is directly contained in the clues and dialogs of the one level where it starts and ends.
The puzzle Here's what happens: Our protagonist Neil is called to a crime scene to investigate a murder. His colleague Gary explains that a sniper must've taken the fatal shot from one of the opposite highrisers. He mentions that one of them, the casino, is holding a large event with lots of security, so it probably wouldn't have been the sniper's first choice. Neil is also told that the bullet hasn't been found yet.
At this point the player is given the Case Sheet, allowing them to submit their solution at any time from now on. This way, the player cannot know when exactly they possess enough information to solve it correctly. It also allows them to just submit any random solution if they completely get stuck and want to get on with the story. The Case Sheet simply reads "The shot was fired from ____", which doesn't spoil the solution while also formulating the question very clearly. There are only four options to pick from, which does make the answer more guessable, but we decided that was acceptable for the first puzzle, especially given that the player has only one shot.
The player can now walk around the building freely, investigate objects and talk to witnesses. Some of what they learn may be fluff, world-building, or even red herrings, but some is important evidence. The body lies out on the balcony, from where four buildings are visible: Gadle Hotel, Pixie Casino, Sakura Hotel, and Rocket Tower (from left to right). By investigating them, the player learns their approximate distance to the balcony. The position of the body, head to the left, already indicates that the shot probably came from somewhere on the right. A witness inside who saw the body hit the ground corroborates this.
The player may notice that they can also investigate a cupboard next to the balcony door. Its description states that the bullet disappeared into the wall on the other side and that it is locked. Investigating it unlocks a new dialog with a witness who gives the player the keys. They open up the cupboard and find the bullet. Neil's colleague takes a look at it and surmises that it came from a rather small and quiet rifle that cannot shoot accurately over distances greater than 200 meters.
The player asks for the key in the newly available dialog
Gadle Hotel probably appears unlikely at this point because it's too far on the left. The casino is also on the left and would additionally be a bad pick due to its increased security that night. This leaves Sakura Hotel and Rocket Tower, only the former of which is close enough to be plausible. (Remember that the player learned both the rifle's effective range and each of the buildings' distances to the balcony earlier.) At this point, the player may decide they've seen enough and submit the Case Sheet.
Processing the answer Now the game evaluates if the player got the answer right. If so, that's perfect: The player's correct answer causes the story to continue, and they head off to Sakura Hotel to look for the sniper. But how do we handle it if they picked one of the other three buildings?
You might be thinking that we could prevent the Case Sheet from being accepted until it's correct. Although not unheard of, that's a bad idea because:
It allows brute-forcing. And if it didn't (by introducing combinatorial explosion), it would allow getting stuck.
It doesn't make sense that the Case Sheet or the person reviewing it knows the right answer and is withholding it.
Then how about we trigger a game over state if the submission was wrong? Having to replay the level would at least discourage brute-forcing. The thing is:
We're trying to avoid game over states since they break the immersion (in any game).
It's frustrating chicanery; remember that we want people to be able to get on with the story whenever they want.
It contradicts "no takebacks". You submitted the wrong answer, you should have to live with it.
Okay, next idea. We could make all the incorrect buildings levels of their own and have the player go there to eventually realize they're in a dead end... But we shouldn't, for a number of reasons:
It destroys the story's pacing.
It's a lot of extra work most players will never get to see.
The player may take a long time to realize they're in the wrong place and will then have to be steered in the right direction anyway.
It can't possibly be applied to later cases, where Case Sheets allow for 256 (4x4x4x4) or even more possible answers.
As is the nature of game design, what we did end up doing is the least bad solution with the most acceptable drawbacks. Here's what happens: If the player picked the wrong building, everything seems fine until they get into a train to their destination. They then get a call about an anonymous tip made by someone at Sakura Hotel and are told to go there instead. This tip (and especially the reason for it being anonymous) is itself a piece of evidence for the puzzle at the hotel, already setting up the next mystery. This hopefully somewhat turns the attention away from the fact that the player just got railroaded back to the correct path. The player is also told that someone else from their squad will follow up on the building they (incorrectly) selected, and they will later learn that it turned out to be a dead end. Plus, Gary will make a snarky comment about the player's misstep in the next level. These are some small ways to make the player feel like their decision wasn't completely irrelevant.
And in fact, it wasn't: Here's where cascading consequences come in. Each and every correct puzzle solution throughout the first act may produce a piece of evidence relevant to the act's overarching case. This means that every incorrectly solved case makes it more likely (or even inevitable) that the player will fail the bigger ongoing case. Failing the first act's overarching case will in turn lead to information not being obtainable in the second act, which in turn prevents the player from getting one of the two "best" endings to the game. This cascading system makes sure that even small failures can have big consequences even though the player is immediately railroaded into the correct path at the time of their misstep.
Of course, this wouldn't be game design we're talking about if these cascading consequences didn't come with their own set of problems. Most notably, the player may find it unfair or, even worse, not realize at all that they cannot know the solution to a later puzzle due to having failed an earlier one. But although we have come up with some solutions for this problem as well, let's not go down that rabbit hole today.
Have a look at this censored overview of just the second act: bubbles are scenes, and the thinner lines between them represent only the most important (cascading) consequences
Did we stay true to our design? Let's quickly go over all the solutions and principles mentioned in the first half and see if we managed to apply them to our case.
Lacuna's design principles No takebacks? Check. The player has one shot at submitting the Case Sheet and will have to live with the consequences. Limited feedback? Check. The player isn't told (right away) if their answer was right or wrong, even though they're always sent to the right building. What about no getting stuck, did we apply any of the provided solutions? Did we make the puzzle easy? Yes, but only because it's an early one. Did we decouple story and puzzle progress? Yes, the player can always submit their Case Sheet, which ends the level and starts the next one. Did we make branching content for different solutions? Yes, in two ways: small changes in dialogs and, more importantly, our system of cascasing consequences. Did we provide hints? Sort of. We did the two things described above: use Highlight Mode and redundant information. Let's briefly talk about how exactly:
Highlight Mode, which enables colored outlines on evidence and people holding new information, is explicitly introduced at the start of this level. It helps the player notice a number of important things: that they can investigate the cupboard; that a new dialog becomes available once they start looking for the key; and after that dialog (in which the player obtains the key), that the cupboard holds new information because it can now be opened. Highlight Mode also acts as an indirect way of telling the player that they can solve the puzzle and stop looking for clues at a certain point, as there are no colored highlights left on any of the people or objects. Of course, Highlight Mode is optional, so players who like a challenge can just leave it off.
There are also some redundant pieces of information. For instance, the player might already have the idea that the sniper was somewhere on the right based on just looking at Banny's body. However, the dialog with the secretary confirms this again. Similarly, the player might think that Pixie Casino is far enough on the right to still be a possibility, but Gary telling them about the increased security there should make it clear that it's not the right answer.
Detective game problems Now for the detective game problems and their solutions discussed above.
Did the game communicate on many channels? Not particularly since this is an early, easy case. The player only has investigatable clues and witness testimonies to work with. Did the player communicate back on few channels? Yes, the solution to the case is submitted via one central mechanic, a Case Sheet. Did the player communicate only the solution? Yes, the Case Sheet does not ask how they arrived at the conclusion. Did the player have big freedom communicating the solution? Not really, but we found it acceptable here as there's still only a 25% chance of guessing it. A high number of solutions is much more crucial for games that allow infinite retries and thus lend themselves to brute-forcing (instead of giving the player just a single shot like Lacuna does).
Final thoughts Detective gameplay is hard to get right and it's naturally at odds with a game's story in a number of ways. We're lucky to be building upon so many experiments by countless other game developers teaching us what works (and what doesn't), and it's our hope that we've mixed an interesting and unique cocktail of ideas that will keep you engaged and entertained throughout our game. If you want to see for yourself, wishlist Lacuna now and give it a spin when it comes out.
If you have any thoughts on the topic or resources to share, let us know! We're happy about any opportunity to nerd out about game design.
Lacuna devlog #1, pt.1 Detective Game Design: Puzzles vs. Story (Theory)
Welcome to Lacuna's very first devlog! Let's catch you up on the past five years of its development.
Just kidding; Lacuna's first prototype did exist back in 2015, but we'll spare you most of the details of its long journey. The first few devlogs will each give you an overview on a certain aspect of development, and we thought that game design might be a good way to kick off the series.
Gameplay Since the game isn't out yet, we want to start by telling you what it will generally be like. Let's attempt a description without marketing lingo: Lacuna is a story-driven adventure game with platformer controls and investigation elements. Its four fundamental gameplay types are dialogs (with choices), moving around, examining objects, and solving puzzles. All of them are staples of the adventure genre, especially point & click games, but each one is a little different than you might expect:
Dialogs in adventures often loop back to one central node where the player can select all the options they didn't previously select. In Lacuna, each dialog can only be played a single time. Dialogs branch based on player decisions, which oftentimes lead to consequences later in the game – some big, some small.
Movement in Lacuna can be described as "platformer controls without jumping". Pointing and clicking tends to feel too strategic, somewhat removing the player from the action. We found a direct control scheme (using WASD or a controller) more modern and immersive. However, since the game is primarily aimed at people interested in experiencing the story and solving puzzles, Lacuna never demands quick reactions or precise hand-eye coordination.
Examining is one of the basic actions of any P&C adventure. In Lacuna, the player uses Investigation Mode to investigate nearby objects that might be of interest. They are recognized and highlighted automatically because we don't consider searching things a particularly interesting type of challenge. Having a defined array of available objects to toggle through also lends itself to controller-based input (more than being able to select any pixel on the screen hoping it will react in some way).
Puzzles in adventures are often self-contained mini games testing the player's dexterity or logical thinking. Alternatively, especially in P&C games, they involve handling and combining items. Both types have a tendency to not make sense in the game world and/or not tie into the story in a meaningful way. By contrast, all puzzles in Lacuna are mysteries directly arising from the story and dialogs. The player solves them via dialog choices, investigating evidence, and ultimately via a central mechanic dubbed Case Sheets (more on all those mechanics in our example down below).
This is the game's first Case Sheet, very short and to the point
Game Design principles From the very start, we laid out some design principles we've been trying our best to follow ever since. Some of them have become somewhat apparent in the previous paragraphs (e.g. unique dialogs, story-focused puzzles), but there's a few underlying, abstract ones worth highlighting.
The first one is no takebacks: We wanted to make choices and their consequences front and center in the game's design and story. We felt like manual saving and loading would take away from that, and we opted for an automatic save system instead that always overrides your previous save file (in that slot). Non-replayable dialogs as described above were another consequence of this design principle. Not being able to go back might be frustrating at times, so to somewhat make up for it, we created three save slots allowing for multiple concurrent playthroughs. Plus, the game only saves after each level (i.e. every few minutes), so if you immediately regret something or made a choice by accident, you can undo it by reloading the level right away.
We also decided to give the player very limited feedback. As much as we like some of Telltale's titles, we were never fans of "x will remember this". It yanks you right out of the action by giving you explicit information that your avatar doesn't have (and that seemed to mostly be a smokescreen anyway). Lacuna gives no hints of this sort and doesn't disclose which decisions matter more than others, quietly adapting to the player’s behavior. That being said, the reasons for certain consequences need to be made clear later to mitigate frustration.
There are some more principles related to writing, but they're a topic for another day. Let's skip ahead and get to the big one. It's so big, in fact, we need to give it its own headline:
No getting stuck This design principle has been making our lives so much harder (but our game better) ever since we came up with it.
The thought process behind it was simple: In games with both a story and puzzles (e.g. most P&C games), story progress is almost always tied directly to puzzle progress. Until you solve the puzzle at hand, you don't get to see the next part of the story. For some players, especially those most interested in the story, this can become a problem. If they're stuck for too long, there's a chance they'll just drop out and never pick the game up again. Even if that doesn't happen, hard puzzles always run the risk of messing up the story's pacing and interrupting your immersion in the game – because you're becoming frustrated or, even worse, because you decide to tab out and Google the solution. To avoid people getting stuck, we considered a number of solutions:
Solution 1: Make the puzzles very easy? This isn't our favorite since it somewhat defeats the purpose of puzzles. They'd still play a role as a change of pace now and then, but if puzzles aren't a little hard, nobody will feel like a detective solving them. Some early puzzles in Lacuna are easy, but most aren't.
Solution 2: Provide hints? Hint systems can be found in many adventures featuring puzzles. Unfortunately, they often take the player out of the experience in one of three ways: In some cases, the hint is provided by extradiegetic UI (e.g. in the pause menu) and therefore seems to come out of nowhere in the game world. In other cases, the player character is the one giving the hint, disconnecting the player from their avatar’s perspective. The third option of NPCs providing hints is a little better; however, it is often hard to justify why an NPC would be able to point the player in the right direction without possessing the rest of the solution to the ongoing puzzle (and why they didn't volunteer it in the first place). The two types of (sort-of) hint systems we went with in Lacuna are Highlight Mode, which displays optional outlines around objects and NPCs that hold new information, and redundant information, meaning that sometimes the player is given two ways of obtaining an important clue.
"YOU ARE PLAYING A GAME RIGHT NOW"
Solution 3: Decouple story progress from puzzle progress? Why not simply make a story-driven game throughout which the player can solve the occasional puzzle if they feel like it? Well, because it would require that puzzles be somewhat detached from the story. As a result, they run the risk of feeling meaningless since solving them is not rewarding and failing is not punishing. However, this can work quite well when combined with...
Solution 4: Make branching content for different solutions? Instead of impeding the player’s progress, wrong or missing puzzle solutions could lead to a less desirable continuation and/or outcome of the story. Unfortunately, creating a new story branch for each and every wrong solution to a puzzle is hardly feasible. However, there are less extreme ways of realizing this. For instance, the game could account for the player’s overall puzzling performance at certain points in the game, e.g. trigger the “good” finale to an act if they got more than x% of the puzzles right, and the “bad” one if not. There could also be cascading consequences of sorts, e.g. solving one case correctly may give the player an edge in a later one. These approaches have similar downsides as optional puzzles do, but to a lesser degree; puzzle success no longer being required for progress makes them feel more detached from the story and removes immediate feedback. Regardless, we have found this to be the best solution, which is why we employ it quite a bit in Lacuna (while trying to avoid all the pitfalls). By the way, if all of this is becoming too abstract for you, bear with us! The second half of this post is all about a real example from the game.
Detroit: Become Human offers an astonishing number of different outcomes depending on player action, but not everybody has that kind of money to burn
Despite all of these measures being taken to make sure that the player won't get stuck, Lacuna can still be called a hard game. While it's not difficult to get to the end, it's pretty difficult to get a good ending and not mess things up on your way there. In other words, rushing through the whole story is possible if you don't mind bringing it to a terrible conclusion.
Detective game problems Many of the problems we encountered when designing Lacuna are as old as detective games themselves. Most of them are centered around how the player and the game communicate with one another, and especially how the player conveys their thoughts to the game. Several principles have proven to make for a good experience (across countless approaches to this problem over the years), some of which have made their way into Lacuna:
Principle 1: Many channels out, few channels back in. If the game conveys information to the player on many different channels and in many different ways, the process of piecing the solution together tends to feel more interesting and rewarding. In Lacuna, the player picks up clues from dialogs, objects, environments, the news, and e-mails (with all sorts of attachments). At the same time, the channels via which the player communicates that solution back to the game are kept to a minimum, namely Case Sheets and (to a lesser degree) dialog choices. Having one or two central mechanics for player input makes the experience more coherent and transparent and facilitates designing the mysteries around it.
Return of the Obra Dinn by Lucas Pope provides a bunch of different sources of information, but just one central mechanic for the player to communicate back to the game
Principle 2: Have the player communicate only the solution. It is near impossible to create a system through which the player communicates to the game how they arrived at a solution. Luckily, this is not necessary. A well-designed puzzle provides all the information, then moves the entire solution process solely into the player’s head, and finally prompts the player to input only their answer. The player’s objective should be stated clearly, but in a very general way at the start of a case (e.g. “find the culprit”).
Principle 3: Give the player maximum freedom in communicating the solution. The way in which the player communicates the answer to the game is the most crucial part to get right. One aspect is to give the player many choices (or a large combination of choices) to pick from. Two things should be avoided: 1. Giving the player a high probability to succeed by picking a random answer. 2. Making it easy for the player to guess correctly because only one or a few of the available answers appear plausible. An example for a bad solution like this would be to give the player three dialog choices to solve the puzzle; even worse would be if one of them obviously made the most sense. A better approach would be to give the player a cloze text (which is what Case Sheets boil down to) with a bunch of plausible options for each gap. Another possibility is to have the solution be an unguessable string of characters that the player needs to enter manually. Both ideas utilize combinatorial explosion to make guessing and brute-forcing nearly impossible, and both of them can be found in Lacuna.
Good luck brute-forcing your way through Detective Grimoire's cloze texts
Hi! I'm Julian, co-founder and CEO of DigiTales Interactive. I posted a bunch of devlogs here before but for the first I've brought my very own game: Lacuna! It's is a dialog-driven detective adventure set in a 2D sci-fi noir universe. It's coming out summer 2021 on Steam, published by Assemble Entertainment. Find out more on its Steam page and in our first development log below.
Here's the deal You are Neil Conrad, CDI agent. Awoken by the news of a murder, you rush into a case that will soon turn your life and the whole solar system upside down. Ask questions, collect evidence, and put the pieces together until the ugly truth reveals itself... or not.
No takebacks The story branches and ends based on your actions. There's no going back. Sure, you can rush your way to the end – if you don't mind paying the price. Play your cards right, and you might make it out alive.
How far will you go? Some questions don't have a right answer. Will you sell out a friend to protect your family? Will you endanger a loved one in exchange for public safety? Will you keep the peace or reveal the horrible, world-shattering truth?
Here are some screenshots:
If you want to stay in touch, here's some social links. We gladly follow other indies back!
In today’s development log, you can catch a glimpse at what happens when the rental fees for your storage unit are late. Also, simulogics is still looking for a UI/UX designer and a frontend web developer!
Martin
One could sum up my primary activity this week in two letters: HR. I spent a lot of time on interviews with candidates for our open UI/UX design and web development positions. Which is a good thing because it means that we received quite a few applications. This process will likely continue next week and possibly a little bit beyond that as well.
I also did some preparations for the arrival of Julian’s successor next Monday. So yeah… pretty much HR all the way.
Michi (molp)
I finished the warehouse storage feature this week. Although one piece is still missing, it is not vital for the release of the feature and so I decided to start on the shipping contracts and see if there is enough time at the end to finish it as well. Here is a quick screenshot of the current state of the warehouse tile:
As you can see, I changed a few things since I showed it last. The rent unit and cancel unit buttons are now in two separate areas, there is some information about the amount and the receiver of the fee and a countdown that indicates when the next weekly payment of the warehouse rental fee is due. In this particular instance, the player missed the payment (due to missing funds) and the storage unit is now in a locked state as opposed to its normal operational state.
If the fees are not paid, the inventory will be locked until it can be paid. While it is still possible to see the contents of a locked inventory, it is not possible to add or remove any items from it:
Of course the governor of a planet can control the storage rental fee just like the local market and production fees. I added the warehouse rental fee to the local rules LR command.
As always: we’d love to hear what you think: join us on Discord or the forums!
This week, the team launched a new job search for a Frontend Web Developer and a UI/UX Designer. Read all about the new positions here!
Martin
As you might know, we searched for and eventually found a frontend developer to help out with Prosperous Universe development in late 2019. He was supposed to start in January, but due to an unfortunate series of events, that didn’t happen and now - almost two months later - he skipped out on us.
Needless to say, this puts us in an unfortunate situation. We more or less wasted several months, postponing the whole project we received funding for in December. And since we are essentially back to square one in our search for a suitable candidate, we also don’t know when we can actually get started on it, let alone finish it.
Anyway…things are as they are and we’ll try to make the best of it as usual. So I invested many hours this week into finding new candidates and I am glad to say that we already got the first bunch of interviews scheduled for next week.
It’s unlikely you haven’t seen them yet, but just in case: You can find out job ads here.
All that aside, I managed to get some rather technical work done on the game itself, namely some tooling and language upgrades. So nothing to write home about.
Michi (molp)
Just a quick update from me this week: I am still working on the server side of the warehouse storage feature. It is now possible to cancel a storage unit and once the last storage unit is canceled the whole store disappears. Canceling a unit will only be allowed if there is still enough free storage available for all things in the inventory and the last storage unit can only be cancelled if it is empty. After that I started to work on the payment process for the weekly rental fees. This is work in progress and I hope I can show you an updated user interface for it next week!
Fabian (Counterpoint)
I’m happy to report that the plans I talked about in the last devlog came to fruition this week. We discussed the direction of the post-Presence release and I’m working on refinements to the high-level concept right now. I also finalized the mentioned balancing changes regarding market maker prices, nutrient solution output and hydroponics recipes, and of course added Rubicate’s mushrooms as a new commodity.
Besides that and as usual, I kept an eye on the community’s “hot topics”, too. This week one of those was the additive nature of production bonuses. After looking into it for a bit, we indeed found them to be quite problematic, especially in more extreme cases. You shouldn’t really be able to run a severely understaffed production line while providing nothing but drinking water to your workforce for example. So you can expect some changes here in the not too distant future (most likely resulting in production bonuses being treated as multipliers instead of flat bonuses).
As always: we’d love to hear what you think: join us on Discord or the forums!
This week, the team has been integrating the new warehouses into the planetary inventory system, which required a bigger rework than one might think. Meanwhile, the big release after Presence is already taking shape.
Michi (molp)
I continued to work on the warehouses this week. Last week I showed you the user interface that allows to rent storage units and while it seems almost finished from the UI perspective there is still a lot of work to do on the backend. I started by actually generating a new store once the player rents a storage unit for the first time on any given planet. Of course, the capacity of this store needs to be adjusted when another storage unit is being rented. Multiple units at the same warehouse are combined into one logical store, that way it is way more comfortable to use by the players.
With the warehouses in place, it is now possible to have more than one fixed (e.g. non-ship) store at a given location, the store that comes with a base and a warehouse storage unit. This sounds trivial, but it has implications: For example, there is the INVP command that shows the inventory at a given planetary location. Which inventory should be shown if there are two stores at a location? We decided to remove the INVP command in favor of a more flexible INV command!
The INV command can now be used in three different ways:
If there are no parameters for the command, a list of all stores (bases, ships, fuel tanks, warehouses) is shown. If the command has a planetary address as parameter (like INV XK-194c), it will either show a list of stores at that location (if there are more than one) or just show the inventory of the store. The command also accepts the store ID as a parameter (INV 3F2S) and will show its contents- I also added filters to the command which allow to show/hide certain types of stores. The filter settings are persistent if the command is used in a screen.
Fabian (Counterpoint)
This week I honed in on one particular version of the concept for the next big release after Presence. We’ll soon discuss it in the team and see if we agree on the general direction or want to make some changes.
In terms of Presence itself, I’m making up my mind about the before-mentioned balancing changes to MM buy prices. Expect agriculture to get a nerf and ores a substantial buff pretty much across the board. In addition, a couple minerals will be tweaked and construction prefabs brought more in line with one another. Another balancing topic I’ve been looking into that also came up in the Discord last week is hydroponics (HYF) vs. conventional farming (FRM). At the moment, HYF is a bit too inefficient, so we will make NS (nutrient solution) a little more affordable. There will also be some additional tweaks to the HYF recipes.
Last but not least, with Presence we will also add a new recipe to HYF! Our APEX PRO user Rubicate made use of the “Design a Commodity” perk. Soon you will be able to use your hydroponics farms to produce mushrooms of the Agaricaceae rubicatii family. What’s more, they won’t even require water as an input material and thus might open up some new possibilities!
Martin
Once again, a very short report from my side: While it’s rare, it happens that things go according to plan. And this week was one of those times. As discussed last week, I wrapped up my client-side work on “item support” for stores and handed over the changes to Michi. He’ll be able to implement the new shipping contracts based on this foundation.
I also spent quite some time on game design calls with Michi and Fabian as well as going over our reworked terms and conditions which we hope to finally get ready for release later this month.
As always: we’d love to hear what you think: join us on Discord or the forums!
Work on the Presence update has officially kicked into gear. Have a first look at the upcoming upgradable warehouses in today’s devlog!
Michi (molp)
I finally started to work on our next named release Presence this week! As usual with new features there is not much to show yet as I usually start to implement them on the server first and then move to the client. To be able to show at least a bit in this devlog I created the new warehouse command WAR and started to flesh it out:
The warehouse is a planetary project just like the existing ones and can be built on any planet without any dependencies. Once it is finished, the command shown above will be available. The upper half shows general information about the warehouse like its current operator (e.g. faction or the governor’s corporation), the current fees and how many storage units are available.
The ‘rental’ section contains company specific information, for example how many units have been rented, how much storage space is available and of course a link to the store itself. I will add more information to this section later, especially about the next due rent.
Finally, the last section will contain information about the current extension status of the warehouse. As stated in the last devlog, the warehouse will be extendable a few times to increase the amount of storage units.
Fabian (Counterpoint)
While the actual implementation work for the “Presence” release started this week, I pretty much fully focussed on coming up with ideas and conceptual drafts for the next, yet to be disclosed, named release. We’ll soon discuss its content more in detail internally, and once we clearly settle in on a design direction we’ll be able to share more with all of you.
In terms of the nearer future, I’m keeping an eye on market prices to finalize the MM balancing tweaks I mentioned a couple weeks back. Also, there were some interesting discussions and suggestion in the forums and on the Discord surrounding the topic of “order deletion penalties”. The intention there is not just to put a stop to “market maker” bots, but also to make being online all the time to undercut your competitors’ prices by a cent again and again less attractive. We haven’t decided on it yet, but it’s certainly an option and it’s great to see all those constructive debates. Keep the feedback coming!
Martin
Short and sweet: As Michi already discussed, implementation work on “Presence” commenced this week. My job right now is to get some rather fundamental changes into the game’s storage system. Right now, all stores in the game deal with quantities of materials only. But for Presence, we need to support discrete “items”, which behave slightly differently. Most of the respective server-side changes are done and my client-side work was focused primarily on getting everything back to work the way it did before the required changes to the data structures. Next week I’ll work on actually displaying and handling items in the client. Once that’s done, Michi can take over and implement the new shipping contracts.
As always: we’d love to hear what you think: join us on Discord or the forums!
In today’s development log, we’re addressing a few issues the past release brought with it – but more importantly, you’re getting a good look at the next, much bigger one!
Michi (molp)
It has been one of these weeks where you start with a clear plan: finish the maintenance release, release it, work on the new named release. But things never turn out the way you think. It is now Friday afternoon and I have yet to start working on the new named release. The backend release Martin mentioned and the maintenance release left us with a lot of unexpected bugs to clean up: hanging production lines, full ship inventories that have no visible cargo, just to mention two. But the good news is that we fixed most of the issues and therefore we got the maintenance release out of the way.
Speaking of releases, I thought it would be about time to introduce the next named release with the code name Presence!
Presence is all about local market shipping contracts that you have requested so many times. We want to keep it simple, keep the development time short and see how it turns out. If everything goes according to our plan (hint: it won’t) we will release the feature at the end of February, early March. Presence really consists of three main parts, one of which is rather technical:
The local markets will get a new ad type called shipping. A company looking for someone to transport some of their goods will be able to post an ad. The ad will share a lot of elements with the existing ads (commodity, amount, currency, price, delivery time, ad visibility) and introduce two new ones: origin and destination. With these components the creator of the ad can determine where the hauler should pick up the goods and where to drop them off. The requirements are that the principal must own fixed stores, e.g. no ships, at both locations and one of the locations must be the local market. Right now this would only be possible if the principal had two bases, which brings us to the next change.
We will introduce a new planetary project called warehouses (proper name pending) that works like a self-storage facility. Players can rent storage units that will work just like a storage building in a base. These units will require a weekly rental fee that is being set by the planetary governor. If the warehouse runs out of available storage units an expansion is possible up to a certain amount of times to increase the number of storage units.
The last change handles the representation of freight in a haulers inventory. The freight will be represented as a generic icon with a certain weight and volume so the hauler will not know about its contents. Clicking on it will open the corresponding contract. We might even use this method to display materials that are being provisioned for a pick-up condition to make it more obvious that they are still in the inventory, but blocked.
Fabian (Counterpoint)
This week was about nailing down the planning for the “Presence” release, including the balancing for the new planetary project and the gameplay possibilities it will enable. Other than that, I continued last week’s inquiries regarding a MM rebalancing for certain products, which should also find its way into said release. Finally, since research and concept work can’t start early enough, I already invested some time into thinking about the next big feature we have our eyes on after Presence. But that’s a topic for another day…
Martin
A little story from the trenches today, maybe a bit technical:
A lot (well, a couple) of confused faces could be seen in the simulogics development offices this week: After we rolled out my backend release which, if anything, should have introduced some performance improvements, we saw drastic decreases in performance across the board. All server nodes were using a lot more memory and the CPUs where running at more than twice the load compared to before the patch.
So I started looking for the cause. The problem in a situation like this usually is that you are missing exactly the kind of instrumentation you need at that very moment. In our case we saw an above-average amount of so-called “hydration timeouts” which basically just means that the client requested a piece of data that contains references to one or more entities (like companies), but that the information to display those entities (like a company’s name) could not be retrieved from the respective entity actor in time before the data is sent to the client. In that case, the general piece of data is sent to the client but the entity references are still just that: references. The end-user gets to see a “Hydration Timout” error message with the respective entity ID instead.
There are basically two reasons why such a timeout can happen: Either the respective entity is broken and therefore can’t reply to the request at all or it’s just busy and replies too late. When an entity is broken, it’s pretty obvious because we see the errors on the logs, and when it’s too busy, it is most likely because it is “recovering” (more on what that means in another devlog on the architecture of PrUn that I have promised for ages now). But because the latter has never been an issue before and we had optimizations to the recovery mechanism planned for the future anyway, we never put in any instrumentation to track how long it actually took.
After I hacked in a quick-and-dirty logging mechanism we realized that many entities take well above a minute to recover now, which in itself did not explain our problem, though: They surely didn’t start taking this long just this week. It must have been the case before and users didn’t notice any performance problems of this magnitude before the upgrade.
It took Michi’s shrewd eyes to notice that many entities would show up more than once. That’s weird because once an entity has recovered and it doesn’t get passivated for any reason, it should remain active in memory. So after many hours of searching, I found the culprit: A single configuration flag the default value of which has changed between releases of our actor framework. It just killed any actor after 2 minutes of idling, forcing our whole simulation into a constant state of reloading entities. After changing “120s” to “off”, the problem was gone. And so were many hours of my precious time…
Julian (Mjeno)
Hi, guys! I’d like to take a moment to say that I’m still with simulogics and will stay around until at least the end February. Apparently, some of you thought I had already moved on, but you’re not getting rid of me that easily. I just haven’t had much interesting to report over the past few weeks. Same this week, actually; I’ve been preparing a final round of interviews with my potential successors next week and spent a lot of time translating our new TOS and Privacy Statement. I know, fascinating stuff. (: See you next week!
As always: we’d love to hear what you think: join us on Discord or the forums!
We’re in between releases. The post-PC Gamer rush has ebbed away a bit and we’re slowly setting our sights on the next named release. But before that happens, Michi is shaping the upcoming maintenance patch into a big bundle of QoL improvements and bugfixes while Fabian continues to wrap his head around the complexities of the game, especially the different starting profiles and the general “new player” experience.
Martin
My week was kind of short and primarily focused on interviewing the first batch of candidates to replace Julian some time later this spring. Julian and I interviewed six candidates and almost all of them left a very good impression…it’s going to be a tough call!
On Friday I had the honor to speak at the 20th anniversary party of NLnet Labs in Amsterdam. I was invited to talk a bit about what we do and how we ended up doing it, which happens to be quite an unusual story going back all the way to 2002. The other talks were very interesting as well and the event as a whole was great fun. Thanks for having me!
That said, I plan to be back at actual game development (for once) next week, getting started on the preliminary work for our next named release. It’s going to contain some features that our players most certainly are going to love!
Fabian (Counterpoint)
This week I continued my “getting to know Prosperous Universe” month by delving (back) into the new-player experience. For example, I compared starting packages based on how clearly they suggest the first short-term goals to players, whether there are interesting choices to make right from the start and where players can go after following the recommended first steps. From my findings, some of the packages could use more love than others or maybe could be replaced entirely, but this is also a matter of making changes to the tech tree as a whole, so we’ll certainly get back to it later down the line.
Besides packages, I also went over the first-few-sessions experience and accessibility in general and compiled a long list of potential problems and suggestions on how to go about solving them. This is something we will discuss rather soon, since improvements for new players are quite high on our list, especially if they’re “low-hanging fruit”.
Lastly, I also took a quick look at MM prices and actual market prices for minerals and ores, which revealed a few balancing issues, especially in comparison with early-game agriculture. We’ll look into it further, but you can probably expect some balancing changes in the not too distant future.
Michi (molp)
I continued to work on the next maintenance release this week. We decided that we will release it on Thursday January 30th and you can check out the official release notes on the forums.
I kept all the boring bugfixes for this week, so there is not much to show. One bug is rather interesting and a few players tripped over it in the last few weeks: All currencies in the game have two decimal places but they are not shown everywhere. Usually one would use decimal places in FX or ComEx orders, but the sidebar, FINLA and other commands don’t show them for the sake of simplicity. The component that displays the amount of money is aware of the decimal places though and rounds up and down accordingly, e.g. rounds up if the fraction is >= .5. We received multiple reports that contractual payment conditions could not be fulfilled even though the players seemingly had the money. In the end the rounding was the culprit. The players were only fractions of a unit short, but APEX displayed the rounded up value.
As always: we’d love to hear what you think: join us on Discord or the forums!
This week, the team has worked on various tasks such as managing job applications, making a mental image of the game’s systems, and preparing an upcoming maintenance patch.
Julian (Mjeno)
First off, sorry for my absence last week. I didn’t really have much of interest to report and decided to quietly skip the development log for once. We had a call on Thursday in which I relayed quite a bit of community feedback to the rest of the team, most of which will be put through The Filter shortly.
The most important bit of my work this week was to get back to the first applicants to our PR & Community Manager job ad. If you applied for the job and haven’t heard back from me yet, I’m sorry - you’ve probably not made it to the shortlist. Chances are it’s due to a technicality; we’ve been going back and forth between our accountant and the ministry co-funding our development for the next year in order to find out what exactly the rules for the new position are. Unfortunately, we’ve now learned that the person would need to have a German employment contract, meaning that they have to reside in Germany. We don’t want to ask anyone to relocate across the globe, especially since the job would still be remote and our funding is secured for only a year. That is why we’ve been focusing on Germany and its adjacent countries in this first round of replies.
Martin
While Michi is working on the user-facing changes of our upcoming maintenance release, I continued to work on framework-related stuff. I mostly finished the migration to the latest version of the actor framework we use and spent some time ensuring that everything stills works as expected. As mentioned before, the side-effects of this upgrade are minor performance improvements and some additional instrumentation that’ll help us troubleshoot issues in the future as well as improve our deployment process (like shorter connection losses during upgrades). The latter will require some more work, though.
That’s about it for this week. My plan is to also dive into some actual game development for once before the end of the month and I seriously can’t wait for that to happen!
Fabian (Counterpoint)
As mentioned last week, I’m deep into the process of grasping the game as a whole. This includes pages upon pages of notes on existing features, upcoming ones and all kinds of things I notice while playing. And given us systems designers like to keep “mental images” of the things we work on in our minds, it also includes creating actual visual models. Given the game’s scope, these can get quite extensive…
Michi (molp)
I am currently working on a small maintenance update that we will release at the end of the month. As usual a whole list of issues, bugs and quality of life improvements etc have been piling up while we have been working on the last named release (‘Expanse’) and now is the time to work on these issues.
Here are a few examples:
When deleting the last building of a production line, the UI hangs and only a refresh of APEX will show the new correct state. I fixed that and deleting buildings works as intended now.
As mentioned last week, I doubled the amount of available plots on the three hub worlds.
Ever since we introduced the production fees, we received complaints from player that their production would not work for some reason and the next production order would not be started. This was in almost all the cases due to missing funds for the production fee. I included a new error message similar to the existing ‘input missing’ and ‘no capacity’ messages:
During the recent influx of new players, we noticed that base building is not as self-explanatory as it could be. After clicking the ‘start base’ button some players don’t know how to continue and it is not very obvious what to do. For example, if the PLI window is small, the UI overlaps the display of the planetary surface making the selection of a plot really hard. I decided to move the base building into its own window similar to the creation process of corporation projects. In this new UI, we have enough space to explain and guide the players. Here is a work in progress version:
As always: we’d love to hear what you think: join us on Discord or the forums!
This week was a very productive one, starting with a 3-day bootcamp at simulogics HQ and ending with some possible solutions to the current overflowing hub worlds.
Martin
There’s good news and there’s bad news this week.
The bad news first: As you probably know by now, the team came together for a three-day meeting at simulogics HQ. We are a 100% remote team and we only meet at a single physical location for important reasons. The reason for this week’s meeting was that two new members are joining the team: Fabian, who you’ve already read from and about in the previous issue of the devlog, and Frank, who was supposed to start this Monday. But due to a serious injury, Frank got admitted to a hospital the day before and will be stuck there for several weeks. Therefore, he obviously was neither able to make the trip nor to start working on the project. We wish him a speedy recovery!
But I tend to see the positive side of things, so here’s the good news: Because the frontend development aspect of the meeting basically fell flat, we had a full three days to focus on game design. And in hindsight, that was a good thing. The ideas and vision behind this project are vast, with a lot of very personal, arbitrary and hard-to-describe aspects to it that are almost impossible to write down in a style-guide, let alone in a brief vision statement. So just sitting down and discussing all these things was incredibly helpful. It will be hard enough as it is for Fabian to find his way into the world of PrUn as Michi and myself imagine it, but after this week, it should be tad easier.
Fabian (Counterpoint)
To me this week’s workshop was invaluable when it came to understanding the vision behind Prosperous Universe, as well as possible future directions. Besides discussing more fundamental questions such as what the game was, is and is supposed to be, we also touched on tons of current “hot topics” and feature ideas for the near and far future. The amount of knowledge thrown around was so excessive that I even learned about the difference between ducks and geese. Go figure!
Luckily we were able to resolve a few open questions for the next couple of updates which, at this point, aren’t that design-intensive anymore, so I can concentrate on working my way deeper into the game. Right now I’m drafting quite a few models and mind maps of basically every relevant gameplay element, the “big one” of course being the whole commodity production tree. In the latter half of the month, I plan to dive into the first design changes and drafts for future features.
Michi (molp)
Besides all the game design scheming that happened at our three-day meeting at simulogics HQ, we also talked about the very urgent issue of available planetary plots in the current alpha. As most of you know, the recent PC Gamer article led to a great influx of new players and the remaining plots at the three hubs (Montem, Promitor, Katoa) were taken pretty fast and there are still no free plots available. While that is, technically speaking, no serious problem since roughly 50% of all starting planet plots are still available, it has some implications for player retention. New players tend to start at one of the hubs because it is the easiest start one can have. If they start somewhere else, there is a higher risk of them not continuing playing.
To solve this problem, we thought of three solutions.
We will reduce the amount of time until we delete a completely inactive, new company to eight days. After three days, the players will receive an e-mail notification about the pending deletion and if they don’t react, the deletion will happen five days later. This will remove the companies of all players that just checked out the game and never came back. We will release this change with the next maintenance update.
We will also double the amount of plots on the three hub planets. The current alpha has been running for a long time now and there is no reset in sight. It was never intended to hold that many players, let alone the vast amounts after a spike like the one we experienced recently. That’s why we want to make room for potential new spikes in player count. This game design band-aid will also be released with the next maintenance update.
Finally we thought of a mechanism that will allow more planets to become starting planets in the future. This change might need a restart, though, and will therefore have to wait a bit. Once we restart the universe, we’ll also make sure to not make the the hub planets as strong as they are now. Maybe we might even turn the planetary commodity exchanges into space stations, so everyone will have to fly there. But that is all dreams of the future!
By the way, we expect that some of the plots will free up in the next week, so keep an eye on the hubs!
As always: we’d love to hear what you think: join us on Discord or the forums!
What a way to start the year! Fabian, our new game systems designer, joined the team, and a favorable review on PC Gamer expanded the community by a good 300%.
Martin
Similar to Michi, I spent my first working days of 2020 playing catch-up. The PC Gamer article caught us by surprise and while we didn’t face any fundamental technical issues - the servers seemed to cope with the influx quite well - the spike in traffic rattled the tree quite a bit and out fell several bugs that went unnoticed so far.
Also just like Michi, I did some preparing for next week’s kick-off meeting with Fabian and Frank (we’re changing the rules: new hires’ names have to start with an F instead of an M from now on). One of the main topics of the three-day meeting will be game design and the recent rush of new players and its side-effects (full exchange planets, for example) will be informing our discussions quite substantially.
Last but not least, I started work on the long-overdue chore of migrating our backend server to the latest version of the actor framework we’re using. It comes with a bunch of new instrumentations that should help with analyzing server issues, among other things.
Julian (Mjeno)
Happy 2020, guys! Imagine my surprise earlier this week when I joined the game and saw close to 300 connected users. Someone soon identified the PC Gamer article to be the source of all the new community members. So again, welcome to the new players! Happy to have you guys here.
For me, this meant a lot of support work, as some people didn’t get their confirmation e-mails, had their payments rejected, wondered why their license status didn’t update etc. Apart from that, we are still getting applications for our Community Manager job ad, which I’m still catching up on. If you applied a few days ago, don’t worry - we will get back to you very soon!
Fabian (Counterpoint) Hi! I’m incredibly excited to have joined Prosperous Universe as game systems designer this week. Given the complexity and uniqueness of the project as well all the documents and ideas I already went through the last couple days, it will be quite the challenge. That’s part of why I’m here though. It’s what makes things interesting in the first place, right?
For now I’m getting accustomed to the game, documentation and tools. Not least to prepare for the 3-day workshop we’ll be having next week. Really looking forward to meeting the team in person!
In case you’d like to learn more about who I am, find me on Twitter via @Ludokultur. My profile has all the links. Also don’t hesitate to contact me on our Discord if you have any questions (I’m the new guy with the dev role called “Counterpoint”)!
Michi (molp)
Happy new year everyone! I started this year with catching up what happened in the last week and a half. I tried to stay away as far as I could from any PC during the holidays and only checked occasionally what was going on the game via my mobile phone.
As you can image the PC Gamer article and the resulting influx of new players kept me busy for the rest of the week. These events tend to wash up errors and bugs way faster than during “normal” times and so I was bug hunting the whole time. We had one especially nasty bug that almost lead to a core meltdown and Martin and I had a hard time figuring out what was going on. We now have an idea what might cause it, but we do not have a definitive fix yet.
Besides all the bugs I spent some time preparing a meeting in simulogics HQ that will happen next week! For the first time Martin and me will meet the two new guys in person! More about that next week!
As always: we’d love to hear what you think: join us on Discord or the forums!
Show Posts
