Why did you choose Unity for Ori and the Blind Forest?
We started the development on Ori back in early 2011. Back then, the very early prototype of Ori was actually developed in Construct with only two people working on it. But when it became clear that we wanted to go big and turn Ori into an actual fully produced game, Unity was the natural choice for our team. We were able to port the Construct prototype in just a week and Ori immediately felt at home there. We all went ‘this already looks and plays so much better’.
Unity was powerful, extensible, very intuitive and artist friendly while still being affordable for our small start-up team in those days. We wanted to be agile and ‘indie’ and Unity was the engine to go.
Which area did the engine contribute to most significantly?
For us, Unity’s biggest strength by far was how flexible and extensible its Editor is. We were basically able to transform Unity into the perfect, fine-tuned ‘Ori production engine’.
For our tech team Ori is a very challenging title. Over time Ori became a full HD 2.5D ‘painting comes to life’ title with gigabytes of handcrafted, painted and animated art with insane levels of parallaxing that required to run at a solid and consistent 60fps without any loading screens, ever. On top of that, we needed to deliver sophisticated in-engine cinematics with crossfade transitions between shots, lush interactive environments, GPU simulated water, motion blur, and much more.
Since Ori is a “Metroidvania” style game, we had to allow our designers build the levels and the world of Ori in the most efficient and flexible ways. Designers needed to have one big birds eye view of all the scenes in the game and the ability to easily rearrange and reuse levels as LEGO blocks on a big world map.
Our artists needed to have a 2D art pipeline that would allow them to efficiently build, preview and animate all of our art directly in the editor. We needed to hide all the complexity of the thousands of shader permutations, as well as to do heavy editor and build time optimisations required to make the game run efficiently on the target consoles.
We have developed our own animation and cinematic framework that allowed us to build our story sequences and cutscenes right in the engine, iterating in the editor like you would with an editing tool such as After Effects but tightly integrating with all of our other core frameworks.
Since Ori’s world is fully continuous we had to develop our own multi-scene editing solution, allowing artists and designers to load and edit multiple scenes at once – which later also became the basis for our cinematic tools where each shot is a separate scene file – checking for art issues during scene transitions or finer cinematic edits.
There are many, many more examples and it’s hard to imagine an engine that was so extensible and exposed so much through a very well designed set of APIs and thanks to which we could build a production pipeline highly tailored and optimised for the type of game Ori is and its precise production needs.
Just thinking back at it – we were able to implement crazy things like our own multi-scene editing solution back in 2012. And before Unity supported text format we almost ended up implementing our own text format for assets and scenes. It’s simply insane but that goes to show how powerful and extensible Unity is.
How accessible is Unity on Xbox One? How does it help you get the most out of the new console?
For a while, we were actually targeting Xbox 360 as our main platform. Once the decision was made to create an Xbox One pitch, we were able to get the game up and running on the console in a matter of days.
Given the complexity of the game and having to have a continuous solid 60fps experience with no loading screens we actually had to shift to using Unity 5 for Ori, since it is the Unity version that has all the necessary optimisation work for level streaming.
We are still hard at work in making Ori the best experience on Xbox One with Unity 5 and the Unity team has been a great help in constantly improving and pushing the boundaries of Unity to be able to reach that quality bar and helping us ship hopefully one of the best looking and highly performing 2D games in the recent years.
How did you choose/define Ori’s distinct visual style?
From the get-go we were very inspired by the Studio Ghibli classics such as Princess Monoke and Spirited Away. We also referenced films like The Iron Giant and Lion King quite a bit.
Like many other aspects of Ori, its visuals have evolved and grew over time. If you were to send our past selves a screenshot of Ori from 2014 back in 2012 we would never believe that the game would look so good. By now it’s pretty much a different game visually.
There was this very interesting ping pong between the art team and the tech team. The game was not all continuous from the start. Before our multi scene editing was in place Ori used to be made out of segregated rooms and had hideous 8-bit style camera “scroll locks” with fades to black as you were running between them.
Back in the day Ori did not have very sophisticated lighting or environment animation. But at some point we decided to invest into our own “Ubershader” framework that allowed us to approach the features our artists needed in an extensible and modular way while auto-generating the all the shader permutations for the requested features.
Once the Ubershader framework was in place, our artists were able to introduce a whole new level of polish into our art with all the lighting and animation, as well as clever ways of arranging the art tiles to make every single screen in the game look unique.
But, most importantly, none of this would have been possible without the incredibly talented artists we have the privilege to work with at Moon. Sometimes we develop a new shader modifier or a tool and hack a nice looking demo usecase with it and hope it’ll be useful. Just a couple of weeks later, our artists are able to make something that looks completely mind blowing with it. And then, they will ask for more features. The ping pong cycle keeps going until we are basically forced to ship the game.
What were the most useful features of Unity?
Being able to write code in an awesome language like C#, without needing to recompile and restart the editor with every change.
A really nice built-in particle system. An insane scripting API that allowed us to do almost everything we wanted for Ori. Very well exposed and highly performant physics engine. Very flexible and customisable rendering pipeline. Very easy to use but powerful and useful profiler.
And the biggest thing is of course the ‘develop once – ship everywhere’ capability. With a small team of engineers like ours we wouldn’t have been able to ship on all these platforms if we weren’t using Unity.
What features would you like to see added?.
Since we grew to become a pretty big team towards the end of the project it would be nice to have more advanced collaboration tools for scenes and assets – knowing who is editing the scene at the moment for example – better content merging tools and easier control over the stability of the text format when re-saving existing scenes to avoid merging conflicts.
We would love it if LoadLevelAsync could work in the editor, currently it stalls while loading scenes, and for the play mode entering times would be faster, since they have gotten quite slow as our project grew in size. In some cases our artists have to wait for eight-to-ten seconds before being able to play the level and that isn’t optimal for iteration times.
And it would of course be very good if we could scale particle systems.
What advice would you give to new Unity developers?
Don’t be afraid to modify and extend the engine to make it do exactly what you want and how you want it. Learn to write custom inspectors and editor tools. It’s the best investment you can make while making your game. And Unity is simply the best engine for this.
Once you are able to optimise and fine-tune your production pipeline for the game you’re making you will be amazed by the results your content team will be able to deliver.