With over 3.5-million views, Book of the Dead is hugely popular and many want to know how it was accomplished. Unity evangelist Matt Schell went to Stockholm to meet the Unity Demo team and learn what drives them. This is the kick-off post of a new series covering the demo’s art, characters, lighting, storytelling and much more.
It’s late winter when I land in Stockholm and the landscape is still blanketed with snow. I’m here to talk to my Unity colleagues about how they accomplished Book of the Dead. As a Unity evangelist, I communicate with our community a lot. Often that’s about helping folks understand the engine technology, what’s coming out, and how to use it. When the teaser for Book of the Dead landed and all sorts of questions about it started pouring in, I decided to visit the Demo team to see what I could learn and share with our community.
In preparation for my trip, I watched the real-time teaser trailer for the project repeatedly. It’s mysterious and hints obliquely at a larger world. The imagery is haunting and technically impressive. The fact that the demo looks so good has prompted many to wonder if it was only made possible with some highly customized version of Unity, a huge budget or a massive team. I’m curious to get the inside scoop and answer a lot of those questions.
It’s a team that gets a lot of recognition externally -- their work has won awards, including the highly prestigious Webby Award for Adam last year -- but they are a distributed team which seldom gathers in the same place, so I pick the one week when they’re all in Stockholm so I can get to spend some time with all of them and see how they work together.
When I arrive, I’m introduced immediately to Veselin Efremov, or “Vess,” as everyone calls him. Vess is the creative leader of the Demo team, defining both the visual and narrative vision for their projects. On Book of the Dead, he’s credited with writing, directing and art direction. When we meet, he’s heading into a morning standup meeting with Robert Cupisz, Torbjorn Laedre and Julien Heijmans. They’re doing an environment art review as they prepare to demo at the Game Developers Conference (GDC) in San Francisco, and are working to get it running on a PS4 Pro.
As Julien navigates the environment, Vess looks at the rocks and asks Torbjorn, the technical lead of the project, who’s attending via teleconference, “We need some more rocks. Maybe one or two more 4K textures?” Torbjorn, who is currently optimizing the project, replies, “That’s fine. What are you going to give me in return?”
Friendly haggling ensues over texture memory and whether or not more rock textures can in fact be afforded while maintaining performance. We then spend 10 minutes discussing whether the skybox is oriented correctly, and experimenting with it. Observing their process, I am reminded again what an incredible amount of painstaking, detailed work goes into creating a real-time 3D project like Book of the Dead.
After the meeting, I sit down with Vess and Silvia Rasheva, who is the team’s producer, to learn more about how they work within Unity.
Vess explains: “There are 12 of us, plus some contractors from time to time. The budgets are more or less the salaries for the team. We basically behave like an internal studio. We get access to information and we communicate a lot with R&D, requesting and contributing bug fixes, but we don’t use the whole Unity machine to do stuff for us.”
“The main difference between us and an external studio is that we are trying to use upcoming technology very early in development, which can be difficult because it’s not finished. So we provide a lot of feedback to the various Unity R&D teams as we go.”
Silvia adds: “Basing entire productions on features in pre-alpha state, and sticking with them through constant updates until they mature enough to ship, is very taxing on our production process. Sometimes we need to work for months with R&D to overcome certain technical hurdles. This is why half of our team consists of programmers – it’s not such a typical composition of a creative team, but it’s necessary in our context. While our art department is more traditional in how it’s organized – with six artists creating the concept art, character art, the assets and scenes, animations and VFX in the demo – more than half the programmers’ schedule is spent collaborating with R&D.”
Vess jumps in: “This is one of the downsides of being an internal production team at an engine company – when you make a game, people will put pressure on the Engine team. They’ll say ‘This is not working, fix it now!’ But when you want to be versatile, like Unity, you can’t focus only on solving the problems of one game or studio. We represent the perspective of ‘This is what we’re trying to do, which reflects AAA ambition – games that will want to use complex shaders, a lot of vertices, high-resolution textures, etc.’ – and so R&D needs to find a way to satisfy our request while balancing it against the complexity of simultaneously satisfying the needs of all the different types of projects being created with Unity. But when we raise a flag about a clear-cut issue – ‘Do you know when you do this, the shadows break?’ for example – then R&D will prioritize it, because if it breaks for us, it will break for everyone.”
“That’s when we receive a lot of collaboration and involvement from the engineering teams, so our production can continue,” Silvia adds. “And they get a solid context to validate the new tech and improve it as much as possible from the early stages. We use the features in a complex, gamelike environment, and we set our quality standards uncompromisingly high, so our productions expose issues that otherwise could go unnoticed for a long time. And of course, there’s always the tech that we sorely need but no one has gotten around to doing yet, so we make our own solution in the project, just as a game studio would. We then hand over our prototype to R&D to help kick off the design of an integrated in-engine solution.”
An example of this collaborative development is the occlusion probes, which Robert Cupisz, the senior graphics programmer on Book of the Dead, created for the demo. In simple terms, occlusion probes work to improve the lighting of the scene by allowing objects to test how much light reaches them from the sky, which allows for more natural-looking, deeper shadows when objects occlude one another. This required deeper access to the light-baking API. At Robert’s request, the Lighting team in R&D exposed this access to C# scripts, and this API was made available with 2018.1 to everyone to use in their own development.
The team maintains a balance between using a non-modified version of Unity (so their achievements are within reach of external studios) and pushing tech boundaries so the engine can satisfy the needs of ever-more ambitious productions. As such, the team carefully manages the project-specific tech they develop on top of Unity, and are pushing hard to ensure that it will be available for everyone by the time 2018.2 is released.
Speaking of custom tech, I asked the team how they approached terrain in Book of the Dead, since Unity’s terrain capabilities have gone for a while without an update, and every second comment I’ve seen online seems to be about what custom stuff they did in order to pull it off.
I’m surprised to learn that Book of the Dead actually uses the existing Unity terrain without modification, with the addition of one or two custom scattering and placement tools they wrote in C#, as Vess explains: “It was very tempting to do our custom terrain, but we had to consider that in Book of the Dead we deal entirely with a natural environment, so people would pay special attention to terrain, and if we had implemented our own solution here, it would have been misleading. So we made it a hard requirement for ourselves to make this demo with Unity’s default terrain. Torbjorn built some tools that made it easier to work with it, like a scattering tool, and a tool that allows us to paint with groups of vegetation, such as painting five different ferns. I also placed a lot of stuff by hand using the Unity tools. While the terrain system is old, it’s still a complete system and it works. Building small things on top of it can completely change its face. It’s mostly just authoring convenience and shading.”
I also ask about the grass, since it’s one of my favorite parts of the demo. “Unity’s grass doesn’t support lighting – they’re billboards and you can’t have shaders or a normal map, and we have no control over the material. So we placed the grass as trees. Tiny trees.”
During my two days in Stockholm, a common thread runs through all of my conversations with the team: A desire to show what’s possible in Unity. “That is our goal. We want to show what’s possible. Our target is not a single individual, but for a small team, 10-15 people, maybe with one graphics programmer, it’s totally doable to make something with the visual quality of Book of the Dead,” Vess explains.
“Unity is a very powerful tool in the hands of an advanced user. It’s extendable, it’s flexible and things are getting better all the time. Part of our role, and how I decide on what demo we should do next, is looking around and asking: ‘What is nobody doing in Unity?’ Then we try to do that. At the time it might seem impossible or at least very difficult. So while we work on the demos and collaborate with R&D, we help make it possible. Unity evolves incredibly fast and our team tries to run a step or two ahead of it. By the time our demo is done, they have caught up and, in the end, the users get a better product. That’s really what it’s all about.”
Stay tuned for our next posts in the series. Next week Georgi Simeonov covers Concept Art, and the week after Plamen Tamnev will share the Character Art creation process, with lots more to come.
Meet us at Unite Berlin on June 19 to walk through the Book of the Dead environment on a console yourself, and attend Julien Heijmans’s presentation about Environment art in the demo. See the full schedule here.