Jan Klose (director) and Thorsten Lange (technical director) worked on German studio Deck13 Interactive’s Lords of the Fallen, which launched worldwide October 2014 on PS4, Xbox One, and PC.
More than three years ago, the publisher CI Games gave us the incredible opportunity to create a new Action RPG. After Venetica, Lords of the Fallen was the second game of that genre that Deck13 was about to develop. Little did we know that we would end up on the then-nonexistent “next generation” hardware, work together with people from all over the world and win new fans from the most foreign of countries. We are unbelievably grateful but it has been a rather rough ride. We hope this postmortem help others not to fall into the same traps.
1. Finding the core game loop early
Creating the first concepts for a brand new IP is both challenging and thrilling at the same time. At the beginning of the production, we already had a concept in place that was not too far away from Venetica, our first RPG. In open talks with the publisher CI Games about what was possible, time- and budget-wise (and what wasn’t), we soon decided that we better not try to do too much at once, but rather focus on one core gameplay element and build the game around it. During conception, this proved rather tricky for a game in the RPG genre, because people generally expect a host of features that turn their game into an alternative world, a world in which everything is possible.
Our debut RPG project Venetica already featured tactical close combat, but all in all, Venetica was more focused on story and a unique atmosphere. The combat, while being a good start and a valid source of inspiration, was not really the game’s focus. But it was an element that had been much fun to develop, and we wanted to build up on that. So should tactical combat be the foundation of Lords of the Fallen?
Luckily we shared a vision with producer Tomasz Gop: our passion for Demon’s Souls. Above all, this game taught us one thing: You can build a game around a hard and challenging combat system and, at least after people embraced Demon’s Souls, you wouldn’t need to boil the project down to some convenient cutscene-packed game that would almost play itself. After Demon’s Souls, you were able advertise your game as hard and challenging again, a thing almost all people at Deck13 had grown up with and missed in many games that had recently been released.
So we agreed with Tomasz that the tactical action combat should become the one core element of the game, that we would start with it and build everything else around it. Even the story, a component that we at Deck13 are kind of known for, was not supposed to play the major role, however we still planned to make it strong and compelling too (a thing that we should only partially succeed with).
Our experience with a similar combat system and our love for Demon’s Souls resulted in a very clear game mechanic that we kept until the end, even though some people later said it really played quite a lot like Demon’s Souls successor, Dark Souls. Some even called us a Dark Souls clone. While this certainly felt a bit unfair, the good thing about it was that people were desperately waiting for Dark Souls to appear on the new generation of consoles, but it didn’t, so we were able to fill that gap (and certainly many players did consider our game to be quite different to Dark Souls when they actually played it!). Also, we considered our combat mechanics to be quite similar to Dark Souls mainly because they both tried to convey a very timing-focused combat. And we were not fond of making our system less focused on timing just because another game had just excelled in this area.
In any case, the tactical combat worked very well, and it was the one element that kept the game and its development together from start to finish.
2. Adapting the goals and the team
We started with about 40 people on the team. That’s already quite a lot, but for the project we had planned, certain key areas were seriously understaffed. So we were facing the big task to find more skilled people quickly. Back at the time when we were developing Venetica, we had a similar situation, and no experience with hiring people fast. That had resulted in rushed hirings of people who did not really fit and, especially in the programming department, sometimes did more harm than good. Supposed experts needed training in basic tasks, and in the end some code sections written by new hires had to be rewritten by the lead programmers, who in turn ran late with their own work.
We were determined not to make this mistake again.
So we started the hiring process as early as possible to have enough time to find the right candidates, and we planned time to train them before they would get started on production of the game. After scanning the applications, we did Skype interviews and then sent them a questionnaire with some tricky questions. Then we invited the best candidates over for a two-day test-task on site, to see how they would work on their tasks and how they would fit into the team. And this time, we barely made any “mistakes” and created the very best group of people we had ever worked with. Soon we were about 65 employees with people from all over the world. Oh, and we switched our meeting language from German to English on the way.
3. Fledge: our own “next-gen” engine
After about a year of development, the publisher asked if we could ditch all plans for the “last-gen” platforms, as the new platforms were close to launch. We still did not know any real facts about their system specifications (actually we needed to heavily rely on rumors) so that was a tough question. We needed to guess a lot and still tried not to gamble. In the end, we decided to take the risk. It proved to be a very good decision.
People were asking us if we were serious about using our own engine for such an ambitious project. Why not use Unreal or CryEngine?
Well, we wanted to be fully in control when it comes to technology, and we felt that the only way to achieve that was to use our own. We started developing the current iteration of our tech back in 2009, and successfully shipped on both PS3 and Xbox 360, so it was not like we had to start from scratch. In addition, there are some third-party components which we used that would have been impossible to create on our own, like the NVIDIA’s APEX for destructible objects and cloth simulation or Geomerics’ GI solution, Enlighten. While we did not know up front that we would have to switch platforms during production, in hindsight we think that it would have proven much more difficult to do that if we had chosen a third-party engine.
Whenever evaluating whether to use a third-party engine versus rolling your own, one major argument for an engine like Unreal is the number of shipped titles. But while the catalog of shipped titles using Unreal is certainly impressive for the last generation of consoles, the same obviously did not hold true for the new gen, since the platforms weren’t even out yet.
But the most important argument for our own engine is that it’s just in our culture – it’s what the people on the tech team want to do. For the major part of the development cycle, the tech team consisted of only five to seven people taking care of everything programming related. We think that this is a testament of what you can achieve if the people can work on (and focus on) things they love.
Having said that, it should be clear that Lords of the Fallen was not exactly a walk in the park for the tech team. We had to define what “next-gen” would mean for us, given the scope of the project. It was always a challenge to define and stay within budgets to make sure the content would work properly across all supported platforms. It was not only the “more of everything” approach that we took compared to last-gen, but we also developed techniques and features that just would have not been efficiently possible at all on older hardware (like our volumetric lighting solution). Keeping the tools up to date to support these new features was quite challenging as well.
4. Evolution of team and structures
Lords of the Fallen was by far the largest project that Deck13 had ever done. While we felt pretty well-prepared in the beginning, we found out that we needed to learn an awful lot along the way. For some people, this resulted in exciting new assignments. One example was in the animation section, where Sebastian Seubelt, lead animation artist, and animator Ralf Risto coordinated the whole animation pipeline up to the point of directing the actors in the motion capture studio (they did 12 mocap sessions over the course of development, flying to the remote Polish town of Rzeszów for each of them). In other departments however, it meant dramatic changes that were not welcomed by everyone. The artists, for example, had to switch from creating nifty 2D and 3D assets to feeding and maintaining a massive outsourcing pipeline. At the beginning, both Deck13 and the publisher underestimated how precise and strict the asset delivery toolchain needed to be organized, resulting in unusable assets and frustrated artists. Unclear responsibilities between developer and publisher made things even worse, and at one point we decided that we needed to give things a more formal approach.
We decided that we needed one central place at Deck13 where every single briefing for the art outsourcer teams was created. That was basically an (online) A4 sheet containing all relevant data for each and every asset of the game. Even a single barrel received clear reference images, text describing the important aspects, polygon limitations and material requirements. We wrote several hundred of those individual briefings. With the Chinese company Virtuos we had a great art outsourcing partner who could perfectly work with these briefings, and the results were so good that we could place most of the objects we received into the game almost immediately. (Also, their time zone was seven hours ahead of ours, so they worked while we slept, and vice versa.) As our whiteboxed levels already contained all the necessary objects in a very rough state, we could directly replace these dummy objects with one single click in our editor, turning a rough white level into a vivid world, click by click, asset by asset. But it had been a long way before we got there.
The evolution of our structures did not stop there. Every department became better and better with their planning tools, migrating from Post-It walls to online boards like Jira and starting every day with a quick stand-up meeting. Even though some aspects of our work still lacked the proper organization, people worked unbelievably professionally and remained great and enjoyable (but understandably slightly maniacal) colleagues at the same time.
5. External experts’ contributions
The game would not have become what it is now if not for lots of external feedback during the whole production. The project started off with a totally different setting, at first on paper, and it kept the setting until the first playable version was reviewed. The game was initially set on some sort of Scottish island and the villains looked a lot like ancient Romans. However, even though the graphical quality of the assets was really good, it soon became clear that this approach did not really hit the nail on the head. After a number of reviews, a lot of this was turned around, and the Rhogar, a demonic race, entered the scene. The environment on the other hand became somewhat more snowy, spiky, and… castle-y.
Only the core combat gameplay was kept, because it was basically the one thing that was working right away, and all the way until the end of the production. This was the thing giving us the confidence that the game really had a chance to become good, no matter whether or not we had already found the fitting visuals to accompany it. A lot of people helped shape the game and turn it into what eventually became.
Some individual people deserve special praise. Producer Tomek Gop, who previously worked on The Witcher 2, has a surprising eye for game design and enemy balancing. He provided perfect feedback on any new enemy or boss design that we had him play, and he was able to talk about the tiniest details together with our enemy design team.
Designer Eric Williams of God of War fame did a very important review of the game after Alpha, suggesting some new gameplay mechanics, enemy design and asset focus. Without him, the game would now feel rather different, and most likely not for the better.
Writer Susan O’Connor of Tomb Raider fame helped us with finding the right story, even though we gave her a difficult task with so many ideas already in place when she joined. She was more moderating the elements than suggesting new ones. Still, without her work we would have had a hard time focusing on our most important characters and story elements. It was a pity that we did not have more time in advance to work on the script. We could have done so much more here.
Damian Zielinski, art director at CI Games, has the right eye to spot ever-so-slight inconsistencies in any screenshot, giving valuable feedback on visual quality throughout the whole process.
Composer Knut Avenstroup Haugen of Age of Conan fame is an excellent musician who created just the right tune for the game world and boss fights. His live orchestra direction gave the game the epic touch it needed.
And finally, the publisher CI Games was keen to request external reports from game evaluation companies that wrote mock reviews and in-depth assessments, giving us plenty of hints on how we should shape our features in order to make the best out of them.
The team is unbelievably grateful to have worked with so many renowned people from the games industry who helped to make Lords of the Fallen happen, who broadened our horizons and gave us a totally different view on the game and ourselves as a team.
1. Management structure
While the project was staffed rather well from a developer and publisher perspective, not all key personnel was in place. Missing throughout most of the project was a managing producer, someone who loves reading and writing schedules and charts, asking the tough questions and making tough decisions regarding scale, features, and deadlines. To put it short, someone who knows what to throw out of a project to make it happen. Instead, creative people on both the developer’s and the publisher’s side were striving to create the most beautiful, content-packed game one can imagine, with the result that schedules were too crammed, people had too much on their desks and were not able to finish all the desired features on both sides.
This put horrendous stress on the artists, programmers and game designers as they tried to fulfill all the goals, and they never fully succeeded with that. We tried to counter the lack of a managing producer with building up management power at Deck13, firstly by establishing two-week sprints together with the publisher to have a clear overview of the tasks that were to follow next and to see early enough what would inevitably slip. Still, every sprint basically felt like the team would fail to meet the goals, and people were close to resigning, as they could not keep up with the psychological stress this was causing.
At that point, we decided to hire Mathias Reichert, a development director and veteran in the German games industry. After a couple of weeks at the project, Mathias pointed out that the task he was given had been described to him “a bit too optimistic” at the beginning. But he was soon able to work with the team and the publisher to establish better channels of communication and was brilliant in collecting the developers’ and the publisher’s needs, distilling the essences of what was important and relevant, and inform everyone accordingly. Things began to work.
And then they began to work really well when the publisher finally established Steve Hart, a managing producer, on their side. He would quickly opt for the more important features and drop the less-important ones. Our team noted that it was a pity that the producer came in only when 3/4 of the development time was already over. But still his contribution made it possible to release the game at all.
2. No clear responsibilities
At the beginning of the project, both publisher and developer sides did not feel that it was very important to approach things too formally, and therefore there were (in some areas) no clear hierarchies or responsibilities in place. Sooner or later this resulted in a struggle over competences, especially after some of the initial goals were not met. This again resulted in some bizarre incidents. For example, at some point, people at the publisher began thinking of level layouts, and were we doing so at the same time. This resulted in two parties submitting level maps to the project. And when a level map has once been created, it’s hard to get an idea out of someone’s head. So what now? Which version of the castle was the better one? Could they be combined?
One might be able to imagine how long it took to settle on the maps that were best for the project (and not the egos), and this issue seriously threatened the whole production plan. Luckily, things like these ceased once Mathias and Steve were in place. These two guys were, from time to time, puzzled about how we could have come so far without people like them on the teams. Their work strongly increased the faith of both publisher and developer. Things started to improve, and we were happy and relieved to have the project back on track, even though it happened rather late.
3. Communication
Throughout large portions of the development time, we were not really good at communicating. While we were not so bad talking internally (well, there still were issues but we had them under control), we were really miserable communicators when it came to publisher discussions. As there wasn’t one person channeling all requests and feedback, there were times when it actually felt as if everyone was talking to everyone, without clear rules or structures, resulting in a lot of negative vibrations, confusion, and anger.
Basically we had not thought about establishing guidelines for communication, and things only got better when we did so. For a start, we stopped the wild communication between so many people at publisher and developer teams, employing “channel” people, mainly department leads, who would be responsible for gathering and distributing feedback.
Also, we were sometimes not very good in replying to requests quickly. Our most frequent excuse was that we had to observe so many individual tasks that there was just no time to reply to a request within an instant. However, we did not consider the effect that this had on the other side: People just did not know why exactly their request remained unanswered for hours or even days. Did we just not feel the request to be important? Or had we simply not seen the mail in our inbox folder? Or had we talked about the request and abandoned it without feedback? Well, employing some rather simple rules solved this problem. We agreed that any request from the publisher was to get a feedback from the team lead within at least hours, if not sooner, and if there was no time to really assess the matter, we would at least write back that we had received the mail and would give an estimate on when we would get back at the latest. This greatly improved the communication atmosphere and removed a lot of frustration on the publisher’s side.
All in all you could say that we employed a “service” attitude at Deck13, understanding ourselves as a service provider without losing our identity as a developer, a thing sometimes hard to achieve. Still I think that we succeeded with it.
4. Art-driven design approach
Having no proper management structure in place also meant that the people and departments with the strongest standing were those who dominated parts of the design process. This tended to make things rather difficult, especially when detailed art design decisions were made by top management without considering the whole pipeline, giving tech and game design personnel a hard time.
After finishing Venetica, we were determined to make the areas work together better. However, at times it felt like we were doing even worse than before.
At the start of the production, technicians were clever enough to set up strict asset limits based on their best estimates. This was supposed to ensure that the artists would not create assets with an insane amount of polygons or use a crazy amount of material layers, slowing the engine down to a point where even technical optimization would not be able to save the day. During preproduction, however, these limits were largely ignored with the argument that we would “first need to find the right look” and that we would be able to “boil the whole thing down later anyway.” But it turns out that if you show people a scene full of great stuff, they will not want to go back to scenes that look more scarce, whatever argument of reason you might offer them (like “framerate”). Then it was all coming back to the tech guys who, obviously, had told everyone that it would end up like this and nobody listened to them. Believe it or not, the tech people always seem to be right in the end, so next time it would be wise for us to listen to them right from the beginning, even if that might mean hard fights with management, marketing, or other publishing departments.
The game designers, on the other hand, were facing a different kind of problem. At Deck13, game designers usually create 2D maps of their levels, offer them to the art department where a 3D world (the blocked-out level) is created out of that, and that goes back to the game designers to put in their gameplay assets using our Fledge Editor and test the gameplay flow, and then it goes once again back to the art department, who will improve the level structure and add details with whitebox geometry. This is a tricky process because these two departments need to talk to each other after every step they take, and in the heat of the battle this might slip from time to time. Things get even harder when 3D models of game levels surprisingly come floating in from the publisher, suggesting some “cool structure” here and some “awesome new castle” there. If you have ever tried to cram gameplay into an existing map that has been created by artists that were working without the guidelines in mind, you will agree that this feels like quite the wrong way around, especially if your team is considerably larger than a couple of people.
Enemy design was another critical topic. Several experienced people in the art and game design departments had a pretty clear picture about the rules we needed to apply to make the enemies work well in our game: As it was so crucial for the player to quickly identify the type of opponent he would be facing (to brace himself with the right equipment and tactics), we needed them to be clearly distinguishable in size, color, and movement (see Left 4 Dead as a great example on how to do it right). However, there was a design guideline installed that said that all enemies were required to look like “honorable warriors with human shape.” This, however, resulted in all enemies looking pretty much alike when you actually played the game, making it very hard for the player to identify who he was fighting against. Luckily, external feedback was finally gathered, the guidelines were changed, and we created as much enemy variety as time still allowed. Again, we could have achieved this more cheaply.
The art-driven design approach resulted in being over-budget with our assets, and with the stuff being rendered on screen at once. It again meant that we could not fulfill our production sprints because nobody could actually integrate everything that they would have needed to.
5. No real beta phase
At some point, the release date was set. This was mainly due to the fact that we had a new and unknown IP that would need to compete on the big platforms. For our game to be noticed at all, it had to be out there before the big wave of great new titles would hit the market by Christmas 2014. So whatever we wanted to still put in the game, it needed to be ready way before that time. That seemed extraordinarily tough, and it was only doable by crunching throughout the final months, to the point where people got so stressed that you could barely talk to them. Two things let us survive this phase and come out of it with a (rather!) polished game: Firstly, people were just so determined to make this game a success that they did everything they felt necessary to reach the goals. The other factor was managing producer Steve Hart, who helped channel publisher requests throughout the final months. He was able to make some tough decisions on what to throw out of the final product and what to focus on, close to release.
Still, we did not have enough time left for proper beta testing. Even though testing was ongoing and a great QA department at the publisher supported our small internal QA management team all along, there was just not enough feedback on balancing and, even worse in our case, on compatibility.
This resulted in some very annoying bugs that were still present in the release version, at least on PC where we just did not cover enough hardware configurations to make sure the game would run everywhere, and this resulted in some very annoyed people (and rightfully so!) who could just not get the game to run on their machines. We tried to be as fast as possible, and to help as much as possible, but still it was very dissatisfactory to just fix the stuff after the release and not before. We were not deliberately putting a product on the shelves where we still knew about bugs just to keep the deadline. Instead, we were releasing a product that was free of serious bugs to the best of our knowledge. It was just that this knowledge was too shallow because we did not have enough time to collect more test data.
Conclusion
With so many sacrifices and such an uncertain outcome (at least from our perspective), we were, lots of times, wondering whether all of this was really worth it. Well, we were lucky. The game was received well on all three platforms, it received awards and sold very satisfactory. Deck13 is now known as a capable developer, we got credits for the engine we developed with a small team, able to deploy on Xbox One, PS4 and PC with high quality. We professionalized our structures, bringing art and game design to the next level, and we vastly improved our network of valuable contacts. So, all in all, Lords of the Fallen was the necessary step to turn Deck13 into a serious studio. We still have a very long way to go, but this milestone was necessary, and it was good. It was a big leap, and hopefully only one of many more to come.
