Remi Quenin is a game engine architect at Ubisoft Montreal and will be at GDC 2018 to present The Asset Build System of FarCry 5 will discuss the architecture of Ubisoft Montreal’s data pipeline.
Remi Quenin is a game engine architect at Ubisoft Montreal and will be at GDC 2018 to present The Asset Build System of FarCry 5.
His Programming Track talk will discuss the architecture of Ubisoft Montreal’s data pipeline, from edition to optimized runtime asset, with a main focus on the part performing the transformation: the asset build system. Here, Quenin gives us information about himself and what he does.
Don't miss out! The Game Developers Conference in San Francisco next March is going to be full of interesting and informative sessions like Remi's. For more visit the show’s official website.
Hi! My name is Remi Quenin, and I am a game engine architect working at Ubisoft Montreal on the Far Cry brand. I've been working professionally in the game industry for the past 15 years, and more specifically for 8 years on Far Cry titles. My main role on Far Cry has been split between low level systems (multithreading, memory/resource management, streaming and anything related to performance) and productivity improvements (pipeline and workflows).
This last subject is extremely important in a big team such as Far Cry, and sadly, it usually doesn't get as much love as it deserves. This situation motivated me to present some of the work we did on Far Cry 4, here, at GDC 3 years ago, and brings me back again this year to present what we've done on Far Cry 5.
What we call "engine" at Ubisoft, is sometimes called "system" in other studios. So our engine team in responsible of all the low level systems, such as memory management, threading, streaming, serialization, runtime asset pipeline... etc. This is where my expertise is, and my role is to act in those domains as much as I can in 3 different ways. First, by pushing for innovation and providing technical solutions for our design ambitions. Second, by making sure that all our development are made in the best possible way, making the best use of the systems in place. And third, by constantly trying to improve the productivity of our team. We do have expert in every field, so my role is to provide guidance and advice where I can, and take ownership where required.
For example, our Asset Build System that brings me this year to GDC is the perfect example that lies at the junction of this three facets. The design of Far Cry 5 was clearly pushing in an unprecedented manner the amount of assets required to build the game: bigger world, more variety in biomes with bigger focus on procedural generations, more characters to interact with...etc. From the engine perspective, this means a huge amount of additional assets to build, package and stream. So I designed and developed the framework able to handle such a load. I provided all the support required to make a good use of it amongst our programming team. And I drove its integration in our production workflows (processes, hardware selection ...) in order to improve the productivity.
The main obvious benefit is that our engine is crafted for our needs. Dunia is the Far Cry engine, and solves FarCry issues. There are very few engines out there that can handle vegetation, fire simulation, destruction, vehicles, systemic AI, wildlife, weather, day/night cycles, non linear storytelling...etc., all of that in a gigantic streamed open world. All those features are built around each other, and all of our technical decisions are taken with those constraints in mind, including low level ones. Far Cry titles has always been pushing technology and innovation. So owning our technology, and having the ability to finely tune every bit of it is a huge advantage.
For instance, it is true that 10 years ago, Dunia was initially based on CryEngine. But it has evolved so much over time, that today, it would be very difficult to find any of the original code. All parts have been changed, replaced, re-written, in order to solve the specific problems of a modern Far Cry game. And in 10 years, it will probably be very different than it is today. Such agility would not be possible without owning our technology.
I was a gamer in my youth (and still am!), playing on Nintendo NES, Amiga 500 and PC. But I was also passionate about anything related to computers and programming. Even if I didn't know exactly what I wanted to do for a living, I knew from the start it would be related to computers. So I took a computer sciences course at university.
When the time came to find my first job, I saw most of my buddies aiming for jobs at banks or other serious businesses, but I knew this was not for me. Multimedia was the thing that got me excited: using computers for sound, video, graphics ...etc. It was so inspiring! So making games immediately came as an obvious choice, since to my eyes, it was the "Ferrari" of multimedia. This is what pushed me in. But once in, I also fell in love with the industry: lots of smart people from very diverse background and sensibilities working together in a creative, young, and dynamic environment... and I never left the industry since then!
As I said earlier, I want to bring some attention to pipeline and productivity matters. I have seen too many times, on too many projects, offline computation or asset processing left to a poor intern who had no idea of what was going on... A poor student who is usually trying to solve issues with buggy scripts lost on the disk of an old workstation turned into a build machine…
For projects of the scale of Far Cry, this is naturally not even an option. But it is not rare, even on large projects, to have those buggy scripts at the root of a huge organic build system, that tries to solve hundreds of complicated problems through unspeakable hacks... On Far Cry 5, we wanted to have the exact opposite: a state of the art asset build system, able to process millions (yes, millions) of assets quickly, and to take advantage of the most powerful hardware.
This is even more important for us, because our production tools are using a JIT (just in time) compilation approach, where an asset is binarized upon request. So in this talk, I will describe this JIT approach and its benefits, and will explain in detail the architecture and implementation of the build system. I will also explain some of its main features, such as caching, distribution and process isolation.
I think the biggest challenge in a production like Far Cry is the scale. The scale of the production itself for sure, but also the amount of code and content. Far Cry titles have always been massive open world games, with a crazy amount of content. And Far Cry 5 is no exception: once again, it is breaking all records, with almost three times more data than we had in Far Cry 4.
So the first challenge, from a runtime perspective, is to make everything fit. Fit in memory, fit in performance budget, fit on disk. Our content team always wants more, and it is our job to set the limits, as high as we possibly can. Then, this heavy load is putting pressure on all systems of our engine, revealing weaknesses we had never thought of.
On the pipeline/productivity side, this is a huge challenge as well. How do you generate gigabytes of data in a reasonable amount of time? How do you deal with tens (if not hundreds) of thousands of assets, with millions of dependencies between them? You cannot design a tool for such a scale the same way as you would do for a more modest project. So the scale is at the center of every decision we make.
I would say, that one of the big rewards, is when everything finally works as expected. When you have designed a system, and you are throwing a ridiculous amount of data at it, and it just works, flawlessly, consistently, with great performance, this is extremely satisfying. Both as an engineer, because it just works, but also as a team member, because it empowers our colleagues in being even more ambitious, more creative, and ultimately it helps them to build a better game.
Because we must not forget that our job is making great games: we are not selling technology, but an immersive experience to our players. And low level and pipeline systems are the foundation on which our team can build such an experience!
Anyhow, at the end of the day, having a powerful engine that lets us build great games, that are ultimately being enjoyed by millions of players is the best reward I can think of.
This will look like very specific advice, but this is something I value a lot with my youngest or less experienced colleagues: learn to read and understand code as well as to just write it. When you join a (big) team working with a big engine, start by fully understanding what's in place, what problems it solves, and how.
Even if some code looks a bit rusty, make sure you fully understand in deep detail what it does, and which other system rely on its services. And then, you'll have all you need to change, improve, or even redo if necessary what is there. Also, when producing new code, I cannot stress enough that any system is useless until it is tested under heavy load. Building a new system is 20% of the work. Making it work efficiently with real life data, in a real life environment, is what takes the most time. Shipping your system is what makes you a great programmer.
GDC 2018 will take place March 19-23rd at the Moscone Center in San Francisco. For more information on GDC 2018, visit the show's official website, or subscribe to regular updates via Facebook, Twitter, or RSS.
This article originally appeared on gdconf.com. Gamasutra, VRDC, and GDC are sibling organizations under parent UBM Americas.
Read more about:
event-gdcYou May Also Like
