LogInWe’ve had a chance to talk to Nicholas Routhier about the techniques and processes which helped the team build the enormous world of Assassin’s Creed Origins.
We’ve had a chance to talk to Nicholas Routhier, a Design Technical Director at Ubisoft Montreal, about the techniques and processes which helped the team build the enormous world of Assassin’s Creed Origins. Nicholas will also be joining GDC in a week to discuss monitoring and validation of world design data in AC, so don’t miss the session.
Introduction
My name is Nicholas Routhier, I’m a Design Technical Director at Ubisoft Montreal. I am a French Canadian, born in Montreal. I’ve been in the studio for 15 years now, I worked on brands like Far Cry, Prince of Persia and Assassin’s Creed. The last two games I’ve shipped are Assassin’s Creed IV Black Flag and Assassin’s Creed Origins. On these two games, I worked with the world team. I work with programmers and content creators to establish the content creation pipeline, develop new game features, develop new tools and support content creators in their daily tasks. I love the technical director role because I get to work with a lot of different people from different trades and I get to work on lots of different things. One day I’m in the engine figuring out the best way to implement a feature, the next I’m writing C# scripts to help speed up world designers work, every day is different and interesting.
Working on Assassin’s Creed Origins was an awesome experience for me because we put a lot of work in re-working the world creation pipeline, to allow us to produce a full country instead of only a single city. We introduced a new terrain system, a new persistent AI system and used Houdini Engine to procedurally place assets in the game world.
The World Design Technical Director team (Kevin Coughlan, Roland Levesque, Remi Toupin Gaudet and myself) also developed a new system to help us monitor and validate the game world data. This new method turned out to be a game changer for the world team.
Challenges behind open-world games
On Assassin’s Creed Origins, everyone worked in the same game world, level designers, level artists, quest designers, audio designers, lighting artists and so on. It can happen that one of these content creator breaks something that will affect the work of the others. Something that was working one day, might be broken a week later due to a data change (or a code change). And we might not find out about it right away.
With the size of worlds, the size of the teams working on them and the complexity of the data, it’s very challenging to cover everything with traditional testing processes. It’s a big challenge to make sure that everything that is done is still working in every part of the game, and every day.
That is why we developed tools to help us in that task. We created a system that finds errors in the game data, automatically, every day.
Every morning before we get to work, the system takes the latest game data on the latest code version and it runs a series of tests. The tests are written by Design Technical Directors in C#, they are scripts that run inside our game editor. We mainly test gameplay ingredients and AI setups. Gameplay ingredients include navigation ingredients (like ladders, zip lines, etc.) and interactive ingredients (like ballista, chests, and collectibles). For AI tests we make tests like making sure that their settings have no errors and that navigation mesh exists toward all their potential destinations.
The results of the tests are exported in various forms (spreadsheets, emails and visual maps) to the world team. So when we arrive to work, we have a report of the current game world data situation. We can see if there are issues that require our immediate attention.
For example, if several AI navigation mesh tests fail in a city of the game world, it is urgent that we investigate the problem. If we don’t, quests designer won’t be able to develop their quests and QA won’t be able to test them. By being notified by our system that this problem exists we save precious time and it makes it really easy for us to get working on a fix right away. It’s a huge time saver for everyone.
Procedural approach
Indeed a large portion of the world is being created by procedural content placement, like the placement of trees, cliffs, and fields. We have to make sure that the placement of these assets does not break any gameplay or world locations.
Our system of data validation, tells us if procedural data ended up breaking a gameplay setup. We do that by running a series of tests on gameplay ingredients and AI data. We make sure that no collision is obstructing gameplay ingredients and that navigation mesh is clean around AI setups. If a vegetation asset has been placed on a gameplay ingredient and it will affect the player flow, we will know it. If a procedurally placed rock affects the navigation mesh near an AI destination point, we will know it. When we are faced with bugs like these, we must investigate to see if it’s a setup problem or a problem with the procedural rules.
The visual look and the optimization of the rendering are handled by the Graphic Technical Directors which are also part of the world team. They handle LOD creation, lighting tech, shader creation and much more.
Interconnection
Everyone works in the same game world. So in a way, yes, everything is interconnected! But our tools are made so that we can load only what we want to see or work on. We can load small chunks of the world or a big part of the world depends on your need. You can also load everything if you have enough RAM.
If one part of the world is having issues, it’s invisible to the rest of the team working in other parts of the world, because they probably won’t be loading that area.
Streamlining the production
Our system of monitoring and validation of the world data, helps us find out about urgent issues really fast. So when we receive the reports, we can know what we should be focusing on in priority, to make sure that no one is blocked in their work.
We know the scope of the problems we have in the game and so we can plan in consequence of the scope. Can we simply fix the issues one by one? Should we develop a quick script to fix all issue at once? Should we change the way we integrate that feature?
To help content creators in the placement of certain ingredients, we have developed tools to give live feedback to the editor. If an ingredient is misplaced, a big red line will show up above the ingredient and debug text will tell the user what is wrong. It’s a small improvement that makes a huge change in the daily work of a world designer.
Complex Spaces
We have an internal web-based tool called Atlas. It’s basically Google Maps for our game world. We export tons of data to it, like objects and their position. So that’s one tool we have to spot ingredients that are placed outside of the game world.
We also export the results of our daily tests to Atlas. Which allows the team to quickly see where the problems are in the game. Some people like spreadsheets other prefer visual helpers.
Checklists
Regarding design data, our reports are actually a good chunk of our checklists! Our reports cover, Gameplay ingredients for player navigation, AI setups and various gameplay location validation (fast traveling, location completion, etc…). We also have engine focused tests to make sure that memory, frame rate, and streaming speed is under control. Content directors play the game over and over to make sure that everything is at the right quality level. Basically, we have checklists to make sure that everything is fine on the Technical level, Design level, and Graphic level.
Of course, everything is also tested thoroughly by QA testers.
Advice
The methods we used to create 4 square kilometers game worlds do not scale to create 100+ square kilometers. Don’t just throw more people at the problem to solve it. Do not hand make everything. Re-think your production pipeline, procedural asset placement is a good way to handle large worlds, but it’s not the only one. Better edition tools, faster loading times, fewer regressions in the created content, faster ways to test and error creation prevention are all topics worth investing into.
Do not validate all game data by human hands. Automate everything you can to allow focus on trickier things, game quality, and overall player experience.
For more information on this topic please follow me on Twitter @NyksterR and if you happen to be at GDC 2018 (or have access to the GDC vault), make sure to come and see the talk about our system.