Дизайн інтерфейсу ігрового проекту однією парою рук

Привіт, Хабр!

Я хочу розповісти тобі не гарний кейс про те, як якась крута студія робила відмінний дизайн, а історію, як у невеликій команді, однією парою дизайнерських рук робилася ММО А-класу, в умовах перманентного дедлайну і брак досвіду у сфері створення ігор.



Наш проект, VirCities — це дійсно велика гра, особливо для одного дизайнера інтерфейсу — кількість тільки статичних екранів наближається до сотні, не кажучи вже про модальних вікнах і станах. Незважаючи на те, що до цього я 5 років займався дизайном, вона стала моїм першим серйозним проектом саме в області ігор, так що я зміг отримати багато нового досвіду і пройтися по цілому ряду неминучих грабель.

Розпаковую валізи

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


Байкер і його стара браузерна версія гри

Коли я прийшов у проект гри вже була робоча, але закрита браузерна версія, від якої відмовилися. З її дизайном все було катастрофічно погано: відсутність сформованого стилю, будь-якої сітки, карикатурний арт, кольору танцюючі у всіх напрямках спектру — ось що мене зустріло при переході на сторінку з вже існуючими «напрацюваннями». Вінцем усього цього пишноти був логотип у вигляді земної кулі, який виглядав так, ніби його завантажили з якогось кліпарта. Але головною проблемою існуючого дизайну була не графічна частина, а дуже слабка зворотний зв'язок, з-за чого складалося враження, що гра взагалі зависла і не працює. Жодного ігрового процесу підтримувати такий дизайн не міг.

Збираю інформацію

На вході, крім поганенької браузерки, у мене було трохи диздоков, набір старих PSD з нереальною кількістю не об'єднаних шарів, наглухо вешающих Photoshop, і широка свобода дій. Моя роль в проекті полягала в тому, щоб перенести гру з браузера на мобільні платформи, хоча я, звичайно, бачив її у порятунку гравців від жаху браузерної версії. Як наслідок, я зайнявся грунтовної переробкою все, до чого тільки дотяглися руки, щоб VirCities стала якісною грою. Зрештою, пікселі і екрани — це лише засоби для досягнення мети: створення позитивного досвіду.


Mindmap, помістилася лише невелика частина

Під час збору інформації перед початком роботи, я попросив геймдизайнера скласти для мене повну майндкарту ігри, уникаючи при цьому використання інтерфейсних сутностей. Так я хотів побачити все на власні сценарії і відгородитися від впливу браузерної версії, щоб випадково не скопіювати звідти поганих рішень. Звичайно, реальний робочий процес виявився суворіше і майндкарта часто програвала того, щоб просто зайти в браузерку і подивитися на все своїми очима. З часом я прийшов до висновку, що ідеальним варіантом передачі інформації від геймдизайнера до графічному дизайнерові є статичні прототипи, в нашому випадку створювані в Balsamiq. Незважаючи на те, що вони використовують інтерфейсні сутності — зрозуміти і переробити їх швидше, ніж розібратися в документації або майндкарте.

Не прототипирую

Коли інформація про проект в тому чи іншому вигляді була зібрана, ми задумалися над повноцінним етапом прототипування. Але в умовах обмежених термінів і великого обсягу роботи було прийнято рішення спритно оминути цей етап і почати відразу робити екрани, збираючи з них цільну картинку Invision і там же тестуючи. Ймовірно, цей трюк добре спрацював на невеликому проекті, але виявився поганим рішенням для ММО-ігри.


Карта екранів в Realtime Board

Нові екрани стали конфліктувати з вже отрисованными і викликати в них зміни, що змушувало постійно повертатися назад. Зараз ми використовуємо Realtime Board для візуалізації карти екранів, додаючи їх у міру появи. Проте, нам все одно періодично доводиться рефакторіть дизайн, підтримуючи її цілісність, з-за відсутності цілісної картини зі старту. Втім, навіть маючи повну карту екранів, при великій кількості макетів вам все одно доведеться повертатися назад, щоб, як мінімум, підтримувати їх актуальність. Таким чином, оцінюючи строки, потрібно враховувати, що якщо на 1 екран потрібно, умовно, 5 годин робочого часу, то на 10 екранів потрібно зовсім не 50, а всі 80, а то і 100 годин. Цього ми, звичайно, не закладали в терміни, що створило критичну нестачу часу і стан перманентного дедлайну — все потрібно було вчора.

Шукаю стиль і настрій



Назва «VirCities» відразу говорить про те, що це гра про міста. Однак, мова зовсім не про містобудівний симуляторі і гра не повинна була бути візуально схожа, скажімо на «SimCity». Наша гра на порядок серйозніше, в ній моделюється реальна політика і економіка. Знайти подібні ігри як референсов виявилося дуже непросто, тому наші мудборды здебільшого складалися з інтерфейсів додатків і держ. сайтів. Чіткий поділ на блоки і мінімалізм підтримувалося і серйозною нестачею арту, а прикрасити інтерфейс різного роду «рюшечками» не представлялося можливим, щоб не випасти з стилю. До того ж, часу і ресурсів на експерименти було мало і я намагався слідувати гайдлайнам платформ, щоб не винаходити нічого зайвого. Все це сформувало поточний вигляд гри — вона наполовину схожа на гру, наполовину на додаток. І хоча цей процес ще не завершений, мені здається, що це той самий вигляд, який потрібен соціально-економічного симулятору.

Наводжу інформацію в порядок

Основою будь-якого дизайну є інформація, а значить з нею повинен бути порядок. Його, як можна здогадатися, у браузерною VirCities не було. Перша поширена проблема — це різні назви для одних і тих же ігрових сутностей. Так, наприклад, в одному місці посада називалася «менеджер», а в іншому вже «керуючий», або професія «лікар», а ліцензія на ній чомусь «доктора». Гравець може не зрозуміти, що мається на увазі одна і та ж сутність і виникне досить неприємна ситуація. Ще однією проблемою було порушення логіки. Ліцензія спортивного тренера мала запас, що вимірюється в якійсь «Енергії», хоча набагато логічніше було б використовувати для виміру кількість проведених тренувань. Більш того, в грі вже був інший показник з такою ж назвою — «Енергія». Бували і списки, які ранжувалися в порядку, відомому лише творцям гри і нелогічні послідовності, начебто такої класифікації предметів одягу: Голова, Тіло, Ноги, Взуття. Хтось може подумати, що це дрібниці. Але якщо в інформації немає міцної логіки та чіткої послідовності — користувач не зможе розуміти систему інтуїтивно, і йому доведеться користуватися довідкою, що в ігрових проектах, як мені здається, неприпустимо.

Втрачаю контроль

Коли значний обсяг робіт по дизайну був готовий, я зіткнувся новим неприємним ефектом.

Працюючи над великим проектом вкрай важливо не поспішати, добре продумувати кожен крок і бажано десь цей крок записувати, підтримуючи макети документацією. Інакше, коли макетів стає більше, ніж можна утримати в голові, починається моторошна плутанина, і цільний дизайн розсипається на окремі, погано взаємодіючі частини. Спочатку, документація по макетів у нас не велася, і зіткнувшись з такою втратою контролю над дизайном, нам довелося взяти солідний перерву, щоб привести все в порядок.

Ще один важливий урок, який я отримав — не заплутатися в макетах допоможе «риба». Якщо сліпо не називати всіх користувачів у списку «Вася Пупкін», а кожної ролі відвести своє ім'я, і заповнити текстові дані всюди максимально реалістично — в макетах з'явиться контекст, який полегшить їх сприйняття.

Знаходжу єдину мову дизайну

image
Набір всіх елементів в окремому файлі як частина гайдлайна

Повернути втрачений контроль мені так допомогло усвідомлення необхідності підтримувати власний гайдлайн не тільки в макетах, але і незалежно від них у вигляді самостійної сутності. Адже щоб гравець міг интутивно використовувати інтерфейс все різноманіття елементів, віконець і екранів має діяти однаково, а на дії гравця реагувати передбачувано для нього. Це єдність неважко підтримувати при невеликій кількості екранів, але зі збільшенням їх числа робити це стає все складніше і складніше. Сформулювати правила інтерфейсу і його компонентів, і винести в окремий файл, стало дуже корисним рішенням, нехай і прийшло воно не дуже своєчасно.

Аналізую досвід

Створення дизайну для такого великого проекту самотужки — це унікальний для мене досвід. У маленьких проектах складно простежити життя дизайну, відчути процес, адже маленькі проекти дуже швидко закінчуються. Якщо раніше я чітко розумів як робиться дизайн, то тепер я ще й знаю, як його підтримувати та розвивати, і наскільки більше на це потрібно часу і сил, ніж просто на розробку макетів. У мене попереду ще дуже багато роботи, ми тільки починаємо тестування, а значить нас чекає ще безліч ітерацій коригувань і поліпшень. Буду тримати вас в курсі.

image

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.