Nintendo's Open World Industrialization Process - Using Zelda as an Example

type

Post

status

Published

date

Speaker Introduction

First of all, let's introduce the speakers on stage.

Programmer Yuichiro Okamura is the system architect of BotW, responsible for the overall architecture design, production tools and environment development to ensure smooth game development. In this talk, Okamura will introduce the method of open world project management and operation from an engineer's point of view.

Yoshiyuki Oyama has worked on many of the characters in the Legend of Zelda series, and he is responsible for managing the character models in "BotW".

Mr. Okamura is in charge of system and workflow design, while Mr. Oyama manages the work of on-site designers.

Prior to the introduction of specific content, a development tool for "The Legend of Zelda: Breath of the Wild" called "Zelda Editor" was introduced.

This tool edits and manages all the data in the game, and is the core development tool for The Legend of Zelda: Breath of the Wild project, and this presentation will introduce Nintendo's development process based on the premise of this tool, called "Zelda Editor".

The details of the tool will be analyzed and explained in a later article.

Stacked development vs. framework development

Before introducing specific examples, let's first explain the two development concepts from a conceptual level.

According to Mr. Okamura, the game production process can be roughly divided into "stacked development" and "frame development, " and he explained these two approaches using the example of the five-tiered tower building.

Stacked development" refers to a development mode in which the first layer is completely finished, and then each layer is developed according to the style of that layer. (As shown in the picture below)

To put it in a way that's easy for people in China to understand, "Hara Kami" first made Monde, and then went on to make forms like Ritsuki and Inazuma.

On the other hand, "framework development" is a development method where you first visualize the whole tower, make a development guideline, then build the skeleton of the tower, then add the walls and the roof, and finally perfect the decoration. (As shown in the figure below)

The representative of this type of development is naturally The Legend of Zelda: Breath of the Wild. In other Nintendo presentations during the same time period, Nintendo employees described how a 2D version of the prototype was created to test the feasibility of the gameplay before production officially began, and that this process of making the prototype first is in fact the embodiment of framework development.

These two development methods are not good or bad, but are chosen according to the type of game being developed. So for the current Legend of Zelda: Breath of the Wild, which approach is more suitable?

According to Mr. Oyama, who has worked on a number of Zelda titles, games such as Ocarina of the Wind basically use "stacked development". The team would create a level that would serve as a template, and then create the rest of the levels by adjusting the design.

For example, The Legend of Zelda: Ocarina of Time is known for its large-scale labyrinth designs, with mazes such as the Temple of the Forest, the Temple of Fire, the Temple of Water, the Temple of Darkness, and the Temple of Souls being created using a labyrinth template as the basis for the stacked development, which was continually modified and refined.

The reason for this development is that Ocarina of Time's labyrinths have clearly defined areas and stages, and domestic gamers can understand Ocarina of Time's labyrinths as copies that must be played in order.

But Oyama also said that in the open world "The Legend of Zelda: Breath of the Wild", which is full of various monsters, materials, dungeons and other elements that are interconnected, there is no such thing as a clearly differentiated limited area of the level or stage. Therefore, the entire world had to be done right from the start, which inevitably led to the adoption of "framework development".

The main difference between stacked development and framework development is the prototyping phase.

In stacked development, the prototype is a level or a mission that validates the gameplay of the game, whereas in framework development, the prototype is the entire gameplay framework, and the question is how to build the project roadmap.

For stacked development, if it is determined that 5 stages are needed overall, then each stage will have a milestone.

However, framework development like developing an open world does not have such milestones that exist from the start.

As such, Breath of the Wild gradually established milestones as it progressed from prototypes in the framework phase to mass production of materials, and their tinkering and refinement.

Specifically, in the prototype stage, the materials are rough models depicted without extra detail (such as the square boar on the far left of the image below). The material is then gradually refined to get closer and closer to the final version.

The important thing is that the elements that make up the gameplay are included from the initial stage, and are gradually revealed as the development progresses. This is referred to in this talk as a "seamless production process".

Advantages of Framework Development and Hybrid Development

I would like to explain that, as you can see from the comparison of the "Five Towers" picture (one crooked, one square), the Nintendo development team prefers "framework development".

One of the main reasons for this preference is that Nintendo used stacked development in the development of games such as "The Legend of Zelda: The Wind Wand", and encountered a problem with the later content of the lack of top-heavy mess, which is a problem that Nintendo is trying to avoid.

Of course, service-oriented online games (including handheld games) and buyout system of single-player games are different, stacked development and continuous operation, constantly updating online games are indeed more compatible, the author's view is: the entire game of the underlying gameplay or to adhere to the framework of the development, but in the production of the big world can be used in the production of stacked development, that is, hybrid development.

Mainly divided into the following stages:

①

First, before the formal development, the underlying gameplay is decided through discussions, trial prototypes and other forms, and the game framework is finalized.

For example, "Proto-God" was initially planned to be similar to Zelda's depth of environmental interaction, but then point to the end, in fact, the design of these underlying gameplay, if it can be determined at an early stage is able to reduce the workload and rework.

②

Secondly, after determining a good framework, according to the form of stacked development to do open world, and then combined with the plot to open in stages.

For example, in Breath of the Wild, there are a large number of "walls" that restrict players' movement, and the areas divided by these walls can be developed in stacked form and provided to players in batches through updates and large-scale quests.

Here combined with the author's " The Legend of Zelda: Breath of the Wild" in the open world to limit the player's means of action "a brick to cite a jade to illustrate: "Breath of the Wild" in the water god beast where the Zora region due to persistent heavy rain rock wall slippery, players can not through the form of rock climbing over the mountain peaks, which has formed a natural area boundaries.

(The red line in the picture below shows the area boundaries caused by the heavy rain)

Then, in the production of open-world service-oriented online games, you can design it in this way: the valley of continuous heavy rain, outside the valley is the undeveloped open world, the stage of the world mission is to defeat the BOSS that caused the continuous heavy rain; after the open world outside the valley is ready, open up the mission of defeating the BOSS, and the rain stops after the death of the BOSS, so that the players can climb over the peaks to explore the external open world.

The above design will not give people a strong "unfinished" feeling, but through the plot will be due to the stacking of development caused by the "incomplete open world" rationalization.

However, the reason why domestic companies mainly focus on "stacked development" is that some leaders usually want to see the output of the finished product quickly, and mistakenly think that the long time of analyzing, researching, discussing, and trying out in the early stage is "grinding work", which is hard to accept. It is difficult to accept the concept of "framework development", but this also leads to easy "rework".

Three development phases

Next, we will explain Mr. Okamura's development process for Breath of the Wild based on specific milestones.

In contrast to stacked development, framework development starts with all the elements in place and builds on them.

Thus the milestone was designed with three stages, being set like a racing competition with a first lap, second lap, third lap, etc., or the three iterations mentioned at the beginning of this article.

Breath of the wild" will be the game's development process into three stages respectively, in order to avoid unnecessary work in each stage, prohibited some of the work content.

For example, in the first stage, all work other than realizing the core fun of the game is prohibited; in the second stage, only character and environment materials are allowed to be created, and no beautification or refinement is allowed.

The process is represented by these three pigs in the previous picture. In the first stage, only this kind of square pig is allowed to be made to verify the feasibility of the gameplay; in the second stage, a rough model of the pig is made and the other animals are perfected, and only in the third stage is this pig refined and adjusted.

Each phase will be described in detail below.

The longest phase

The first phase was the longest, with more than half of the four years of Breath of the Wild development spent on this first phase, which took a year and a half.

Phase 1 focuses on the essence of the game, the gameplay that results from the player's interaction with the many elements of the world of Hylar (environment, elements, physics, enemies, creatures, etc.).

Of course, this is true for Breath of the Wild, and not necessarily true for other open-world games, such as Elden Phalanx for SoulsLike combat.

As a result, all characters and such need to be reused from previous entries or temporary models in order to reduce unnecessary workload and increase efficiency.

Below is a development schematic, with the blue "past" representing past models and "仮" representing temporary models, which were used first to make the gameplay and plot.

The finished product, Princess Grodd, used the Missy model from a previous work, The Staff of Winds, in the first stage, and other monsters and such were differentiated by different colored kobolds.

In short, from this stage, all game content containing the list of production staff is prepared, making it easy to verify that the game is a good player experience. Verification at this stage allows for early corrections to be made in directions that are not appropriate.

Here is an example for you, "Cyberpunk 2077" in the early demo demo there is a mantis knife climbing wall gameplay and subway system, but later are deleted, in fact, is the early did not validate the gameplay and the possibility of the system.

On the other hand, in the process of reusing resources from previous models and using temporary resources, what were the artists who were responsible for making the actual models doing?

In fact, at this stage, they are not directly involved in the actual game development, and seem to be "doing nothing".

However, the author reiterates that they are not fishing, and that this is not the stage where they are actually out there doing the actual work.

In fact, they were conceptualizing the game's art style and atmosphere, as well as attending training sessions to learn how to use new technologies to aid in development (author's note: this should refer to the Zelda Editor).

In addition, they studied how to express a cartoony art style (author's note: this refers to the style mentioned in Tomo Takizawa's presentation as a way to "trick" the player) and a metallic feel, as well as the workflow required for mass-produced assets and worldview content such as the racial setting.

The workflow can be seen in the image below, it's a bit blurry, I'll try to analyze it, not necessarily accurate, but better than nothing, you can leave a comment if you think I'm wrong.

The first image above from the left should be Link's wrong (NG) poses in different terrains; the one in the middle should be the collision model or modeling for Link modeling for when making different poses; the far right is the comparison of compliant gameplay resources with NG gameplay resources; and the bottom right is the base setting of icons and elements in order to keep the style uniform.

Populating the framework with task management tools

In the second stage, the main task is to replace the temporary model material with the official model.

The schematic is below, note that the previous words have been changed to "formal".

The actual replaced gameplay is very close to the final product, but there are still some rough spots in the textures and NPC animations. It was important to polish these, and the key to that was task management.

The image below is a promotional image from the presentation, and I'm guessing that this might be a video showing that the NPC textures and movements aren't ready yet.

Task management is very important in game development as well as project management. Tasks are simply the work that needs to be done, and are usually managed using specialized tools.

Specifically, a series of tasks containing information such as task content, requirement initiator, developer, and estimated workload are published.

However, traditional task management tools suffer from some "problematic tasks", such as unclear task execution targets, inability to find the location of the data to be corrected, or ambiguous task descriptions. Typically, to avoid these problems, each sponsor needs to pay attention to the format of the task, or have a project manager review and inventory the task.

Nintendo took a bolder solution by adding a dedicated task management feature to the Zelda Editor, combining a task management tool with a development tool.

Unlike the usual task management tools, this one puts all the tasks on the data like "sticky notes". For example, if there's a problem with a kobold model, the task is put on the model's data and says "Please fix the model". Think of it as putting "sticky notes" directly on all the data in the game with instructions to work on it.

Below is an illustration of the task management tool, where a bubble is placed over an in-game scenario to indicate that the requesting party wants to add a "hive" near an enemy stronghold.

As a result, developers have direct access to the data they want to work with, eliminating uncertainty and providing a more granularity to the tasks.

In addition, each piece of data contains a history of the producer, so the developer of the next process can also be automatically identified. These "sticky note" like tasks can be attached to models, shaders, AI, in-game scene coordinates, and everywhere else.

Mass Production and Bug Fixing with Task Management Tools

Let's talk about how designers can utilize this task management tool for mass production of materials.

As mentioned earlier, in the early stages of Breath of the Wild development, in-game resources were made using old artwork resources or temporary resources.

At this stage, the designers created temporary sword resources for 10 weapons and only changed the colors to differentiate them.

Then, they would attach tasks such as "Sword_1 is a sword, Sword_2 is a club, Sword_3 is an axe" to the "Please model the soldier's sword" data.

In this way, tasks can be mechanically batch-ordered using the task management tool. At the same time, by associating tasks with data, accurate and easy progress management can be realized by summarizing tasks.

Okamura showed a progress management table with various weapons on the left side and the right side not very visible, which the author guessed was divided into four columns like this:

Status and days for concept art subordinates, the status is all confirmed and the days are 0.

The status and days of the model production, the status of new tasks, in production and completed, given the schedule is 4 days.

The status and number of days to refine the details, the status is the same as the model, and the scheduling is three days.

The status and number of days for the final product, the total number of days given for scheduling is seven.

Through such task management, the project was completed without deviating too much from the expected time, the following is the development schedule management chart, the horizontal axis is the date, the vertical axis should be the number of models that need to be made, and the vertical coordinate on the left side of the significant increase may be the basic generalized model made after the extension of the subdivided model.

For example, if the basic generalized model such as one-handed sword is made first, and then the ice sword and flame sword are made, then the workload on the chart will be greatly increased.

In fact, the data from the task management tool shows a nice downward curve in the number of tasks, and from here it is also possible to make an estimate of the progress of the whole project.

Since tasks are associated with data, there are no duplicates or ambiguous tasks.

Once all the models had been finalized, the game officially started to produce the models, and the necessary working time was pre-estimated after the actual production in the early stage, so that the time needed to finally complete all the tasks could be inferred.

The second phase of development took a little over a year, but ended up taking only 15 days longer than planned, showing the power of Nintendo's "master time manager".

Phase 3 of Quality Improvement and Bug Fixes

In the final Phase 3, all resources needed to be brought up to the quality of the finished product.

Specifically, the main focus was on finding and fixing bugs in order to improve quality, and the fixes were made using the same task management tools described above.

For example, like in the image below, bugs are graded and progress is displayed.

Moreover, bug reports can be added not only from the Zelda Editor, but also from within the game while testing to play the game. For example, if there is a mushroom with an incorrect sense of scale, you can select that mushroom and attach the bug report as a sticky note.

In addition, since the task management tool supports the scripting engine on which the game runs, it is possible to write scripts directly in the bug report field so that they can be executed immediately with the modified script, so that modifying bugs and testing can be switched seamlessly.

On the other hand, the designer's goal in phase 3 is to check resources where possible and perform beautification work to improve quality.

As in phase 2, the validation work is done by the leader with uniform instructions, for example, model or texture sizes are checked in the worksheets, while other model's such as combustion, buoyancy, water flow, etc. are checked in the tester.

Designers working on model validation and landscaping in a task management tool are much more efficient because access to data is easier and information is centralized. The result is that they are able to focus more on creative work.

Large-scale development also always treats the game as one

These are the three stages of realizing The Legend of Zelda: Breath of the Wild's diverse characters and scenarios.

The first of these phases lasted a year and a half, while the second and third phases lasted around a year. The beginning stages took the longest since Nintendo didn't have the technical knowledge of open worlds to begin with, but the mass production stages progressed relatively steadily.

While the development process should match the style of the game series as closely as possible (author's note: referring to the series' past development according to stacks), the development model of gathering a large number of employees to create a separate editor and mission management tool based on the framework, as in this case, is also a very interesting experiment.

The following figure shows the development process of one of the modules:

As there is no relevant news without explanation, I analyze that the content of this picture may be: the protagonist in the early stages of the first enemy met "Bokoblin", which includes "enemy model", "enemy AI This includes the "Enemy Model" and "Enemy AI" data, which is used for mission management and development.

On the basis of "enemy model" and "enemy AI", generate the character and action of "Pokoblin", put it into demo scene for testing, and finally put it into the game by the The programmer writes the script.

Conclusion

The fact that this editor automatically creates a development ROM every 5 minutes for playtesting shows that Nintendo is very focused on the cycle of gameplay and game development.

While open-world game development is not uncommon, and Nintendo has not gained a lot of experience with open-world development, there is still a lot to learn from this industrialized development process.