Как левел-дизайнеры создают уровни

Инструменты и этапы разработки.

Рассказываем, какими инструментами пользуется профессиональный левел-дизайнер и как устроен процесс создания уровня. При подготовке материала использовалась информация из блога Михаила Кадикова и комментарии Дениса Куандыкова. Оба преподают на курсе по левел-дизайну «OutBlock».

Инструменты левел-дизайнера

Бумага

Большинство уровней начинаются с прототипа, нарисованного на бумаге, а многие локации так и не переживают этот этап. Такие наброски встречаются в артбуках, дневниках разработчиках и блогах, посвящённых разработке видеоигр.
Это разветвлённая цепочка блоков, стрелочек и бесконечных уточнений, которая призвана отобразить не карту планируемого уровня, а скорее схему взаимодействий игрока с ним.

Метрики

Следующим инструментом пользуются не все, но именно он отличает опытного левел-дизайнера. Вместе с геймдизайнерами создатель локаций формирует метрики — правила, шаблоны, своеобразные линейки, которые позволяют проектировать уровень не «на глаз», а по заранее определённым параметрам.

Метрики — это всегда фиксированные величины. Они определяют всё, что угодно: например, ширину оврага, преодолеваемую прыжком, высоту укрытий, дальность полёта пули из конкретного оружия. Габариты элементов окружения тоже сверяют с метриками, — иначе собачья конура на уровне нечаянно может оказаться размером с дом.

Блокауты

Определив метрики, левел-дизайнер собирает блокауты — трёхмерные макеты уровня. Их всего два типа.

Designer block out или grey box — это макет используют для проверки геймплея. В нём есть только то, что непосредственно влияет на игровой процесс. Серые кубы, сферы, цилиндры и плоскости схематично отображают будущую локацию, хотя и создаются с учётом всех пропорций и масштабов. Неважно, насколько красиво нарисована яма с кольями — главное, чтобы игрок точно мог через неё перепрыгнуть.

В грейбоксе тестируют механики — например, можно ли здесь забраться, спрятаться. Изучают как ощущается геймплей и сложность. Если что-то не работает, проблемный элемент выкидывают или переделывают.

Пережив все правки по механикам, прототип обрастает деталями и превращается в Art block out, он же — White box. В нём художники прорабатывают визуальную часть уровня: накладывают на серый эскиз цвет и полноценные модели вместо фигур.

Этапы создания локации

1. Планирование

На этом этапе вся команда разработчиков решает, какое место конкретная локация займёт в финальной игре. Если у левел-дизайнера возникают собственные идеи касательно сценария или геймдизайна, то их обсуждают именно на этом этапе. После этого нужно продумать напряжённость уровня и его структуру.

Напряжённость событий регулирует накал эмоций на каждом этапе прохождения. На уровне нужны «слабые доли», чтобы игрок мог отдохнуть после сложного этапа, и «сильные», — чтобы он не заскучал.

Эмилия Шац, левел-дизайнер Uncharted 4:

На каждый участок уровня мы добавляем что-то, что сказывается на общих ощущениях от игры. Например, всё окружение в одной локации может намеренно быть скруглённым, будто текущим, и игроку в этом месте будет комфортно. Он почувствует, что может спокойно исследовать локацию, не рискуя быть убитым. А следующий участок, наоборот, напичкан противниками, а повсюду валяется разбитая мебель. Играть с подобными контрастами и учитывать эмоциональное состояние игрока во время прохождения уровня — это для меня бесценно.

Можно выделить три основных типа структуры уровня.

Линейная — все ответвления локации возвращают героя на основные «рельсы». Пример — Call of Duty: Modern Warfare.

Кластерная — цепочка центральных хабов, от каждого из которых отходят несколько дополнительных путей. Пример — Resident Evil 2.

«Паутина» — соединение множества кластерных уровней, по которым игрок может свободно перемещаться и проходить уровень нелинейно. Пример — Watch Dogs 2.

2. Работа с бумагой

Когда и концепция, и структура, и напряжённость уровня сформированы, левел-дизайнер воплощает все задумки на бумаге. Он создаёт эскиз локации, обозначает на нём основные этапы игрового процесса, расставив ключевые задачи игрока. Затем он прописывает всё это в технической документации.

Михаил Кадиков, левел-дизайнер Crytek:

Техническая документация поможет описать все компоненты будущего игрового окружения и прикинуть, сколько времени понадобится на их производство. Таким образом, под занавес первого этапа мы получаем четкое видение уровня и ответы на самые главные вопросы — как он будет выглядеть, играться и что нам понадобится для его сборки.

3. Создание играбельного прототипа.

Это тот самый «серый» блокаут. Благодаря Grey box левел-дизайнер может впервые увидеть локацию своими глазами.
Бесцветные, недетализированные геометрические формы позволяют быстро изменять структуру уровня, убирать и добавлять огромные куски локации, при необходимости стирать всё подчистую и начинать заново. Иногда на этом этапе не все геймплейные механики готовы к использованию, поэтому дизайнеру приходится внедрять их постепенно, адаптируя уровень под постоянно меняющиеся условия разработки.

На этом этапе левел-дизайнеру пригодятся созданные заранее метрики. С ними проще соблюсти пропорции и масштаб уровня и проследить, чтобы персонаж мог залезть на все нужные уступы и не бился головой о слишком низкие потолки. На одну простую комнату блокаута может потребоваться несколько десятков метрик.

Несоблюдение метрик может испортить игроку всё удовольствие от прохождения, если макушка главного героя будет предательски торчать из-за очередного стола во время перестрелки.

Михаил Кадиков, левел-дизайнер Crytek:

После того, как левел-дизайнер определился с размерами уровня и задал правильный масштаб, нужно как можно скорее сделать его играбельным. Для этого потребуется настроить весь необходимый функционал (точки появления персонажей, триггеры скриптовых событий, среда для искусственного интеллекта и т.д.).

4. Тестирование геймплея

Во время игровых сессий дизайнер наблюдает за тестировщиками и собирает отзывы, чтобы выявить самые раздражающие факторы. Новые итерации уровня тестируют до тех пор, пока не устранят наиболее критичные проблемы.
На этом этапе движок игры уже достаточно стабилен и может рассчитывать, например, работу камеры. Особенно это важно в играх от третьего лица. Левел-дизайнеры следят, чтобы стены и небольшие предметы не загораживали игроку обзор, а сама камера не упиралась в границы локации.

Или наоборот: чтобы камера во всё упиралась, заставляя игрока почувствовать клаустрофобию. Например, в той же Dark Souls регулярно встречаются узкие тоннели и катакомбы, которые давят на игрока.

К тому же, чем меньше вокруг персонажа пустого пространства, тем сложнее маневрировать. В таких местах камера превращается в ещё один невидимый элемент левел-дизайна.

Для левел-дизайнера также важны ограничения игрового движка. Иногда фантазия создателя локаций превосходит возможности технологии, которая эту локацию отрисовывает. В такие моменты дизайнеры уровни вместе с программистами прибегают к хитростям. Самая известная — приём «бутылочного горлышка», или Occlusion culling. Игроки сталкиваются с такими элементами уровня регулярно и, если «горлышки» сделаны хорошо, почти не замечают их.

Денис Куандыков, левелдизайнер VOID Interactive:

Лифты из Mass Effect, тесные улочки в The Last of Us, любой узкий лаз из перерождённой Tomb Raider — все эти места призваны замедлить прохождение игрока, чтобы движок в это время выгрузил использованные ресурсы и подгрузил новые.

В таких ситуациях Occlusion culling, то есть отсечение всего того, что не видит камера игрока, работает очень быстро, так как может сразу целыми кусками «срезать» окружение позади игрока. А одно из самых удачных применений этой технологии можно встретить в Uncharted 2, на уровне в поезде — когда игрок открывает дверь между вагонами, фоновая локация меняется.

Итог этого этапа разработки — план-схема. Когда она утверждена, планировка локации останавливается, — за исключением особых случаев. С этого момента прототип уже не изменяют, а только шлифуют.

5. Создание White box

Когда первоначальный блокаут отслужил своё, левел-дизайнеры переходят к созданию прототипа геометрии. К работе над уровнем подключаются художники по окружению и концепт-художники. От них на этом этапе зависит куда больше, чем от самого левел-дизайнера — ведь теперь, когда планировка локации утверждена, дело за визуальной проработкой.

Михаил Кадиков, левел-дизайнер Crytek:

Из временных моделей на основе геймплейного прототипа собирается «белый» уровень. Художник по окружению должен постараться не только оставить геймплей прототипа неизменным, но и использовать любые художественные средства для улучшения навигации по уровню (освещение, композиция, контраст и т.д.).

Интересный пример разницы между всеми видами блокаутов можно подсмотреть в Uncharted 4: A Thief’s End. На изображении ниже представлена локация из эпизода «The Twelve Towers», которая очень наглядно демонстрирует разницу между этапами разработки уровня: от геймплейного прототипа, собранного левел-дизайнером, к прототипу геометрии локации, нарисованного художником, и, наконец, до финальной версии уровня.Изображение из блога Михаила Кадикова

Изображение из блога Михаила Кадикова

Иногда после прорисовки окружения локация перестаёт быть играбельной — к примеру, тумбочка загородит обзор, а временная грубая модель дерева перекрывает выход с уровня. Тогда уровень снова переходит в руки левел-дизайнера.

Теперь ему нужно ещё раз проверить, правильно ли работают механики, везде ли может пройти игрок и видит ли он при этом всё, что нужно. Тут вновь пригодятся метрики. После того, как «белый» блокаут подтвердит, что всё работает как задумано, на руках у левел-дизайнера окажется почти готовый уровень, собранный из временных моделей и текстур.

6. Cоздание финальной версии уровня

Это самый ответственный этап для левел-дизайнера, — ведь в его распоряжение попадает результат работы всей команды разработчиков. И именно ему предстоит собрать из всего созданного контента цельную локацию.
Тумбочки становятся похожими на тумбочки, на них ставят вазы, сквозь кроны деревьев пробивается солнечный свет.

Михаил Кадиков, левел-дизайнер Crytek:

После того, как весь финальный контент попадает в игру, необходимо сразу же произвести его «заморозку». С этого момента наполнять уровни новым содержанием строго запрещается, так как все силы бросаются на оптимизацию производительности — настраивается дистанция прорисовки геометрии уровня, меняется качество отображения моделей персонажей, спецэффектов, теней, удаляются неиспользованные ассеты и так далее.

Наконец, разработка уровня заканчивается активным тестированием финальной версии и исправлением найденных ошибок. На этом производственный цикл можно считать завершенным.

Изменения в процессе

На протяжении разработки игра может сильно меняться — как в технологических аспектах, так и в геймплейных. Зачастую какие-то этапы создания игры обгоняют другие или, наоборот, отстают от них. Поэтому левел-дизайнер должен быть готов в любой момент вносить правки и исправлять ошибки. Лучше всего это делать ещё на этапе «серого» блокаута — бесцветные примитивные формы довольно просто передвинуть, изменить или вовсе убрать.

А вот правки на поздних стадиях разработки куда сложнее и дороже, — иногда из-за простого изменения маршрута необходимо будет создавать новые модели или записывать новые реплики. Поэтому ценятся левел-дизайнеры, способные как можно раньше найти на уровне проблемное место и либо «починить» его, либо вообще удалить.

Например, к началу разработки Uncharted 4 у команды разработчиков накопилось множество идей. Самой заманчивой была механика крюка-кошки — это приспособление должно было освежить перемещение по уровню, добавив окружению интерактивности.

По изначальной задумке главный герой должен преодолевать ущелья с помощью трёх отдельных действий: достать верёвку, раскрутить её и забросить на конкретный уступ. В меру сложно, в меру интересно. Механика выглядела отлично — но только на бумаге.

На практике же левел-дизайнер Эмилия Шац уже на этапе «серого» блокаута обнаружила, что процесс получился слишком громоздким и только замедляет прохождение: рано или поздно начнёт раздражать игрока. В итоге геймдиректор Uncharted 4 Брюс Стрейли принял решение упростить механику: теперь для использования крюка достаточно нажать на одну кнопку.

Брюс Стрейли, геймдиректор Uncharted 4:

Есть куча идей, которые работают на бумаге, или когда вы говорите о них за обедом: было бы здорово, если бы… Но когда вы пытаетесь проверить их в игре, они быстро разваливаются.

А вот другой пример того, как проблемный элемент локации обнаруживается в почти готовой версии уровня. На скриншоте ниже — игра, над которой работал левел-дизайнер Денис Куандыков. Серые скалы в центре локации — это так называемый «поздний» блокаут, сделанный уже после того художественного оформления уровня.

Денис Куандыков, левел-дизайнер VOID Interactive:

Это костыль, который лечит проблемы локации, сделанной, что называется, «на красоту» — то есть, она получилась совершенно нечитаемой и, к тому же, со сломанным масштабом. По сути, вышла просто огромная равнина. Но равнины не рассказывают историй, на равнинах сложно сделать интересное зонирование и подарить игроку разнообразные впечатления. Поэтому поверх изначальной локации мы добавили эти огромные блоки, нарезавшие всю равнину на зоны разной сложности.

Чтобы добавить всего несколько скал, пришлось переделывать маршруты персонажей, создавать модели и текстуры камней. Но решение оправдало себя: из-за перепада высот и перекрытой линии горизонта на локации сформировались конкретные игровые зоны. Новый элемент уровня сделал лес более выраженным, добавил вокруг себя несколько ущелий — и плоская равнина заиграла новыми красками.

В такой мир игроку хочется отправиться и ощутить себя первооткрывателем. Например, за добавленными скалами видны огромные колонны и арки. В первоначальной версии уровня игрок бы просто пошёл к ним напрямую, не исследуя локацию, а в новой версии ему придётся тщательно выбирать свой путь и, следовательно, формировать своё собственное приключение.

Основы проектирования навигации для приложений для Windows Navigation design basics for Windows apps

Если вы рассматриваете приложение как коллекцию страниц, термин навигация описывает действие перемещения между страницами и на странице. If you think of an app as a collection of pages, navigation describes the act of moving between pages and within a page. Навигация является отправной точкой взаимодействия пользователя с интерфейсом. Она служит для поиска содержимого и функций, интересных пользователю. It’s the starting point of the user experience, and it’s how users find the content and features they’re interested in. Это очень важно, и иногда сложно сделать правильно. It’s very important, and it can be difficult to get right.

Есть огромное количество способов реализации навигации. We have a huge number of choices to make for navigation. Можно сделать следующее: We could:

Требовать от пользователей просматривать ряд страниц по порядку. Require users to go through a series of pages in order.

Создать меню, которое позволит пользователям переходить непосредственно к любой странице. Provide a menu that allows users to jump directly to any page.

Поместить все на одной странице и предоставить механизмы фильтрации для просмотра содержимого. Place everything on a single page and provide filtering mechanisms for viewing content.

Не существует единой схемы навигации, подходящей для каждого приложения. Существует набор принципов и рекомендаций, которым можно следовать, чтобы разработать правильный проект приложения. While there’s no single navigation design that works for every app, there are principles and guidelines to help you decide the right design for your app.

Принципы хорошей навигации Principles of good navigation

Начнем с базовых принципов разработки удобной навигации: Let’s start with the basic principles of good navigation design:

• Согласованность: соответствуйте ожиданиям пользователя. Consistency: Meet user expectations.
• Простота: не делайте больше, чем нужно сделать. Simplicity: Don’t do more than you need to.
• Понятность: предоставляйте понятные пути навигации и варианты выбора. Clarity: Provide clear paths and options.

Consistency Consistency

Навигация должна быть согласована с ожиданиями пользователей. Navigation should be consistent with user expectations. Использование стандартных элементов управления, с которыми пользователи уже знакомы, и общепринятых обозначений для значков, расположений и стилей позволит сделать навигацию предсказуемой и интуитивно понятной для пользователей. Using standard controls that users are familiar with and following standard conventions for icons, location, and styling will make navigation predictable and intuitive for users.

Пользователь ожидает найти определенные элементы пользовательского интерфейса в стандартных расположениях. Users expect to find certain UI elements in standard locations.

Простота Simplicity

Отсутствие большого числа элементов навигации упрощает принятие решений для пользователей. Fewer navigation items simplify decision making for users. Реализация удобного доступа к важным пунктам назначения и скрытие менее важных элементов поможет пользователям находить то, что им нужно, быстрее. Providing easy access to important destinations and hiding less important items will help users get where they want, faster.

Представляйте элементы навигации в знакомом меню навигации. Present navigation items in a familiar navigation menu.

Не перегружайте пользователя различными параметрами навигации. Overwhelm users with many navigation options.

Понятность Clarity

Понятные пути навигации обеспечивают возможность логической навигации для пользователей. Clear paths allow for logical navigation for users. Благодаря очевидным вариантам навигации и упрощению связей между страницами пользователь не потеряется в приложении. Making navigation options obvious and clarifying relationships between pages should prevent users from getting lost.

Пункты назначения должны иметь четкую разметку, чтобы пользователи знали, в каком разделе они находятся. Destinations are clearly labeled so users know where they are.

Общие рекомендации General recommendations

Теперь на основе знаний о наших принципах проектирования — единообразии, простоте и понятности — попробуем сформировать некоторые общие рекомендации. Now, let’s take our design principles—consistency, simplicity, and clarity—and use them to come up with some general recommendations.

Подумайте о пользователях. Think about your users. Подумайте над тем, какие пути пользователи могут часто использовать для навигации в вашем приложении, а также для каждой страницы, поразмышляйте о том, почему пользователь находится на конкретной странице и куда он собирается перейти в последствии. Trace out typical paths they might take through your app, and for each page, think about why the user is there and where they might want to go.

Избегайте глубоких навигационных иерархий. Avoid deep navigation hierarchies. Если уровней навигации будет больше трех, вы рискуете тем, что пользователь застрянет в многоуровневой иерархии, которую ему сложно будет покинуть. If you go beyond three levels of navigation, you risk stranding your user in a deep hierarchy that they will have difficulty leaving.

Избегайте прыжков вверх и вниз. Avoid «pogo-sticking.» Прыжки вверх и вниз возникают, когда есть связанное содержимое, но для перехода к нему необходимо, чтобы пользователь перешел на один уровень вверх, а затем снова вниз. Pogo-sticking occurs when there is related content, but navigating to it requires the user to go up a level and then down again.

Использование подходящей структуры Use the right structure

Теперь, когда вы ознакомились с общими принципами навигации, какую структуру вы бы создали для приложения? Now that you’re familiar with general navigation principles, how should you structure your app? Существует две общие структуры: плоская и иерархическая. There are two general structures: flat and hierarchal.

Плоская или боковая Flat/lateral

В плоской или боковой структуре страницы располагаются рядом друг с другом. In a flat/lateral structure, pages exist side-by-side. Вы можете переходить от одной страницы к другой в любом порядке. You can go from one page to another in any order.

Мы рекомендуем использовать плоскую структуру в следующих случаях. We recommend using a flat structure when:

• Страницы могут просматриваться в любом порядке. The pages can be viewed in any order.
• Страницы явно отличаются друг от друга и не имеют очевидных отношений типа «предок — потомок». The pages are clearly distinct from each other and don’t have an obvious parent/child relationship.
• Группа содержит менее 8 страниц. There are less than 8 pages in the group.
  (Если в группе больше страниц, пользователю может быть трудно понять, чем они отличаются друг от друга, или определить свое текущее местоположение в группе. (When there are more pages, it might be difficult for users to understand how the pages are unique or to understand their current location within the group. Если вам кажется, что затруднений не возникнет, используйте одноранговую модель организации страниц. If you don’t think that’s an issue for your app, go ahead and make the pages peers. В противном случае используйте иерархическую структуру, чтобы разбить страницы на две или несколько более мелких групп.) Otherwise, consider using a hierarchical structure to break the pages into two or more smaller groups.)

Иерархическая Hierarchical

В иерархической структуре страницы организованы в древовидную структуру. In a hierarchical structure, pages are organized into a tree-like structure. У каждой дочерней страницы имеется одна родительская, но одна родительская страница может иметь одну или несколько дочерних. Each child page has one parent, but a parent can have one or more child pages. Чтобы попасть на дочернюю страницу, сначала необходимо обратиться к родительской. To reach a child page, you travel through the parent.

Иерархические структуры хорошо подходят для упорядочивания сложного содержимого, занимающего большое количество страниц. Hierarchical structures are good for organizing complex content that spans lots of pages. Недостаток ее заключается в некоторых издержках навигации: чем глубже структура, тем больше нажатий требуется пользователям, чтобы перейти от страницы к странице. The downside is some navigation overhead: the deeper the structure, the more clicks it takes to get from page to page.

Мы рекомендуем иерархическую модель структуры в следующих случаях. We recommend a hierarchical structure when:

• Просмотр страниц должен осуществляться в определенном порядке. Pages should be traversed in a specific order.
• Существует четкая иерархическая связь между страницами — «родительский — дочерний». There is a clear parent-child relationship between pages.
• Группа содержит более 7 страниц. There are more than 7 pages in the group.

Объединение структур Combining structures

Вам не нужно выбирать какую-то конкретную структуру. Многие хорошо разработанные приложения одновременно используют плоскую и иерархическую структуры. You don’t have to choose one structure or the other; many well-design apps use both. В приложении могут использоваться плоские структуры для страниц верхнего уровня, которые можно просматривать в любом порядке, и иерархические структуры для страниц, которые имеют более сложные связи. An app can use flat structures for top-level pages that can be viewed in any order, and hierarchical structures for pages that have more complex relationships.

Если в структуре навигации имеется несколько уровней, мы рекомендуем, чтобы одноранговые элементы ссылались друг на друга только в пределах своего текущего поддерева. If your navigation structure has multiple levels, we recommend that peer-to-peer navigation elements only link to the peers within their current subtree. Изучите следующую иллюстрацию, на которой показана трехуровневая структура навигации: Consider the adjacent illustration, which shows a navigation structure that has two levels:

• На уровне 1 элемент одноранговой модели навигации должен предоставлять доступ к страницам A, B и C. At level 1, the peer-to-peer navigation element should provide access to pages A, B, and C.
• На уровне 2 элементы одноранговой модели навигации страниц A2 должны ссылаться только на другие страницы A2. At level 2, the peer-to-peer navigation elements for the A2 pages should only link to the other A2 pages. Они не должны ссылаться на страницы уровня 2 поддерева C. They should not link to level 2 pages in the C subtree.

Использование правильных элементов управления Use the right controls

Когда вы решите, какую структуру страниц хотите использовать, вам нужно решить, как пользователи будут переходить по этим страницам. Once you’ve decided on a page structure, you need to decide how users navigate through those pages. UWP предоставляет разнообразные элементы управления навигацией, позволяющие обеспечить единообразную и надежную навигацию в приложении. UWP provides a variety of navigation controls to help ensure a consistent, reliable navigation experience in your app.

С некоторыми исключениями любое приложение, которое состоит из нескольких страниц, использует кадры. With few exceptions, any app that has multiple pages uses a frame. Как правило, приложение имеет главную страницу, содержащую кадр, и элемент первичной навигации, например элемент управления представлением навигации. Typically, an app has a main page that contains the frame and a primary navigation element, such as a navigation view control. Когда пользователь выбирает страницу, кадр загружает и отображает ее. When the user selects a page, the frame loads and displays it.

Отображают горизонтальный список ссылок на страницы одного уровня. Displays a horizontal list of links to pages at the same level. Элемент управления NavigationView реализует шаблоны верхней панели навигации. The NavigationView control implements the top navigation pattern.

Используйте верхнюю панель навигации, если: Use top navigation when:

• вы хотите отобразить все параметры навигации на экране; You want to show all navigation options on the screen.
• вам требуется больше места для содержимого приложения; You desire more space for your app’s content.
• значки не четко описывают категории навигации. Icons cannot clearly describe your navigation categories.

Отображает горизонтальный набор вкладок и соответствующее содержимое. Displays a horizontal set of tabs and their respective content. Элементы управления TabView удобно использовать, чтобы отображать несколько страниц (или документов). С их помощью пользователь может изменять порядок вкладок, а также открывать и закрывать их. The TabView control is useful for displaying several pages (or documents) while giving the user the capability to rearrange, open, or close tabs.

Используйте вкладки, если: Use tabs when:

• пользователи должны иметь возможность динамически открывать, закрывать или переупорядочивать вкладки; You want users to be able to dynamically open, close, or rearrange tabs.
• предполагается, что одновременно может быть открыто большое количество вкладок; You expect that there might be a large number of tabs open at once.
• предполагается, что пользователи смогут легко перемещать вкладки между окнами в приложении, которое использует вкладки, как и другие веб-браузеры, например Microsoft Edge. You expect users to be able to easily move tabs between windows in your application that use tabs, similar to web browsers like Microsoft Edge.

Отображает вертикальный список ссылок на страницы верхнего уровня. Displays a vertical list of links to top-level pages. Используется, когда: Use when:

• Страницы располагаются на верхнем уровне. The pages exist at the top level.
• Есть много элементов навигации (более 5). There are many navigation items (more than 5)
• Предполагается, что пользователи не будут часто переключаться между страницами. You don’t expect users to switch between pages frequently.

Выводит список элементов. Displays a list of items. При выборе элемента отображается соответствующая ему страница в разделе сведений. Selecting an item displays its corresponding page in the details section. Используется, когда: Use when:

• Предполагается, что пользователи будут часто переключаться между дочерними элементами. You expect users to switch between child items frequently.
• Вы хотите позволить пользователю выполнять операции высокого уровня, например удаление или сортировку, с отдельными элементами или группами элементов, а также хотите позволить им просматривать или обновлять сведения о каждом элементе. You want to enable the user to perform high-level operations, such as deleting or sorting, on individual items or groups of items, and also want to enable the user to view or update the details for each item.

Шаблон «Список и подробные сведения» хорошо подходит для почтовых приложений, списков контактов и ввода данных. List/details is well suited for email inboxes, contact lists, and data entry.

Встроенные элементы навигации могут отображаться в содержимом страницы. Embedded navigation elements can appear in a page’s content. В отличие от других элементов навигации, которые должны сохранять единообразие на страницах, элементы управления, встроенные в содержимое, различаются от страницы к странице. Unlike other navigation elements, which should be consistent across the pages, content-embedded navigation elements are unique from page to page.

Далее: добавление кода навигации в приложение Next: Add navigation code to your app

В следующей статье Implement navigation between two pages (Реализация навигации между двумя страницами) показан код, необходимый для использования элемента управления Frame, чтобы реализовать базовую навигацию между двумя страницами в приложении. The next article, Implement basic navigation, shows the code required to use a Frame control to enable basic navigation between two pages in your app.