Lessons Learned: Lost Ember Post Mortem – Part Two

Hello again! 

As promised, I’m back with more behind-the-scenes tips and tricks and this time especially with a look at everything that went wrong in the development of Lost Ember. If you haven’t read the first part yet, you can do so here and find your way back after.

For anyone else, let’s go.

If you’re working on anything for five years you can’t expect everything to go smoothly. During the development of Lost Ember we experienced a couple of minor and major setbacks that led to us having to delay the release more than once. 

These setbacks might come from simply realizing that what you have planned doesn’t work or from external factors you cannot really control. An example of the former is our realization that an episodic release wouldn’t actually mean less work and would even introduce new problems. We still would have to be absolutely sure that the story works, because after the first episode is released, we can’t change it anymore. And in order for us to be sure that everything works, we would have to have a playable version of everything to test whether the pacing and the general mood was right. We just weren’t experienced enough to know for sure that the way we had planned to tell certain things would actually be the right way to tell it. So we decided to tell everything in a single game instead, which of course also meant that we had to increase our budget and extend the timeline. Not an easy decision to make, but definitely the right one.

Other setbacks came from things like disagreements with our author. He did not work on games before and instead came from the film industry, which posed bigger problems than we initially thought. We just spoke different languages. Whenever we agreed upon a basic story outline and set a technical scope, he would just lock himself in for weeks without any progress updates and then come back with ten new characters, five new locations and dialogue that would fill our planned playtime alone. This happened a couple of times and it was really difficult to explain why certain things he added just were impossible for us to add. We finally realized that it just wasn’t working at all and had to part ways. 

For most important scenes of the game we would draw simple storyboards like this to get a feeling for how we wanted to tell certain things

We reached out to other authors that had worked on games before to help us come up with a story outline that would enable us to tell what we wanted to tell in a way that’s compatible with a game. These new discussions immediately felt a lot more productive and pretty quickly we landed on an outline that we all were happy with. Finally, the actual work on the narrative side of the game could begin. Without ever having written a story or any experience in that area, I began to write the first version of the full story with all of its memories, dialogues and twists and turns myself. The plan was to write the first version ourselves just to make sure that it wouldn’t stray too far from what we wanted to tell and what we were capable of delivering and then maybe get a more experienced author in that would use my story as a guideline to create the final story. But as it turned out from not just our own feeling but also the feedback we got from players testing and people we read the story to, this first draft of the story wasn’t half bad. It felt kind of weird to become the writer just like that, but at some point it just happened. We still got someone else in for just a couple of days at the very end to help us get the final version of the story right, though. I still didn’t fully trust my narrative capabilities. And this did definitely help in bringing out the best of the story. 

Of course writing the story yourself has a lot of advantages. I was always there to make adjustments when the implementation turned out to be more difficult than expected, I knew the game world in and out and knew when and where we might need some more dialogue to fill the void or when to be quiet and I knew what I wanted to tell and wouldn’t suddenly go in a wrong direction. This whole ordeal was definitely the biggest setback for the development schedule and the main reason we had to extend the timeline a couple of times, but I think in the end it was the right decision. It enabled us to create a much more consistent game world and more rounded story altogether.

We also used storyboards for general gameplay scenes we wanted to achieve in order to have a visual representation of the full game at this early stage

There were other reasons why development took as long as it did, though. Reasons that weren’t even problems that just suddenly showed themselves at some point. Reasons like having to build new demos for publishers, the Kickstarter or conventions . During most of the development time we knew that we didn’t have enough money to complete the game (except for right after the Kickstarter), so we had to take every chance we got to either build demos for potential publishers and investors or just do additional marketing and community-building at conventions to reduce the risk of a completely failed launch. This meant that we very rarely had more than two or three months without some kind of deadline for the next demo. And working on a demo always means working on some things that aren’t really important for the progress of the full game. Polishing a certain area of the game before the full game is finished not only means that there’s a risk all that polish has to be tossed if we make changes to other parts of the game, it also means that it takes longer until the full game is in a playable form to allow us to look at the big picture and call the final shots. But at the same time you don’t want to go to a convention with a 6-months-old demo that you already know still has bugs in it that players always would run into. It’s a difficult balance to find and definitely also added a couple of months to the final development time. 

Developing for consoles

A part of the development process that we had absolutely no experience in was developing for consoles. We knew that we wanted to release on consoles as well since Lost Ember always felt like a more relaxed, laid-back experience that we felt would be ideal for playing on a couch on a big screen. But of course this would also mean that we had to dive deep into documentations of systems we hadn’t worked on before, which is always difficult to plan for. We had no idea how long it would take us to get a build for PlayStation, for example, and even less of an idea of how long the whole certification and submission process would take. On PC, things are pretty straightforward and simple. You still have to get an initial approval from whichever platform holder, but that usually only takes a couple of days and after that you can just upload builds whenever you want. On consoles things are different. Every build you submit gets tested in-depth on platform-specific things that are easily overlooked. Things that can be as trivial as choosing the wrong translation of “button” in Korean, for example. Some platform holders have very specific rules on how the controller or certain buttons are to be referred to and will fail a build if on a single screen in a deeply buried menu you mention a “gamepad” instead of a “controller”. And with multiple languages that often have multiple possible translations for the same thing, this can get very hard to track down very quickly. But there’s also other systems that aren’t relevant on PC or other platforms like handling the case that you disconnect the controller during gameplay and then connect a different one. On some platforms the active user is synced to a controller, so changing the active gamepad will lead to problems with the save games and things like that, because the original user that the current save slot was assigned to doesn’t exist anymore. These kinds of things caused a lot of headaches a lot of times. 

Aside from these platform-specific systems of course there’s also general performance improvements needed for consoles – and especially the Switch which is why we always knew that the Switch version would not be included in that first release. We spent a long time figuring out what was causing specific problems on consoles and why things weren’t unloaded correctly, for example. The good thing about this work of course is that it benefits all platforms, PC included. So at least it mostly didn’t feel like we had to spend ages on an arbitrary problem no one really cared about. But it still kept us from what we actually wanted to do: polish everything and fill it with life.

The question whether we should release simultaneously on multiple platforms was ever-present and we never were quite sure whether we made the right decision. We were very eager to achieve a multi-platform-release because we knew that we didn’t have a huge marketing budget and being able to combine all of that budget into a single release would be ideal, but we also knew that it would take longer to get there, which of course also costs money. The question of which way we would lose the least money was not an easy one to answer. In the end, we decided to get some additional help for the console ports in the form of an outsourcing studio that specialized in that sort of thing. They would work alongside us for a while and consult us every now and then on how to deal with certain special cases. This allowed us to focus more on the actual game and put everything we had into that single release. It’s hard to say whether that was the right decision, because obviously we can’t know what would have happened otherwise, but at least I don’t think it was a terrible decision and I’d probably do it again, maybe with some adjustments. 

But as I briefly mentioned earlier, getting the builds ready was only half of the work that console-ports bring with them. Dealing with the submission processes and different backends is something that is so much more complex and complicated than it is on PC that we immensely underestimated the time we would have to put into it. Not only does it take a lot of time to just get everything set up, simply understanding the processes on each of those backends could take ages – and it’s not even just a backend for each platform holder, some have completely different backends for every region of the world they operate in. This is already getting better, luckily, but back when we prepared Lost Ember for release it was a confusing mess. 


Crunch in the games industry has gotten a lot of awareness over the last couple of years with terrible working conditions in a lot of major studios being exposed to the public and I don’t want to shy away from talking about it during our development. 

Yes, there definitely were extensive crunch periods during the development of Lost Ember. It’s hard to avoid when you know exactly that the money will run out in a month or two and you just have to put everything into the next publisher pitch to be able to keep your company and your job. Crunch phases always mean that you misjudged something and your schedules were unrealistic. Getting these schedules right for your very first game is obviously incredibly hard. You can only go by what you hear from others and that’s never the same as it will be for you. As I mentioned earlier there were a couple of times we had to delay the release date of the game because we just knew that we wouldn’t be able to get everything ready in time. And every time our expected release day came closer again, the crunch increased because there was always some part of us that thought “maybe we could still make it”. And part of that wishful thinking always also was the wish to finally be done with it. Five years we had been waiting for this day and when it was just within reach, we had to make the decision to delay it even further. That’s a very hard thing to do. But of course also the only thing that is reasonable. Having worked on a game for five years just to have it ripped to pieces in the reviews because of some bugs you were always aware of was even scarier than the prospect of an additional couple of months of work without knowing if it would be worth it in the end.

An additional factor that comes with a successful Kickstarter is that it just feels terrible to have to say to our beautiful backers that we won’t be able to keep our promised schedule. We tried to avoid that as long as we could because we felt like we owed it to them to do our absolute best to try to keep our promises, whatever that may involve. They were the only reason that kept us going for that long, after all. It’s an additional layer of responsibility that increases the pressure you feel every day anyway. But again, it’s obviously not their fault, it just means that we misjudged the effort when we came up with that initial release window during the Kickstarter. It’s basically impossible to come up with a correct estimation of the work needed when all you have is a prototype and that’s something that should be carefully considered when starting a crowdfunding campaign. 

What I can say is that we definitely have learned from the experience and are very eager not to repeat it with our next game. After Lost Ember’s release, we implemented a 35-hour-week with a digital time tracking solution that allows us to count overtime which can then be converted to vacation days later. I hope we’ll be able to keep this kind of schedule up even during stressful release phases and if not, at least this way everyone can take their well-deserved vacation afterwards without having to feel bad about it. And as another benefit it also allows us to track the time spent on certain projects much better. For Lost Ember, I can’t really say how many “normal” work-weeks we put into it in the end. For our next project I hope I’ll at least have a rough idea to be able to make better schedules for any future projects.

And that’s it again for this week. I hope you learned something from our mistakes our at least just saw that these things happen to everyone. No project goes smoothly from start to finish. Just don’t lose track of what you’re trying to achieve and always look out for yourself and the people you work with. In the end, making games is just as much about bringing fun to others as it is about having fun working on it yourself.

The next part will focus entirely on our Kickstarter campaign, what we did in preparation for it and what it was like seeing six figures on our bank account for the first time (spoiler alert: we did not buy company Porsches, but it was pretty tempting).

I hope to see you all again then! If you don’t want to miss it, you can subscribe to our newsletter here or just follow our Twitter. 

Until then, enjoy the rest of your week!



And here’s the next part:

1 Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.