Вступление

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

От этого, в первую очередь, страдают игры с высоким drop-rate. Этим термином я назвал частоту получения игроком нового предмета, который нужно изучить и принять решение — что с ним делать.

Явление, в целом, понятное — ресурс разработки ограничен и тратить время на удовлетворение мидкорной части аудитории при наличии других проблем довольно логично.

Я как заядлый игрок в looter-shooters (это неформальное название жанра сессионных ММО шутеров с высоким drop-rate) и как UX-специалист широкого профиля решил попытаться сделать проектировку интерфейса для создания одного и более наборов предметов в максимально простой концепции. Работу сделал большую — и призываю вас ознакомится с последовательностью. проектировки.

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

Сценарная часть

В этот материал не будет включена. Очень коротко освещу ключевые тезисы модели UX для этой проектировки.

Два сегмента в рамках функционального блока: все игроки и продвинутые игроки. Ценность первых выше на старте. Ценность вторых повышается с течением проекта. Из них формируется долговременное ядро. Т.к. мы условно на старте, весь функционал, ради которого я все это затеял, все равно считаем дополнительным. Это означает, что ради него мы не имеем права усложнять места интерфейса общего пользования так сказать 🙂 Это бы нарушало приоритизацию сценариев. Кому интересно, могут посмотреть внутрь спойлера, где лежит картинка с UX-черновичком. Созданию UX-модели в будущем я посвящу отдельный материал.

Выбор концепции

При подборе концепции буду, опираться на вышеупомянутый критерий drop-rate. Спроектировать хочется кейс, позволяющий покрывать диапазон от среднего до низкого, но не ломающийся и при высоком drop-rate. Определим высокую частоту как 20-30 предметов в час, для отсечки.

Карточки

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

Максимальное сокрытие

Так же простой пример, который скрывает все лишнее на втором уровне. В данном случае в lightbox-диалогах похожими на контекстные меню. Адаптировать можно было-бы, но сегодня будем выбирать из чего-то менее инновационного и более практичного.

Особенно сложно водить в рейды казуальных новичков, которые не хотят разбираться с подключением к внешним сервисам – это характерная и важная черта казуального сегмента. Без возможности переодеваться под нужную тактику в рейде они бесполезны. Игра отрезает их от уникальной части контента!

Таких «адов», как в DIM мне тоже не хочется. К тому же в команде создателей DIM нет проектировщика, и реализация получилась местами не юзабельна.

Старое доброе

Обратим взор на «давно придуманное в Симпсонах». Сумки из World Of Warcraft. Вернее, совокупность сумок с окном персонажа, которые вместе представляют из себя почти классический rpg-like интерфейс экипировки с «куклой» и «сумками».

Эта концепция, мне нравиться рядом свойств. Она модульна — легко добавлять и убавлять новый функционал. Она содержит в основе ОЧЕНЬ реалистичную и простую ментальную модель «ящички с ячеечками». Она позволяет реализовать практически любой сценарий сортировки простым drag-N-drop, без сложного функционала.

И мобильная адаптация

Самый ближайший вариант, но максимально упрощенный я встречал у Studio Nord в Hustle Castle. Приятная концепция, которая еще и позволяет отработать сценарий сравнения, который в работающем виде не так часто встречается.

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

Крестик против стрелочки

Часто возникает вопрос, а в каком варианте навигацию по экранам делать лучше?

а) — как череду экранов с кнопкой назад в левом верхнем углу

б) — как наслоение (или «стопку») экранов с крестиком в правом верхнем углу

Вопрос выглядит философским, но мне крестик в правом верхнем углу для закрытия текущего контекста, заметно удобнее стрелочки в противоположном углу. Я играл в топ-проекты, использующие этот вариант — мне было удобно. Я спрашивал людей, играющих в тот же проект — им тоже было удобно. Еще этот вариант чуть проще адаптировать под дисплеи. Проектов не один ни два — несколько. Многие из них я считаю эталоном UX\UI в мобильном секторе. Я предпочитаю вариант навигации с крестиком.

Я так же играл в топ проекты, использующие стрелочку слева. Мне было менее удобно, особенно на планшете. Мне неудобно правой рукой достигать левого верхнего угла, с высокой частотой, особенно.

Меня пытались втянуть в драку ни раз, призывая НЕ использовать крестики на окнах и диалогах (не путать с экранами). Но у меня на памяти было два теста, где сверяли UI в диалогах «с» и «без» крестика. В большинстве случаев отсутствие крестика (где предполагалось закрытие через тап мимо, например) вызывало лёгкий ступор осмысления у тестируемых. После этого я перешагивал через аргументы «это же не страшно», «не все же у нас тупые», «дай я на своем айфоне Х» и делал «с крестиком». Долгое чтение UI — это плохо для проекта. Не нужно делать усилий, чтобы немножко испортить проект.

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

Утрамбовка концепции

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

Я честно пытался найти острый угол, об который эти люди бились головой, но не преуспел. Пытался вспомнить, где такое возможно — вспомнил популярную в узких кругах операционную систему EVE Online от 2002 года выпуска. Там действительно можно настроить dashboard, благодаря оконной системе UI, под свои нужды, хоть на все ваши мониторы. Но ни один человек, который этим пользуется не скажет, вам, что он этому рад и что ему удобно. Интерфейсы, специализированные под конкретные сценарии, всегда побеждают dash-boards, но для их создания нужно значительно больше труда.

Я не буду пытаться сделать «в один клик» без диалогов второго уровня — это затруднит создание концепции не давая взамен НИЧЕГО. Диалог — бьет все другие варианты своей гибкостью и универсальностью.

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

Вариант с диалогом же, даст нам гораздо больше гибкости. Его можно расширять вплоть до полноэкранного варианта, если понадобиться. К тому же, сценарий сравнения, который нам, скорее всего, не помешает, трудно реализовать без диалогов в концепции.

Запасной вариант

В силу, того, что я выбрал для проектировку систему сложнее среднестатистической (в процессе оказалось, что сильно, но «Орешек знаний тверд! Но мы не привыкли отступать!» (с) советский т\ж «Хочу Все Знать»), может понадобиться расширение области инвентаря или увеличение сложности рубрикатора. В этом случае будем двигаться в направлении полноэкранных интерфейсов, а не комбинированных (инвентарь + манекен), как текущий рабочий вариант.

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

Теперь, когда мы выбрали шаблон для детализации начнем проработку групп элементов UI.

Черновая сетка

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

Набросок сетки я делаю на три размера: основной, минимальный и планшетный. Почему так и почему это размеры 1280х720, 960х640 и 1024х768 я готов рассказать позже в отдельном посте — оно того стоит.

К сожалению, очень часто правила масштабирования UI выбираются не корректно. От применяемой мною модели можно шагнуть в любую сторону, что уже не маловажно, но скорее всего она еще годы проработает «as is». Упрощенно можно сказать так — Все что влезает одновременно в эти разрешения легко адаптировать под любое устройство с помощью ОЧЕНЬ простого кода (сам могу написать — значит просто). Под «любым» я имею в виду «и консоли», «и мониторы» и любой вообще экран.

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

Разбираемся со слабым местом

Я, конечно, с запасом взял количество слотов вокруг «куклы» 3х4 — всего 12. При этом можно вместить еще. В Division 2 экипировки касаются 9 слотов: 6 для частей защиты, 3 слота под оружие. Еще есть условный слот специализации, слот гранаты, два слота навыков, но их в этот пример я не потащу. Это избыточная глубина системы.

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

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

Прикольно, но… Начали ограничивать себя по прокрутке в вертикали, ведь для работы «бесконечного ряда» важно переключения закладок свайпами лево-право. Обозначим это стрелочками. Немного сложно будет реализовать двойную прокрутку, подобно разделам «историй» (Stories) из помершего windows phone. Эта концепция мне очень нравилась, да и, например ленты Clash Royal — используют именно ее.

Важное примечание: все известные мне игровые движки (это, собственно UE и Unity) требуют поддержку кодом для того, чтобы реализовать жесты хорошо. Движки содержат в себе систему UI-событий, но собирать и настраивать обработчики нам нужно самостоятельно. Важно наладить работу и поставлять в разработку в документах нужную информацию, касающуюся тонкостей обработки жестов и “разведения” возможных конфликтов. Вот в этом примере, нужно правильно “развести” свайп в стороны с вертикальной прокруткой при наличии тапа в сам предмет. Неопытный в front-end вопросах разработчик, без поддержки, такую обработку скорее всего либо завалит, либо сделает плохо. Кому то – это “Пффф”, но количество приложений, которые не правильно обрабатывают тап в элемент списка с прокруткой велико. Тап срабатывает прерывая обработку свайпа, что не корректно.

Переходим к последнему варианту реализаций рубрик, которые более-менее подходят под наш случай. Многоуровневый рубрикатор, где есть категории второго и далее уровней. Звучит страшно, а выглядит обычно.

Теперь мы ограничены только количеством категорий верхнего уровня (они пока получились снизу 🙂 ). Напомню, что в избыточно сложном Division 2 их как раз три: Броня, Оружие, Навыки (включает два навыка и гранату).

Этот вариант мне кажется наиболее годным для черновой концепции. Настало время подумать над опциями взаимодействий с предметами.

Опции взаимодействия

Верстка диалогов обманчивая штука. Разместить много информации в окошке, не просто. Блоки начинают конфликтовать приоритетами, размерами бодаться за места. Процесс компоновки диалога часто растягивается до безобразия. Так случилось и в этот раз 🙂 , не смотря на то, что он учебный!

Должен признать, что попытка сделать понятную мобильную реализацию для очень сложной системы атрибутов из Division 2 провалилась. Вернее, не удалась достаточно хорошо.

Чтобы вместить ее в разумные рамки и завершить этот материал я ее безбожно порезал, оставив от оригинального набора атрибутов только 3 свойства, один perk, который имеет требования, и принадлежность к brand-наборам.

Место под кнопки можно выделить больше (тут есть куда ужиматься) — это важно при проектировке в нечетких рамках. Пока оставлю два очевидных действия, понимая, что легко вмещу сюда еще пять, если будет нужно.

Можно посмотреть наброски переложения системы Division 2 в эту концепцию под спойлером. Она вмещается только с наличием прокрутки в два с половиной минимальных экрана, что, конечно, не допустимо.

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

А! Ну и еще, покопавшись в деталях, мне стало интересно, как создатели Division 2 видят себе своего среднестатистического игрока. У меня есть доказательства, того, что большая часть игроков постичь нюансы системы оказались не в силах. Мой старый пост о подготовке билда к рейду, который морально устарел, до сих пор является основным источником поискового трафика — настолько важна игрокам информация о том, как и из чего собрать себе экипировку.

Не удивительно! И поэтому, тоже, я потащил именно эту систему в этот кейс. Ибо и самому интересно, что получится.

Детали предметов

Поскольку я выбрал квадратное представление предмета, вариантов расположения дополнительных сведений в нем не так и много.

В этот момент нужно провести массовую приоритизацию всех данных и оценить их на полезность для игрока.

Сделав это, я понял, что основным критерием для игрока будет служить — уровень предмета + показатель брони (или урона для оружия). На поздних этапах игры понадобиться больше информации. Уровень заменяется на «Силу предмета», значение приобретают вторичные атрибуты и Perks. Эмблема «набора экипировки» тоже конкурирует за место.

Не очень хорошо выглядит добавление состояния на верхушку квадратика, с помощью которого я «разведу» high-end экипировку, от «проходной». Если придумается как обойтись одним состоянием — будет лучше.

В казуальной концепции демонстрацией всех возможных данных на маленькой площади экрана увлекаться вредно. За этим стоит простая мысль. Нужно чтобы все детали игры, которые требуют времени на осмысление, изучение, понимание, были спрятаны от основной массы играющих до момента, когда они сами захотят постигать нашу игру «в глубину». Это очень важно т.к. для большей части казуальной аудитории такой момент не наступает никогда. Удобно применять для этого принципы «Progressive Disclosure» или поэтапного раскрытия сложности (В моей адаптации. прим.). Это один из ключевых принципов построение экосистем с большим объемом функционала, обладающих разнородной аудиторией.

Тонны материалов, книг и т.д. по ссылке: https://www.interaction-design.org/literature/topics/progressive-disclosure). Игра-сервис — отличный пример, как раз, такой системы. Разнородная аудитория, функционала хватает. Будем нещадно прятать все, что не влезает опираясь на принцип поэтапного раскрытия (или сокрытия, если хотите).

Переключатель, я использую в концепциях как визуальное сопровождение мысли о том, что нужно придумать авто-триггер, до тех пор, пока не придумаю его. Оставлю в макетах на время. Таких “рабочих” элементов управления при сочинении концепции случается много.

Пока думал, нашел решение для «разведения» картинки предмета (не самое полезная информация, в ряде сценариев) и признака принадлежности к набору. И… оказалось, что в оригинале разработчики Division 2, поступают примерно так же. Логика — она одна на всех. Но есть еще женская, да 🙂

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

Сортировка

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

В связи с этим, я набросал оригинальное казуальное решение, значительно упрощающее разбор пачки новых предметов. Родилось оно как раз во время игры в Castle Hustle, где меня все время принуждают надеть или продать в то время, как при первом просмотре я не могу это решение принять. Поэтому появилась кнопка «Отложить на потом…», которая не снимает ярлык «new» с предмета. Такая мелочь, а закрывает приличное количество ситуаций. Проста в реализации и может быть показана всем сегментам. Люблю такое.

Наборы

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

Информационная архитектура

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

«Наборы» на текущий рабочий момент, мне кажутся полноценными категориями нулевого уровня. Из них в IA (информационная архитектура, объектная модель, структура предки-потомки прим.) торчат сначала категории первого уровня: оружие, броня, аксессуары (у нас три категории в макетах, просто потому, что можно, но в системе-прототипе их и вовсе две), а потом дочерние под-категории: перчатки, рюкзаки и пр. Эту простую модель и попробую использовать и посмотреть можно ли этим пользоваться без боли.

Первое приближение вышло вот таким. Пока мне многое не нравится.

Короткий список «некрасивостей»:

• Ряд закладок «наборов» не однородный. Закладка «ноль» не может быть набором — это наш стандартный рюкзак. Грубо говоря в нем есть первый, второй и … мягкий. Как минимум это значит, что его нужно выделять в UI-дизайне (это более поздний этап проработки).
• Как следствие работать списки внутри наборов будут по-разному. Чтобы не путаться, сразу окрещу содержимое закладки «ноль» — «рюкзаком». В нем функциональность будет отличаться от панелей наборов.
• Обязательно делать визуальные группы, которые будут раскрывать то, что называется «подчинением» областей, соответствующим закладкам. В общем-то можно сказать, что содержимое родительской категории должно быть «обведено» рамкой. И в этой области должно главенствовать название родительской категории (название сейчас находится в закладке). Подумаю над этим чуть позже, когда набросаю функционал. Пока подчинение не соблюдено.
• Интерфейс не получается полностью модульным. Без врезки под закладки наборов, уменьшающей список, уложиться в экранное место в этой концепции мне не удалось. Это всегда решаемая задача, но ее имеет смысл делать только если мы уже уверены, что собрались делать именно эту концепцию. Конечно, можно было бы сразу зарезервировать под нее место, уменьшив полезную область ячеек. Но ухудшать интерфейс для всех, ради получения удобства некоторыми (регулярные игроки на high-end этапе) не разумно. Такое возможно, но на позднем этапе оперирования в проектах с устоявшейся аудиторией.

Эти проблемы буду держать в голове и постепенно избавляться от них, по возможности.

Быстрое надевание

Очень непростой блок функционала. Он мне видится так.

Основная неприятность, что такая реализация усиливает не консистентность между видом и функциями в «рюкзаке» (первая закладка) и панелями, связанными с закладками наборов (закладки два и далее).

Но при этом в таком видел очень просто «работать». Затаскиваем предмет в quick slot и вуаля. Думаем дальше. Возможно, «неконсистентность» придется терпеть ради простоты использования. Так как мы делаем дополнительный сценарий, который изолирован от казуалов и новичков, это не страшно.

Drag-N-Drop

Начиная с этого момента, возрастает зависимость от хорошего UI кода. Повторюсь, что игровые движки не дают готовые интерфейсные решения а, лишь содержат в себе систему интерфейсных событий таких как: OnDragStart, OnDrag, OnDragDrop и т.д. Чтобы сложить из этого корректно работающие обработчики нужно усилие, время и немного знаний.

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

Диалог смены иконки набора

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

Я выбрал вариант «быстрого» выбора или pick’а. Важно соблюдать единство во всех диалогах проекта и не допускать разнородного поведения, когда часть диалогов будут «быстрыми», а часть классическими. (классический — с использованием радио группы для выбора и кнопкой подтверждения. прим).

Набору самих иконок следует уделить время в рамках отдельной задачи. Они привязаны к функциям наборов в нашей игре и зависят от ролевой системы. Эту проработку могут сделать либо дизайнеры с нашей помощью, либо мы ее осилим сами. Так у нас появятся наборы для: PvP и PvE, наборы ролей танк\заноситель\урона-целитель и т.п.

Добавление нового в диалоги

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

Пока я грубо набрасываю кнопки, чтобы в последствии, когда объем функционала зафиксируется, как-то их расставить по приоритетам.

Бывают случаи, когда полезно часть функционала «прятать» в некоторых представлениях — но наш случай, явно не такой. Категорически неверно, привязать весь функционал исключительно к функции «перетаскивания». Он относиться к «неявным» функциям, которые значительная часть игроков (смещенная к неопытному в играх и приложениях сегменту) имеют стойкую тенденцию «не находить». А смысл работы проектировщика в том, чтобы исключать такие случаи. Лучше бы и совсем — это возможно.

Сведение концепции

После того, как у нас стал виден весь объем, нужно провести итерацию сведения. Лучше будет избавится от замеченных проблем во время нее. Увы, на 100% это не всегда выходит. Это является прецедентом, отсылающим нас к приоритетам сценариев и сегментов.

Приоритизация закладок

Немного прошелся по закладкам и расположил их в порядке частоты использования (т.е. как положено). По этой же логике наборы должны быть сверху, но пока я не придумал как красиво их совместить с верхне- уровневыми закладками. Об этом будет время подумать на этапе UI-дизайна. Количество слотов куклы я уменьшил, так как запас я взял изначально слишком большой для сложности мобильной игры. Это позволило сделать их размер равным слоту рюкзаку, что добавляет единообразия (консистентности представления).

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

Проработка quickslot

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

Сначала я было собрался добавить действие по помещению предмета в quickslot в диалоги. Потом, сообразил, что quickslot входит в контекст набора, а не самого предмета. Если понадобится (например, частота использования окажется высокой) мы добавим это действие и в контекст предмета в конкретном наборе. Лучше для этого подготовить диалог.

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

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

Итого

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

Я понимаю, что некоторые будут критиковать эту концепцию как не заслуживающую внимания сложность. Ну а те, кто пытался, но не смог, будут вздыхать. Для меня ярким примером этой «ненужности» остается следующее наблюдение. Команда из трех или четырех человек, которая запустила сервис DIM (Destiny Item Manager) у которого DAU около 100 тысяч. У всей Destiny в это же время 500-700 тысяч, что открывает нам долю казуалов, которым пользоваться сторонним сервисом для игры, кажется избыточно сложным. Периодически команда DIM проводит благотворительный сбор средств на базе сервиса. Сумму в 10.000 Euro они собирают за два или три дня. Восхищаюсь ребятами. Не подумайте, что я не в курсе того, сколько собирают проекты в топ-100, но здесь идет речь о команде в несколько человек. Сопоставьте цифры и факты сами. Про китов, про их хардкорность, про нужное и ненужное.

Скорее всего критикам, стоит провести обновление своего понимания вещей, для соответствия реальности. И больше играть, конечно.

Особую благодарность хочется выразить своему коллеге, которой упомянул меня в своем регулярном дайджесте проекта Аус Хестов, что дало возможность познакомить с моими материалами большее количество людей. По ссылке вы найдете подборку его постов, среди которых очень много и полезного и интересного.

Ссылка на главную страницу проекта Аус Хестов: http://aushestov.ru/

---

На этом я с вами прощаюсь. Ждите продолжения!