Вячеслав Уточкин – Хочу в геймдев! Основы игровой разработки для начинающих (страница 29)
Есть примеры сочетания обоих способов: база для динамических данных и XML для статических. Например, гейм-дизайнер решил, что в игре должно быть 20 уровней, и описал их в XML. Эти данные меняться не будут, можно оставить информацию и в этом формате. А вот если нас интересует, на каком уровне сейчас находится конкретный игрок, сколько у него внутриигровой валюты и другие переменные, нужно обратиться к базам данных.
XML легко писать, но тяжело редактировать; базы данных удобнее и быстрее в использовании, но не все гейм-дизайнеры умеют с ними работать. Для онлайн-проектов обычно используются базы данных. Старые игры часто пользовались XML, так как не надо было ничего подгружать в реальном времени.
Базы данных заточены под быструю передачу информации, XML – под удобство описания. Существуют и другие языки, кроме SQL и XML: JavaScript, ActionScript; в Unreal Engine для описания сценариев используют блупринты. Выбор инструментов весьма широкий и зачастую определяется особенностями игрового проекта и личными предпочтениями.
Итак, описание XML кода и структуру базы обычно делают программисты или (в крупных студиях) архитекторы баз данных на основе документов от гейм-дизайнера. После того как вся экономика посчитана, для чего чаще всего используется Excel, гейм-дизайнеру предстоит внести в игру получившиеся значения.
Можно, конечно, заниматься «мартышкиным трудом», переписывая каждую цифру вручную. Многие разработчики так делали, пока не допустили первые ошибки. Именно вероятность допустить ошибку, просмотреть что-то и здоровая лень зародили мысль об автоматизации.
Гейм-дизайнеру очень важно уметь создавать собственный удобный инструментарий, чтобы упростить свою работу. Гораздо эффективнее было бы потратить время и написать программу для автоматизации выгрузки данных из Excel. Помимо ускорения работы, мы можем проработать проверку важных параметров на валидность. Скажем, цена морковки (либо другого ресурса) в нашей ферме не может быть меньше 0. Если такая ситуация произошла, нужно, чтобы Excel или программа выгрузки обратили на это внимание (например, подсветив неправильные значения красным). В некоторых компаниях такие помогающие гейм-дизайнеру программы пишут программисты.
Если гейм-дизайнеру не хватает навыков работы с Excel, сделать это самостоятельно, особенно при работе с базами данных, может быть проблематично. Фактически ему не удастся оградить себя от ненужного труда, ошибок и лишних вопросов со стороны коллег. Руководство студий часто просит работать больше, и задача гейм-дизайнера – вовремя самому задуматься над тем, как оптимизировать свою работу. Реализовав эти идеи, можно раз и навсегда переложить обязанности по проверке данных, расчетам, формированию XML-кода и т. д. на технические инструменты, тем самым автоматизировав часть рабочих процессов.
На скриншоте приведен пример данных из экономической стратегии. Это пример скрипта на языке VBA, который не только проводит расчеты, заполняя недостающие ячейки в Excel, но и создает SQL, XML или JSON код для экспорта в игру. Простой VBA-скрипт (упрощенная реализация языка программирования Visual Basic) пробегается по этому списку и генерирует текст SQL-скрипта, который можно просто скопировать в SQL-редактор и выполнить. Он сам перепишет нужную часть информации в соответствии с тем, что вы прописали в Excel.
Для многих ГД освоение встроенного языка VBA является относительно трудоемкой задачей. Мы рекомендуем однажды найти в себе силы и изучить его, навсегда упростив себе жизнь. Однако, если вам этого категорически не хочется, Excel позволяет решать подобные задачи и более простым путем, например через обычные формулы:
=”INSERT into `buildings` (” & B1 & ”, ” & B2 & ”);”
Надеюсь, нам удалось донести до вас важность создания собственных инструментов. Эта логика верна для любых задач: прежде чем что-то делать, задумайтесь: может быть, вы можете автоматизировать процесс, снизив вероятность ошибки, сохранив свое время и в итоге спасая собственные нервы от перегрузки. Все это – часть общей культуры производства.
АРТ
Любой гейм-дизайнер, даже не планирующий самостоятельно работать над графикой, должен понимать нюансы процессов разработки игрового арта. Чтобы верно рассчитывать время создания графического контента, а также грамотно составлять ТЗ, необходимо определить, какие виды арта существуют и в чем их особенности. В крупных компаниях для создания каждого типа арта существует свой человек или отдел, в маленьких командах эти должности часто совмещаются.
Обычно художники лучше гейм-дизайнеров знают, что и как рисовать. Поэтому нет смысла перечислять, как должен выглядеть каждый камень или стол в вашей игре. Очень редко возникает необходимость уточнить, как именно персонаж должен держать меч или забор какого цвета должен быть в создаваемой игровой деревушке. Назначая задание на арт, важно объяснить, какие ассоциации и ощущения должна вызывать картинка, желательно с примерами, а также обозначить, с какими элементами арт должен сосуществовать.
Обычно концепт-арт создается первым и не имеет самостоятельной ценности. Это часть комплексной задачи по созданию визуального стиля, а не финальная картинка. Концепт-художник должен уметь быстро делать наброски и предлагать разные варианты исполнения того или иного игрового элемента, чтобы гейм-дизайнер и другие члены команды могли от чего-то оттолкнуться при поиске оптимального решения. Такие рисунки могут выполняться без использования специальных программ, без цвета или деталей. Техника выполнения концепт-арта может быть самой разной: можно рисовать от руки, а можно использовать фотографии или фрагменты чужих работ, чтобы сэкономить время. Работа концепт-художника обычно остается внутри компании: игроки видят ее только в том случае, если этот арт используется для продвижения.
Дизайн интерфейсов (UI/UX) направлен на игрока. Сюда можно отнести все, что игрок видит на экране вне рамок игрового процесса: меню, кнопочки, иконки и пр. Именно он помогает легко разобраться с управлением и окружением, правильно расставляет акценты, поэтому имеет свои правила и процессы. Речь идет не только о внешнем виде элементов интерфейса, но и о логике и опыте взаимодействия с ними игрока. Для такой работы критически важно иметь общую стилистику интерфейсов игры. В средних и крупных компаниях дизайном интерфейсов обычно занимаются отдельные специалисты.
Прежде всего гейм-дизайнером составляется задание с полным описанием фичи и ее логики: что это, какие предполагаются виды взаимодействия с игроком, как это должно выглядеть, возможности перехода и т. д. На следующем этапе хорошей практикой считается сделать макет интерфейса без финального оформления. Сначала это просто система переходов, где подробно прописано, что видит игрок, какие методы используются, чтобы облегчить понимание игроком, какой следующий шаг ему необходимо сделать, какие средства помощи игроку предусмотрены, если он не понимает, что происходит. Для этого используют специальные программные средства, например Figma[72], которые позволяют собирать такие схемы переходов с анимациями. Это дает гейм-дизайнеру возможность проверить, все ли работает так, как он задумал, или нужно внести какие-то изменения.
Вообще, гейм-дизайнер и человек, отвечающий за игровой интерфейс, должны много общаться, чтобы иметь одинаковое представление о том, какие вещи играют ключевую роль и должны быть выделены, как та или иная фича выглядит с точки зрения логики и как игроки должны ее использовать. Полезными документами здесь окажутся юзер-кейс или юзер-стори из ГДД, где гейм-дизайнер предполагает, какие шаги может предпринять игрок, что он должен увидеть в тот или иной момент игры.
Не все компании располагают ресурсами для проведения профессионального UX-тестирования в лаборатории, с отслеживанием пульса, движений глаз пользователя и пр. Но чтобы оценить, насколько понятным и приятным получается интерфейс, необходимо собирать отзывы. Если пользователь действует не так, как задумал гейм-дизайнер, значит, что-то уже пошло не так и принятые решения требуют пересмотра.
Хороший интерфейс должен быть незаметен для игрока. Нужно помнить, что есть общие для всех привычки, например закрытие окна – красный крестик в правом верхнем углу. Чтобы поменять его цвет или расположение, нужны веские основания, так как пользователю будет некомфортно привыкать к новой конфигурации. Зачастую имеет смысл делать именно привычные игрокам иконки, окошки, крестики и т. п.
Важно не перегружать интерфейс, чтобы не вызывать ощущения отчужденности. Люди хотят играть, а не нажимать бесконечные кнопки в меню. Не всегда художники знают все нюансы, поэтому, составляя ТЗ, гейм-дизайнер должен обозначить, на что следует обратить внимание, работая над тем или иным элементом.