Что значит язык интерфейса в игре

Почему многие проекты не переводят на русский язык? Особенности локализации игр

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

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

Разновидности локализации

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

Как выбирают кому нужен перевод?

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

Топ 8 причин для приобретения лицензионных версий игр

Что касается России, то в отличие от США и Европы, здесь не так охотно покупают игры. Пиратские сайты до сих пор имеют огромную аудиторию, и люди не спешат нести свои деньги разработчикам. К тому же у нас цены на видеоигры действительно высокие и даже не все геймеры могут позволить себе брать игру за игрой. Часто приходится выбирать взять тот проект или другой, причем, как правило, при таком выборе выигрывает игра, в которую просто дольше играть.

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

Базовый набор языков

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

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

Как видите, русского тут нет, да и, скорее всего, ближайшие лет 10 не будет. Это еще одна причина, по которой многие игры лишаются адекватной локализации со стороны разработчиков. Исторически так сложилось, что продавать игры в России невыгодно, соответственно, зачем тратить время на перевод?

Кроме того, Русский язык для иностранцев очень сложный, и локализация под Россию всегда подразумевает сотрудничество со студиями озвучки, для которых русский – это родной язык. Это дополнительные растраты, и мало кто хочет на них идти, зная, что игра в итоге может с треском провалиться.

Почему многие игры на русском?

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

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

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

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

А вам вообще нужна русская локализация? Или знаний английского достаточно, чтобы насладиться игрой в оригинальном переводе? Делитесь своими ответами в комментариях.

Источник

5 принципов хорошего интерфейса в играх

Как понять, что разработчики заботятся об игроке.

Если игра — это дверь в виртуальный мир, то интерфейс — проводник игрока в нём. Задача разработчика при создании User Interface, или UI, — показать вам самое интересное, не дать потеряться и, что главное, не помешать. И для этого интерфейс должен отвечать нескольким принципам.

Принцип №1

Интерфейс отражает общую стилистику игры

Часто UI — самая незаметная часть игры. Вы вряд ли будете вспоминать о нём после прохождения и взахлёб рассказывать друзьям об оформлении игровых меню — хотя и из этого правила бывают исключения. Один из примеров — интерфейс в Assassin’s Creed 2.

Игровой энтузиаст. Любит видеоигры, настолки и рассказывать всем, как они устроены.

Остановимся на самой яркой его части — меню сюжетных миссий. Assassin’s Creed 2 показывает прогресс в истории на изящной спирали ДНК. Каждый раз, продвигаясь вперёд по сюжету, игрок заполняет пробелы в схематичной молекуле — а главный герой Дезмонд Майлс таким образом «вспоминает» жизнь своего предка, записанную в его генетической памяти.

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

«Интерфейс игр серии Persona должен не только передавать игроку информацию, но и быть при этом уникальным, отражать их индивидуальность. Исходя из этого правила мы и выбираем цвета для создания UI. В третьей части — синий, передающий прохладу. В четвёртой — ярко-жёлтый, который удачно сочетается с ретротематикой. В пятой — броский красный, призванный подчеркнуть высокую динамику игры и „активность“ главных героев».

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

Следует, правда, помнить: стильный UI — не всегда хороший UI. Никакая, даже самая эффектная эстетика не спасёт интерфейс, неудачный в функциональном плане.

Принцип №2

Интерфейс интуитивен в использовании

Арт-директор студии TallTroll Games Денис Костроман считает чистоту и ясность важнейшими качествами интерфейса. «Как говорили создатели Google Chrome: „Если вы не видите интерфейс, значит, y нас получилось“. Правило „меньше — значит лучше“ также работает в играх. Чем меньше загружен экран, тем лучше будет user experience (UX — пользовательский опыт)», — отмечает разработчик.

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

Возьмём для примера новые, трёхмерные части Fallout. Как и в изометрических играх серии, почти все меню здесь встроены в Pip-Boy — портативный компьютер, который главный герой носит на запястье. Интерфейс гаджета продолжает ретрофутуристическую тематику игры: тексты и графика, выполненные в зелёном цвете, напоминают ранние компьютеры и ЭВМ.

Здорово? Не очень. Дело в том, что дизайнеры Bethesda взяли устаревшие решения из первых частей Fallout и умудрились приумножить их ошибки.

Читайте также:  Как написать эссе по научной статье

Взгляните на дневник квестов из Fallout: New Vegas. Уже на старте игры он не справляется с потоком информации. Все задания — и основные, и побочные — свалены в один длинный список. Вместе с ним на крохотном экране Pip-Boy едва умещаются подпункты заданий. Детального описания квестов и вовсе нет.

А теперь посмотрите, как ту же проблему решили создатели ремейка «Мор. Утопия». В этой игре дневник миссий оформлен в виде «мысленной карты», где «пузыри» заданий и обрывков информации соединены друг с другом ниточками. Не выполнили часть квеста или не хватает сведений? Пустые «пузыри» подскажут, что делать и где искать.

Наглядно и удобно — притом что система квестов в «Мор. Утопия» куда сложнее, чем в тех же Fallout 3 или Fallout: New Vegas.

Оба примера иллюстрируют аспект, который UI/UX-дизайнеры называют User Flow. В одном случае он позволяет игроку принимать решения на лету. В другом — заставляет его искать нужную кнопку, проклиная разработчиков.

Стоит учитывать, что User Flow существенно разнится от платформы к платформе. Как отмечает Денис Костроман, в зависимости от устройства меняется сам способ взаимодействия пользователя с игрой.

«На компьютере функции вроде drag and drop и определённая загруженность интерфейса являются нормой, потому что мышкой все эти задачи решаются просто. На консолях клавиатуры и мышки нет, так что приходится решать, как обойтись геймпадом, что скрыть, а что показать. На телефоне весь рабочий функционал должен находиться в близкой доступности для большого пальца руки (двух, если игра горизонтальная)».

Денис Костроман,
арт-директор студии TallTroll Games

Как правило, мультиплатформенные игры заранее закладывают разницу между устройствами в дизайн будущего интерфейса. Например, разработчики MMO-шутера Destiny, более успешного конкурента Anthem, ещё в первой части придумали интерфейс-«сетку», который учитывал ограничения (и преимущества) геймпада.

Интуитивность — лишь одна из сторон User Flow. О другой речь пойдёт в следующем пункте.

Принцип №3

Интерфейс сообщает только нужную информацию

Обе части Left 4 Dead вышли больше десяти лет назад, но до сих пор привлекают новых игроков. Причина — увлекательный геймплей, сочетающий доступность с множеством нюансов. И важную роль во всём этом играет интерфейс.

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

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

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

Anthem — классический случай, когда интерфейс понапрасну грузит игрока лишней информацией.

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

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

Принцип №4

Звук — тоже часть интерфейса

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

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

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

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

Мелодия флейты в Civilization 5 сообщает об открытии древних руин, а звук трубы — о том, что другой игрок построил чудо света. Фанаты Cities: Skylines, в свою очередь, моментально узнают звон, извещающий о росте цен на недвижимость в городе.

Cities: Skylines также демонстрирует, что во всём нужна мера. Её разработчикам пришло в голову почти гениальное решение: что, если об обстановке в городе будет извещать игровой аналог Twitter? Так появился Chirper — в общем-то, полезный инструмент, если бы не одно «но».

Chirper не всегда сообщает что-нибудь нужное. Очень часто в нём публикуются городские сплетни и скандалы — но о каждом новом посте вас неизменно оповещает громкое чириканье. А теперь представьте, что вы слышите его каждые две минуты. Скорее всего, подобное быстро начнёт раздражать.

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

Принцип №5

Интерфейс — продолжение мира игры

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

Одним из таких решений стал диегетический интерфейс — то есть интерфейс, помещённый в мир игры.

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

Самой известной из них стала Dead Space, авторы которой придумали встроить полоску здоровья в скафандр главного героя, Айзека Кларка, и проецировать из его шлема игровые меню.

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

Если вы играли хотя бы в одну часть Metro, то знаете, сколько всего там приходится делать вручную. Чтобы узнать, на сколько хватит воздуха в противогазе, нужно взглянуть на наручные часы. Фонарь заряжается только от ручной динамо-машины. Дневник заданий, карта и компас закреплены на планшете для бумаг. И чтобы прочитать их в темноте, предстоит светить зажигалкой.

Конечно, подобные детали могут немного испортить впечатление от игры, как это случилось в случае с Red Dead Redemption 2. В своей игре студия Rockstar настолько увлеклась симуляцией Дикого Запада, что кое-где нарушила ритм геймплея и превратила самые рутинные действия в парад затянутых анимаций.

Серия Metro лишает игрока комфорта игровых меню и заставляет его обратить внимание на окружение. Здесь не получится идти по маячкам и указателям: игрок должен сам исследовать уровни и замечать полезные детали. Это заставляет его почувствовать себя частью выдуманной вселенной — а разве не этого хочет достичь любая видеоигра?

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

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

Денис Костроман,
арт-директор TallTroll Games

Разработчик отмечает, что последнее слово всё равно останется за пользователем: «Как бы вам ни казалось, что вы всё предусмотрели и все задачи решены, решать [будут] всё равно игроки — комментариями и монетой».

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

Источник

Игровой интерфейс и с чем его едят

Всем привет! Данная статья — об игровых интерфейсах и порядку работы с ними. Она предназначена в первую очередь для тех, кто работает в игровой индустрии и в том или ином виде влияет на разработку интерфейса, но при этом сам не является UI/UX специалистом. Проект-менеджеры, продюсеры, геймдизайнеры, программисты, работающие с GUI, художники — я писал этот текст, думая о вас, ребята.

Вступительное слово. В своей практике я не раз сталкивался с тем, что разработкой и проектированием игровых интерфейсов занимаются люди, напрямую к этой области не относящиеся. Скажу больше, часто это люди, для которых обязанности, связанные с интерфейсом, являются дополнительным и нежелательным обременением. Чаще всего это связка геймдизайнер+художник, в которой геймдизайнер продумывает функционал и разметку экранов, а художник добросовестно старается “сделать красиво”. При этом зачастую ни тот, ни другой не имеют опыта работы с интерфейсами, не задумываются о юзабилити, пользовательских сценариях или единообразии элементов и в целом не понимают, как организовать процесс работы с интерфейсом, чтобы получить гарантированно хороший результат. И это происходит не по вине художников или геймдизайнеров, просто сама ниша игровых интерфейсов очень специфическая и узкая, информации по работе с ними очень мало, и людям банально негде набраться опыта, не с чего начать. Я хотел бы поделиться своим опытом и наблюдениями в этой сфере и предложить некую структуру, чек-лист, с которым можно сверяться при разработке игрового интерфейса на (вашем) проекте.

Читайте также:  Что такое род существительных в русском языке правило

Пара слов о себе: работу в геймдеве я начал в 2011 году как flash- и web дизайнер. C 2013 работаю исключительно как дизайнер интерфейсов на игровых проектах, в основном мобильных. За это время я поработал в офисах как небольших стартапов, так и в крупных, устоявшихся компаниях; попробовал себя в качестве фрилансера-удаленщика и приходящего “эксперта”. Всего я поучаствовал в создании примерно двух десятков игр разного масштаба и качества, из которых около дюжины дожили до релиза и лежат в маркете. Если кому интересны конкретные тайтлы — пишите в личку.

И давайте договоримся сразу: то, что написано ниже — ни в коем случае не истина в последней инстанции. Мой опыт ограничен. Если вы считаете, что где-то я написал ерунду (или знаете, как сделать что-то лучше) — пожалуйста, свяжитесь со мной или опишите свое видение в комментариях.

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

1) Определение структуры и главных функциональных частей интерфейса.
2) Прототипирование ключевых экранов в виде схем.
3) Сброка и тестирование прототипа. Поиск стилистики и внешнего вида.
4) Отрисовка экранов, составление UI kit’а. Документация.
5) Внедрение в игровой движок, приемка и контроль качества.
6) Добавление интерфейсных анимаций.
7) Аналитика результатов.

Шаг первый. Определение структуры и главных функциональных частей интерфейса.

В процессе накидывания этих первичных мокапов будут материализовываться “правила”, по которым строится интерфейс на данном конкретном проекте. Как осуществляется навигация? Где будут располагаться кнопки? Сколько текста понадобится и какого примерно размера он будет? Нужны ли тултипы и иные всплывающие элементы и если да, то где и в каком формате?

На выходе вы должны получить генеральную схему экранов проекта, по возможности минимизировав при этом количество “белых пятен” на ней. Выглядит это как-то так:

На что тут следует обращать внимание:

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

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

Шаг второй. Сборка прототипа, поиск стилистики.

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

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

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

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

Вообще, общение с заказчиком — это очень важная часть работы, которая может сэкономить (или потерять, в случае пропуска) всем в производственной цепочке кучу времени. К сожалению, большинство дизайнеров сложно назвать эталоном по части общения с клиентом (я тут, кстати, не исключение). Именно поэтому так важно сделать над собой психологическое усилие, а также объяснить (как себе, так и заказчику) смысл и важность происходящего. Приемка интерфейсов, как и приемка арта — дело сугубо субъективное, от этого никуда не денешься, и крутится оно вокруг личности и системы ценностей заказчика. В процессе работы вы можете давать рекомендации или советы, высказывать мнения и приводить примеры, но последнее слово всегда остается за заказчиком или его представителем, и это логично. А заказчики бывают очень разные: кто-то хорошо представляет, чего хочет, кто-то — нет. Одни могут сформулировать запрос в виде картинок (что просто прекрасно), другие готовы описать на словах (что тоже неплохо), третьим не хватает насмотренности или опыта (а иногда и желания, т.к. они считают, что выполняют тем самым чужую работу) и им требуется помощь с формулировкой мыслей. Вообще, это тема для отдельной статьи. В рамках этого материала мы на этом задерживаться не будем.

Заметка на полях: требования и пожелания от заказчика лучше фиксировать в письменном виде — таким образом ему сложнее потом “передумать” или “забыть” сказанное. И никогда не соглашайтесь на “ой, не знаю, вы там давайте рисуйте что-нибудь, а там разберемся”. Это мартышкин труд, который никому не нужен, в том числе заказчику.

Результаты работы с интерфейсом на втором этапе:

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

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

Заметка на полях: в первую очередь лучше набирать референсы из той же рыночной ниши, что и ваш проект. Дело в том, что если вы наберете отличные рефы из ААА игр для ПК, а сами занимаетесь разработкой мобильной игры, то согласовать-то их может быть будет и проще, а вот реализовать всю эту красоту в ограниченном мобильном формате будет практически невозможно. В результате на каком-то этапе вы столкнетесь с закономерным вопросом от заказчика: “Мы же подобрали такие крутые рефы, почему в результате получилось ВОТ ЭТО?”.

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

Шаг третий. Обкатка прототипа, отрисовка превью экранов.

Итак, у нас есть рабочий прототип, в котором реализован заглушечный интерфейс. Он, в целом, работает, выполняет свою функцию. А еще у нас есть визуальный ориентир для отрисовки экранов в виде набора референсов. Самое время их совместить: “одеть” несколько экранов в понравившуюся “шкурку”.

В процессе отбора рефов обычно становятся понятны основные направления для отрисовки первых экранов-превью: Скажем, если у вас sci-fi сеттинг, а в одобренных заказчиком рефах лежат Deus Ex и XCOM… ну, я бы сказал, что вам придется делать превью как минимум в двух вариациях:

Читайте также:  Саботаж как пишется на английском

А если в рефах лежат какие-то близкие по стилистике экраны (тот же XCOM и, скажем, Mass effect) а времени не очень много, то вполне можно обойтись и одним:

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

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

Результат этого этапа: 3-4 отрисованных экрана “чистового” качества, одобренных заказчиком и обкатанная в прототипе схема интерфейса.

Шаг четвертый. Отрисовка экранов, составление UI kit’а, документация.

Это самый объемный этап работы с интерфейсом, занимающий примерно 70% всего рабочего времени. Причем для него у меня нет каких-то хитростей и лайф-хаков, только кропотливая работа и чугунный зад. Планомерно и постепенно, экран за экраном отрисовываются и внедряются в движок. Одновременно с этим обновляется их состав и функционал (потому что с момента рисовки схем обычно многое уже поменялось), а также составляется документация.

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

Без письменных описаний экранов вы рискуете столкнуться со всеми проблемами, связанными с человеческим фактором, забывчивостью и коммуникационными проблемами. Ваш UX-дизайнер внезапно увольняется и улетает на Бали. Программисты собирают экраны не так, как задумывалось, а так, как они считают правильным, апеллируя к тому, что “им про это не сказали”. Геймдизайнер или проект-менеджер забывает принятые решения, поскольку они не были зафиксированы, и всякий раз выдает новую версию.

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

Дальше немного про GUI pack (или, как его еще называют, UI kit или design case). После отрисовки нескольких базовых экранов обычно становится понятен основной набор элементов, из которых будет состоять ваш интерфейс, а также правила их компановки. При дальнейшей работе с экранами будет примерно на 60-80% состоять из реюза уже готовых элементов по уже готовым правилам. Имеет смысл вынести этот “конструктор” с элементами и описаниями в отдельный, эталонный файл. Выглядит он примерно вот так:


Автор изображения — Johnny Waterman

С готовым UI KIT’ом все в команде (особенно это актуально для верстальщиков и программистов) будут знать, где содержатся самые последние, эталонные версии всех интерфейсных элементов. В то же время, в макетах конкретных экранов дизайнерам можно будет не держать десятки дублирующих слоев вроде всех состояний кнопок и переключателей.

Шаг пятый. Внедрение в игровой движок, контроль качества.

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

Помните, что результат работы UX/UI специалистов — не статичная фотошопная картинка и не абстрактная схема, а красивый и, главное, функциональный интерфейс, с которым будет работать пользователь. То, насколько хорош финальный продукт, показывает, настолько хороши конкретно вы как специалист. Поэтому будьте строги и внимательны ко всем звеньям в производственной цепи, и в первую очередь к себе. Не закрывайте глаза на всякую лажу под предлогом того, что это “не моя ответственность”.

Шаг шестой. Полировка и добавление анимаций.

Это бонусный этап. Будем откровенны: при приближении даты релиза (обычно уже несколько раз перенесенной) у всех в команде начинают пылать различные части тела. Времени на полировку (а особенно полировку интерфейса, которому исторически отводят второстепенное значение) никогда не хватает. Поэтому важно изначально задумываться о том, что и когда вы будете доделывать, а также об интерфейсных анимациях. Есть возможность — добавляйте их сразу, еще при первой сборке экрана. Нет такой возможности — выделите на это отдельное, конкретное время в планах разработки. Жестко стойте на своем и не соглашайтесь отодвигать доделки и анимации на неопределенное “потом”, регулярно напоминайте про них.

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

Шаг седьмой. Аналитика интерфейсов.

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

В реальности такое встречается редко: не все могут позволить себе дорогостоящие плей-тесты, мало кто умеет с ними работать и понимает, зачем они нужны. Даже после софт-ланча часто анализируются только базовые показатели вроде DAU, WAU ROI и т.п., не касающиеся напрямую интерфейсов. Т.е. то, что какая-то кнопка никуда не ведет, на этапе софт-ланча заметят, а вот то, что игроки не догадываются вызвать всплывающую по тапу подсказку, уже нет.

В своей практике я, к своему сожалению и стыду, до сих пор еще не сталкивался с полноценным UX-тестированием и последующей аналитикой результатов. Основным методом принятия решений всегда была т.н. “экспертная” оценка. Это когда решения по теме принимает одно лицо (или небольшая группа лиц) которое, как считается, обладает необходимым опытом и компетенцией. Понятно, что это не самый точный и, мягко говоря, довольно субъективный метод.

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

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

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

Источник

Простыми словами о самом интересном
Добавить комментарий