Раньше я делал анимацию прыжка всего в два кадра. Один кадр на движение вверх, другой на движение вниз. Однако с опытом пришло понимание, что двух статических кадров мало. Я использую следующий вариант: один кадр на движение вверх, один кадр в пиковой точке и два кадра на движение вниз.
Анимация прыжка, нарисованная за 40 минут.
После приземления анимация покоя запускается со второго кадра. Этот нюанс позволяет передать момент инерции.
Для анимации, когда персонаж стоит, очень удобно использовать принципы сжатия и растяжения Уолта Диснея. Время можно сэкономить за счёт двух одинаковых кадров — первого и третьего. Но я обычно делаю кадры разными за счёт лёгкого изменения теней. Это позволяет подчеркнуть рисованный стиль.
Анимация покоя, нарисованная за 30 минут
Анимация хвоста имеет большое значение. Именно с помощью неё можно задать ощущение плавности для всей конструкции. В моём случае получился резкий переход между вторым и третьим кадром, но исправлять я ничего не буду. Необходимо придерживаться обозначенных принципов. Иначе разработка может затянуться.
Создание вражеских персонажей происходит по тому же алгоритму, что и построение главного героя. Хитрость в том, чтобы убрать из процесса всё лишнее. В моём случае у врагов будет только анимация движения. Я специально придумал персонажей без ног, чтобы сэкономить время.
Варианты вражеских персонажей
Несмотря на то, что вражеские персонажи довольно просты, на поиск форм ушло время. В общей сложности на трёх врагов было потрачено три часа. Персонажи будут иметь разные траектории движения, что слегка разнообразит игровой процесс. Ничего особенного. Простая экономия на врагах, которую я постараюсь компенсировать за счет игрового окружения. Об этом в следующей статье.
Здесь я использую один очень хитрый приём. Анимация выстрела будет нарисована отдельно от главного персонажа. Таким образом я буду комбинировать её с анимацией передвижения, прыжка и покоя. Главное — грамотно отцентрировать кадры двух разных анимаций.
Анимация выстрела, нарисованная за пять минут
На нижних рисунках видно, что бластер занимает меньшее пространство на плоскости, чем позволяют размеры кадра. Это сделано нарочно. Мне проще задать центр на самом рисунке, чем потом прописывать координаты для отражения кодом. Когда персонаж будет менять направление движения, кадры будут отражаться относительно оси, которая проходит через обозначенный центр.
Теперь о самой анимации. Очевидно, что большая пуля выглядит эффектней, чем маленькая. Однако разница между диаметрами пули и ствола слишком заметна. Её можно сгладить, добавив во время выстрела вспышку в виде белой окружности. В самой игре при выстреле будет происходить тряска экрана — это значительно увеличит эффект от анимации.
С примерами технического задания и советами от гейм-дизайнеров.
Когда идея игровой механики возникает в голове гейм-дизайнера, она существует в виде абстрактной задумки, у которой нет конкретного воплощения. И чтобы реализовать ее в реальности, он должен как-то объяснить программисту, в чем ее суть — гейм-дизайнеру нужно понятно и однозначно описать свою затею, чтобы разработчик воплотил ее в виде работающей механики.
В игровых студиях для этого пишут техническое задание (иногда его называют дизайн документом для отдельной фичи) — там гейм-дизайнер подробно описывает, что он хочет получить, какие особенности должны быть у механики и так далее.
В этом тексте мы ответим на вопросы, как в студиях составляют ТЗ, какие детали там обязательно расписывают, нужны ли референсы и многое другое. Своим опытом поделились: ведущий гейм-дизайнер студии ITT Михаил Сипцов, ведущий гейм-дизайнер студии Panzerdog Олег Снисаренко, ведущий программист ITT Олег Агеев, старший гейм-дизайнер ITT Алексей Анискин.
Ключевая цель – это получение прибыли. Базовый применяемый для оценки прибыльности критерий: количество денег, принесенных в среднем одним игроком за все время (LTV aka lifetime value), должно превосходить расходы на привлечение этого игрока (CPI aka cost per install).
На этом этапе должно быть полностью отлажено оперирование продукта (техническая поддержка, работа с комьюнити), соблюдаются маркетинговые и финансовые планы, ведутся работы по улучшению финансовых показателей, активно отрабатываются каналы по привлечению трафика.
Команда разработки на этом этапе занимается исправлением технических багов, выявляемых в процессе эксплуатации и оптимизацией продукта. Геймдизайнеры занимаются тонкой настройкой геймплея под реальную ситуацию в игровом мире (особенно актуально для ММО проектов). Также реализует различные внутриигровые фичи, поддерживающие новые монетизационные схемы. И конечно идет разработка и интеграция в продукт нового контента, поддерживающего интерес игроков.
Итак, хотите знать больше? Тогда смотрите полную лекцию, ссылки на которую даны во введении к статье.
Кстати, 21го сентября планируется следующая открытая лекция в рамках нашей программы «Менеджмент игровых интернет-проектов», которая также будет являться аналогом «боевого занятия». На этот раз про монетизационные акции от директора программы Уточкина Вячеслава viacheslavnu. Посещение ее как всегда бесплатно, но обязательна предварительная регистрация в связи с ограниченным количеством мест и входом по списку. Регистрация и подробности про новую лекцию ТУТ.
Задавайте вопросы по теме лекций в комментариях, будем рады ответить.
На мой взгляд, анимация персонажей — самый трудоёмкий этап разработки. Он требует терпения и сноровки. Однако и здесь есть свои хитрости. Прежде всего стоит определить для себя основные приёмы анимации, которые будут использованы в проекте. Не мне рассказывать вам о двенадцати принципах анимации Уолта Диснея. Вы можете самостоятельно ознакомиться с ними на просторах сети. Я же поделюсь с вами своими соображениями насчет анимации.
Конечно, можно сэкономить время, сделав взаимодействие главного героя с врагами путем прыжка им на макушку, как в Super Mario. В этом случае можно пренебречь анимацией выстрела. Мой же персонаж будет уметь стрелять. Я сделаю для этого отдельную анимацию.
Возможно ли создать полноценную игру за три дня?
Но как долго она проживёт? И возможно ли полностью раскрыть идею? А что с качеством реализации? Сколько игрового времени может дать проект, сделанный за два-три дня? Вопросов слишком много.
Я убеждён, что за три дня можно создать хорошую игру. Конечно, придётся балансировать между качеством и временем. Сжатые сроки потребуют от разработчика оригинального подхода к решению проблем. В этом состоянии очень много плюсов. Один из них — это концентрированный опыт, который позволит реально оценить возможности разработчика. Подобная практика будет формировать наиболее выгодные алгоритмы разработки и отсеивать лишние действия.
Разработкой компьютерных игр я занимаюсь три года. Подробнее о моём опыте вы можете прочитать здесь. Главное, что со временем удалось накопить множество небольших хитростей, которые значительно ускоряют процесс разработки. Эти хитрости касаются всех аспектов: рисования, создания анимации, написания музыки и программирования.
Эта статья открывает условный марафон из трёх дней. Каждый день будет посвящен какому-либо аспекту создания игры. На данный момент я могу предложить следующие варианты.
Конечно, по ходу написания материала возможны некоторые изменения, но я постараюсь придерживаться обозначенной последовательности. Также стоит уточнить, что задуманный марафон предполагает подсчёт затраченного времени на разработку, которая будет вестись параллельно с написанием материала.
На подготовку этой статьи у меня ушло три дня, один из которых был посвящён непосредственно самой разработке. Это значит, что финальный проект будет доступен не через три дня, а через больший промежуток времени.
Я буду фиксировать время, потраченное на разработку, чтобы определить итоговый результат. Присоединяйтесь, будет интересно!
Идея как начало конца
Много ли у вас идей? У меня много, но толку от этого мало. Бывает, в голове возникает свежая мысль на уровне образов. Она ещё не имеет своей концепции, но уже вызывает интерес. Такая мысль ненадолго вспыхивает в сознании и может погаснуть навсегда, если отвлечься. Эту искру нужно поймать. Я уже давно записываю все свои творческие вспышки в блокнот, чтобы не упустить их в будущем.
В моменты, когда требуется серьёзная идея, я просто комбинирую записанные в блокнот мысли. Собранная идея обретает свою страницу в блокноте. Такой подход позволяет использовать накопленные записи, освобождая место для свежих мыслей.
Гораздо хуже, когда блокноты копятся, а потом выкидываются. Иногда кажется, что придумать что-то новое гораздо легче, чем поднимать старые записи и искать в них интересные мысли. Это ошибка, из-за которой разработчик обрастает макулатурой. Когда порядок отсутствует, то одни и те же мысли пережёвываются по десять раз. А время идет.
В этот раз я не утруждал себя поиском новой идеи для проекта. Просто открыл блокнот и уже на третьей странице нашёл нужную мне комбинацию мыслей. Можно считать, что на этом этапе я не потратил времени на разработку, ведь идеи были уже готовы.
Главная проблема в том, что некоторые идеи не так просты, как кажется на первый взгляд. Иногда разработка может затянуться из-за непредусмотрительности. Разработчик начинает раздувать искру, и она превращается в пожар, за которым сложно уследить. Все ресурсы сгорают и разработчик остаётся ни с чем. Эта аллегория наиболее точно передаёт суть той ситуации, когда создатель игры переоценивает свои силы.
Бесконтрольное развитие одной идеи может стать причиной смерти всего проекта.
Поэтому так важно ограничить свои амбиции и не выходить за обусловленные рамки. Исходить нужно из реальных возможностей.
Лучший вариант для марафона — это что-нибудь незамысловатое в плане программирования. Творческие задачи, связанные с кодом, могут затянуться надолго. Поэтому я выбрал самый доступный вариант — простой платформер.
В разных проектах структура ТЗ может отличаться, но в любом случае основная задача документации — в простой и недвусмысленной форме донести до исполнителя список требований и условий, в которых будет применяться игровая сущность.
В нашей разработке дополнительно к описанию самих механик еще описывается, как это действие выглядит с точки зрения игрока. Другими словами, желательный результат работы фичи.
Михаил Сипцов, ведущий гейм-дизайнер студии ITT
Хорошая практика в составлении ТЗ — идти от общего к частному. В самом начале стоит написать общий принцип работы фичи. Например: «Добавляем возможность делать кувырок. Во время переката есть период неуязвимости». А дальше нужно последовательно описать механику, разбивая информацию по блокам — подробно описать ее с точки зрения геймплея, настроек и так далее.
При описании механики нужно сделать упор на логических взаимосвязях и ограничениях. Важно описать четкую последовательность действий в рамках конкретной механики, а также всевозможные сценарии использования. Если продолжить пример с перекатом, то в описании механики нужно указать:
При составлении ТЗ гейм-дизайнер должен упомянуть основные параметры механики. Но при этом не стоит указывать конкретные числовые значения — для гейм-дизайнера важно, чтобы в дальнейшем он мог их самостоятельно менять, пробуя разные варианты. К примеру, у переката это может быть дальность, скорость, длительность неуязвимости.
Также стоит учитывать, что ТЗ нужно не только гейм-дизайнеру и программисту, но и другим членам команды. Например, QA-специалисты используют ТЗ, чтобы проверить правильно ли работает механика. В некоторых случаях исполнитель или заказчик конкретной фичи может поменяться, а зафиксированное ТЗ поможет сохранить оригинальную задумку.
Очень трудно уместить в четыре кадра плавную анимацию передвижения персонажей. Особенно, если у объектов имеются очевидные конечности. Поэтому изначально было запланировано нарисовать главному герою условный намёк на лапки. Всё-таки персонаж стилизованный, и я могу позволить себе сместить акцент в сторону общего восприятия. Обойдусь без уточнения таких деталей, как усы и лапки.
Анимация передвижения, нарисованная за 60 минут
За моими плечами 25 компьютерных игр, выполненных в пиксельной графике. На рисованный стиль я перешёл совсем недавно и успел сделать всего два проекта. Это объясняет то, что некоторые приёмы пиксельной анимации перекочевали и в новый стиль.
Стоит пояснить, почему я отказался от пиксельной графики. Проблема в затратах на её анимацию.
Осьминог. Пиксельная анимация
Осьминог, вписанный в плоскость размером 320×160 пикселей с десятью кадрами анимации, занял у меня десять часов работы. Я не вижу ничего сложного в рисовании пиксельной графики. Проблема в том, что этот процесс занимает очень много времени. Особенно пиксельная анимация.
Когда всё сводится к монотонному переставлению пикселей на протяжении нескольких часов — приходит осознание того, что пора менять стиль. Я сам завёл себя в творческий тупик, используя одни и те же приёмы в пиксельной анимации. Игры становились похожими, а развитие визуального стиля остановилось. Было решено отказаться от пиксельной графики. Однако на старых проектах можно проследить некоторую вариативность. Предлагаю оценить разницу между пиксельной анимацией передвижения в пять, шесть и десять кадров.
Пример пиксельной анимации в пять кадров
Пример пиксельной анимации в шесть кадров
Пример пиксельной анимации в десять кадров
Пример пиксельной анимации в шесть кадров. Наиболее удачный вариант
Очевидно, что с увеличением количества кадров можно добиться плавности движения. Но тут есть очень важный нюанс. Необходимо очень точно подобрать скорость движения персонажа и скорость смены кадров. Иногда лучше пожертвовать парой из них, чем делать разную скорость анимации передвижения и покоя. Вообще я пришёл к выводу, что разное количество кадров в разных действиях вызывает лёгкий дискомфорт в восприятии, особенно если анимация бега отстаёт от скорости движения персонажа.
Варианты анимации передвижения
Очень удобно, если у персонажа есть колёсики. Тогда можно значительно сэкономить время на анимации передвижения. Вариантов может быть много. Всё зависит от того, сколько времени готов потратить разработчик на анимацию.
Техническое задание напрямую зависит от проекта и от механики, которую нужно реализовать. Для наглядности мы решили привести несколько примеров ТЗ, которые различаются по содержанию, но при этом их структура в целом схожа.
«Танцовщица с клинками»
Эта механика предназначена для игры Rush Royale в жанре Merge Tower Defence, в которой пользователи выставляют на стол пешки, стреляющие по проходящим мимо противникам. Монстры стремятся достичь ворот замка и уничтожить его. Пешки стреляют по врагу, увеличивая свой урон или меняя определенные параметры при правильной расстановке.
Для пешки «Танцовщица с клинками» текстовое описание работы выглядит следующим образом:
«Атакует первую цель. Если по соседству (на ближайших клетках по горизонтали и вертикали) нет других танцовщиц, то переходит в усиленный режим, увеличивая свою скорость атаки и урон. Урон увеличивается с количеством танцовщиц на поле боя. Максимальный бонус достигается при восьми танцовщицах».
Так танцовщица выглядит в игре
Сами пешки представляют собой некие универсальные сущности, на которые надстраиваются уникальные механики. При этом у всех пешек есть стандартные параметры: например, «урон» и «скорость атаки».
Чтобы из базовой пешки сделать «Танцовщицу с клинками», нужно реализовать следующие механики:
Получается, что танцовщицы получают максимальный прирост к характеристикам при такой расстановке
В итоге у «Танцовщицы с клинками» есть несколько характеристик, настройкой которых занимается гейм-дизайнер:
Механика переключения режимов выглядит так:
«Имеет 2 weapon механики. При условии равенства каунтера соседей 0, начинает работать изменение параметров, заданное в PawnBladeDancer_NeighborAttackChange и PawnBladeDancer_NeighborIntervalChange».
«Падение зомби из труб»
В этой части речь пойдет про механику «доставки» зомби на поле боя в изометрическом шутере.
«Нам нужно, чтобы зомби могли выпадать из труб. Сами трубы могут быть любых форм и размеров. Выпадать зомби будут по стандартным сплайнам, которые будут преднастроены в сценах.
Предлагаю сделать новый компонент, который вешаем на юнита. В нем указываем:
В точки спавна нужно добавить галочку, которая будет говорить нам, что отсюда мы спавним по следующей логике: юнит появляется в виде рэгдолла и, по сути, едет по сплайну. Все это время он полностью неуязвим и его нельзя выбрать как цель. В конце сплайна:
В результате получается, что зомби неуязвимы во время «доставки» на поле боя, но сразу после спавна они становятся полноценными целями.
Возможность определять и сравнивать угол движения аватара
А эта механика предназначается для экшен-RPG от третьего лица.
«Что нужно сделать: в зависимости от угла движения аватара относительно сторон света (направления ветра) ускорять его или замедлять. Например, если ветер дует на север и аватар едет под углом не более 45° к северу, то ускорять, а если более 135° — то замедлять.
Вариант сборки: овертаймово во время движения сравнивать угол аватара с нужным значением с помощью PredicateGreater и при определенных результатах сравнения вешать баффы с замедлением/ускорением. Возможно, даже пробовать скейлить скорость относительно угла.
Тут нужен калкер, который сможет определить угол между аватаром и локатором или угол аватара относительно абсолютных координат мира.
Есть AngleCalcerToLocator или AngleCalcerRelative, они были сделаны для эффекта EffectSpin, чтобы задавать угол поворота. Но эти калкеры не получается использовать с PredicateGreater (нельзя даже соединить их в ДД). Хотелось бы заставить эти калкеры работать с предикатом или изобрести иной способ вычисления угла движения аватара».
Первые шаги при создании игры
Время на прочтение
Сегодня хочу рассказать о том, как делаются игры (громко звучит, но на самом деле ничего сверхъестественного). А точнее, с чего вообще начинается работа над игрой. Самые-самые первые шаги. Еще до исследований рынка, до четкого прописывания USP, до GDD, до прототипа, дизайна уровней и детализации.
Статья пригодится начинающим геймдизайнерам, да и всем, наверное, у кого мало опыта в проектировании чего-либо и вы просто не знаете, с чего начать. Попробуем разложить по полочкам. Итак, поехали=)
Для начала пару слов обо мне
Занимаюсь геймдизайном с 2016 года. Начинала со сценаристики и нарратива, но постепенно ушла в глобальное проектирование игр. Работала с легендарными StepGames (одни из основоположников индустрии в нашей стране, если кто не знает, прославились аж в 1995 году своей игрой Star Heritage для платформы Spectrum), создавала образовательные игры для детей, дизайнила множество VR-проектов различных жанров и направленности, настраивала сцены и баланс, писала много (очень много!=)) GDD, занималась тестированием и разработкой (алгоритмы, код).
Я выделила ключевые этапы, через которые прохожу каждый раз (или почти каждый) вне зависимости от команды, продукта и внешних обстоятельств. Хотя большинство из них проходит вся команда во главе с геймдизайнером, если вы работаете над игрой в одиночку — ваши шаги будут теми же. Разве что могут занять где-то больше, а где-то наоборот меньше времени.
Кратко их можно записать так:
Теперь давайте разберемся, что же происходит на каждом из этапов.
Брейншторм — это такая штука, когда вся команда собирается вместе (онлайн или очно) и накидывает на одной доске все, что взбредет в голову. Выглядит это обычно как каша из картинок, скриншотов из игр и стикеров с надписями. Со стороны звучит как балаган))
Пример результата брейншторма на доске в Miro
Это самый первый этап работы, где генерируется максимальное количество идей. Абсолютно любых, даже тех, что кажутся нереальными или бредовыми. Здесь действует одно правило: чем больше и разнообразнее, тем лучше.
Брейнштормы — дело непростое и не быстрое, к тому же они сильно выматывают. Поэтому часто одного бывает не достаточно. Плюс неплохо, если пройдет какое-то время с первого, чтобы все участники смогли немного переварить этот поток идей.
На второй брейншторм мы собираемся, чтобы взглянуть на все заметки еще раз, взвесить все за и против и отобрать из них то, что может быть использовано в продукте. Обычно отбираем путем голосования, но можно и в ходе активного обсуждения (если команда невелика).
Пример наведения порядка на доске и голосования при помощи стикеров
Этот шаг я предпочитаю проходить без команды. Так как здесь важно собрать все воедино и подчеркнуть суть. Множественные мнения могут мешать процессу (да и если вы адекватный человек и внимательно слушали коллег — вы и так уже знаете их мнение и вправе решить: прислушаться или нет).
Садимся перед доской с последнего брейншторма, внимательно изучаем все, что на ней изображено и из всего этого вычленяем конкретную идею для будущей игры. Идею нужно четко представить себе и записать. Можно также на доске, можно в фигме, в документе или таблицах. Тут уж как кому удобно.
Лично я всегда записываю идею в блокнот и делаю визуальные зарисовки. Бумажные записи дают какое-то дополнительное вдохновение. К тому же, его удобно брать с собой и дописывать что-то, если мысль придет где-нибудь в неожиданном месте=)
Еще один важный этап — поиск продуктов (других игр и приложение), так или иначе похожих на вашу идею. По сценарию, по механикам, по стилю или сеттингу. Выбираем такие продукты и собираем общий список со ссылками и скриншотами. Это пригодится в будущей разработке, когда вы столкнетесь с вопросами, как решить ту или иную проблему или как впихнуть в игру очередную фичу. Посмотрите, как подобное сделано у других и станет проще найти собственное решение (подчеркиваю: не нужно копировать чужую идею, она может подсказать вам собственный путь)
На мой взгляд, диаграммой она называется условно, по факту — это схема последовательности действий, то есть базовый путь игрока по игре со всеми развилками. Этот путь важно прописывать на одном из первых этапов. Но не сильно привязывайтесь к нему. Помните, это лишь базовый черновик и в процессе разработки он может измениться до неузнаваемости.
Два варианта короткой диаграммы связей для игры
Прописываем базовую логику продукта и основные фичи, без которых он просто не взлетит. Обычно эту работу делает геймдизайнер в одиночку, а потом презентует всей команде и вносит коррективы. Чаще всего результатом этапа становится схема, в идеале подкрепленная скринами с примерами. Хотя форматы могут быть любые, какие удобны или приняты у вас.
Упрощенный пример схемы с логикой и фичами игры
Этот этап добавила под звездочкой, так как он может как пропускаться, так и происходить уже на более поздних этапах разработки. Ивент шторминг — это процесс разделения вашей идеи, вашей логики и фичей на четкие игровые события с описанием того, что видит пользователь на каждом таком событии, какое его действие к нему приводит и как эти события должны быть реализованы программно (в коде игры). В этом процессе очень много тонкостей, но о них мы поговорим в другой раз.
Так может выглядеть доска после Ивент Шторминга
P. S. Здесь я решила не вдаваться в подробности каждого этапа, хотя, конечно, многие из них сами по себе вызывают сложности (тот же ивент шторминг, который мало кто умеет правильно проводить). Поэтому, если будет интересно, пишите в комментах и я с удовольствием посвящу им отдельные статьи =)
P. P. S. Это моя первая статья, так что надеюсь, получилось хоть чуточку интересно. Всем добра! И удачи в создании хороших игр =)
Вертикальный срез (Vertical Slice)
Цель Вертикального среза – получить минимально возможную полноценную версию игры, включающую в себя полностью реализованный основной игровой процесс. При этом высокое качество проработки обязательно нужно воплотить только для тех игровых элементов, которые существенно влияют на восприятие продукта. При этом все базовые фичи игры присутствуют как минимум в черновом качестве. Реализован минимальный, но достаточный для воплощения полноценного игрового процесса набор контента (один уровень или одна локация).
Семь этапов создания игры
Как создать свою игру? Сколько на этом можно заработать? Какая нужна команда? Каковы ключевые этапы разработки и что нужно делать команде на каждом этапе? Ответ на эти вопросы – в открытой лекции по разработке игр в рамках программы «Менеджмент игровых интернет-проектов», которую разместили наши партнеры — открытая система электронного образования Универсариум. Вот здесь можно посмотреть открытую лекцию:
А под катом вы найдете краткое текстовое описание.
Лекцию веду я, Константин Сахнов, директор игрового департамента компании Rocket Jump, научный руководитель образовательных программ подготовки кадров для игровой индустрии Высшей школы бизнес-информатики НИУ ВШЭ.
Должен сразу оговориться, в этой статье я приведу только выжимку — список этапов, их цели и логику перехода к следующим. Полная лекция доступна на видео. Помимо подробного описания этапов там есть немного о размере игровой индустрии и расчёте окупаемости игровых проектов.
Большая часть лекции посвящена этапам создания игрового продукта, основным аспектам разработки, документирования, создания игрового контента и развития проекта после начала открытого тестирования. Рассмотрим подробнее эти этапы:
Форма, эскиз и концепт
В мире огромное количество художников. Каждый старается найти свой стиль и обрести узнаваемость. Конкуренция приводит к появлению совершенно новых подходов в анимации и рисунке. С одной стороны, борьба за узнаваемость мотивирует творца делать свою работу лучше, но с другой — некоторые выбирают путь примитивизации форм. Количество элементов в рисунке уменьшается, а наиболее важные структуры гиперболизируются.
Самый простой путь к популярности персонажа — это сконцентрировать внимание зрителя на его лицевых элементах. А ещё лучше заполнить лицом всё пространство силуэта. Этот приём является подобием квинтэссенции кубизма. Пабло Пикассо в своих картинах в буквальном смысле раскраивает изображаемый объект на плоскости, заполняя пространство на холсте.
Две картины художника Пабло Пикассо: «Петух» и «Женщина с петухом»
Большинство современных иллюстраторов используют простые геометрические фигуры в качестве формы для силуэта. Пространство внутри персонажа заполняется наиболее выразительными и запоминающимися чертами. И в итоге всё сводится к банальному акцентированию на форму.
Естественно, что так делают не все художники. Стоит помнить о том, что более сложные смысловые структуры требуют от зрителя определённой подготовки. Можно бесконечно смотреть на творения Казимира Малевича, но без понимания сути супрематизма как силы, двигающейся в сторону «чистой беспредметности», уловить художественную ценность «Чёрного квадрата» почти невозможно.
Современное воплощение идей кубизма. Художественная простота с глубоким философским содержанием
Моя задача — наглядно показать, что даже без знаний основ академического рисунка можно сотворить узнаваемого персонажа. Зачем усложнять творческий процесс, когда уже имеются простые решения. Лучше направить эту энергию на решение новых задач.
Меня интересует простая форма, с которой можно будет комфортно работать. На этом этапе можно позволить себе полную свободу действий. Главное — отталкиваться от простых геометрических фигур. Их удобно комбинировать и дополнять. Поиск формы занял у меня десять минут. Все картинки и анимация нарисованы в Photoshop, но вы можете использовать любой другой графический редактор. Лишь бы вам было комфортно.
После того, как найдена комбинация фигур, можно приступать к первому эскизу. Он будет базироваться на выбранной форме. Удобней рисовать на новом слое поверх скомбинированных фигур, настроив их прозрачность.
Поэтапное создание концепта персонажа
Думаю, стоит подробнее разобрать процесс подготовки концепта персонажа. У меня получилось шесть этапов.
На создание концепта персонажа у меня ушло десять минут. Конечно, можно нарисовать лучше, но зачем? Я делаю компьютерную игру, а не рисую картину на выставку. Здесь стоит помнить, что игра — это совокупность множества элементов. И часто сумма всех слагаемых превосходит ожидаемый результат.
Создание этого концепта заняло 80 минут
Логично предположить, что более детализированный концепт потребует больше времени на анимацию. Я исхожу из того, что мне важен законченный проект. Именно поэтому экономия времени будет на всех этапах. И только когда игра будет полностью собрана, можно рассмотреть вариант дополнительной детализации.
Какие референсы нужны
Наличие референсов заметно упрощает работу — чем сложнее сущность, тем заметнее их помощь. В зависимости от ситуации можно обойтись схемой, а где-то можно приложить ссылку на ролик из YouTube. Чаще всего референсы нужны в том случае, если гейм-дизайнер не уверен в том, что добился полного взаимопонимания с программистом.
Еще один вариант референса — самостоятельно сделать прототип. Обычно это не требуется, но в некоторых студиях сами гейм-дизайнеры реализуют механики при помощи внутренних инструментов. Если же задача слишком сложная, гейм-дизайнер обращается с ней к программистам.
Для большинства новых пешек в Rush Royale существует этап пре-продакшна, на котором мы из кирпичиков собираем что-то максимально близкое к желаемому результату, попутно ставя задачи на новые механики для программистов. Чем больше прототипов делает сам гейм-дизайнер, тем больше ошибок он может предвосхитить. Меньше переделок — больше успеваешь сделать в срок, меньше жалоб на «сырой дизайн». Так что делать прототипы, может быть даже не для своей игры, а «для души» — это рекомендация для любого гейм-дизайнера.
Soft Launch / OBT (открытый бета-тест)
На этом этапе продолжается тестирование игры, но уже на широкой аудитории. Идет оптимизация под большие нагрузки. Игра должна быть готова для приема большого трафика. В игре реализован биллинг и принимаются платежи.
На этом этапе полностью завершается разработка новых фичей. Происходит feature freeze, программисты перестают реализовывать что-то новое, а полностью переключаются на отладку и тюнинг имеющихся фичей. Геймдизайнеры, продюсер и аналитики делают выводы из собранной на CBT статистики и проверяют эффективность монетизации.
Прототипирование (Prototyping)
Важный этап проектирования любой игры – это создание прототипа. То, что хорошо выглядит «на бумаге», совершенно не обязательно будет интересно в реальности. Прототип реализуется для оценки основного игрового процесса, проверки различных гипотез, проведения тестов игровых механик, для проверки ключевых технических моментов.
Очень важно на этапе создания прототипа реализовывать только то, что нужно проверить и в сжатые сроки. Прототип должен быть простым в реализации, т.к. после достижения поставленных перед ним целей, он должен быть «выкинут». Серьёзная ошибка начинающих разработчиков – нести временную инфраструктуру и «костыли» реализации кода в основной проект.
Производство контента (Content production)
На этом этапе производится достаточное количество контента для первого запуска на внешнюю аудиторию. Реализуются все фичи, запланированные к закрытому бета-тестированию. Это наиболее продолжительный этап, который может занимать, для крупных клиентских проектов год и более.
На этом этапе задействуется наибольшее количество специалистов, которые занимаются производством всего основного наполнения игры. Художники создают все графические ресурсы, геймдизайнеры настраивают баланс и заполняют конфиги, программисты реализуют и полируют все фичи.
Дополнительные игровые элементы
Игровое пространство должно быть наполнено разными элементами. В том числе объектами, которые смогут завлечь игрока в сложные ситуации. Такие элементы выступают в роли мотивирующего фактора. Они позволяют игроку накапливать очки, которые в процессе игры можно обменять на что-нибудь полезное. Например, на дополнительную жизнь. Принцип очень стар и банален. В этом случае не обязательно придумывать что-то новое. Меня вполне устраивает вариант с колбаской. На нём я и остановлюсь.
Несмотря на простоту выбранного бонуса, его создание заняло время. На колбаску ушло десять минут. Связано это с поиском наиболее удачного положения и с характером анимации. Конечно, можно бесконечно увеличивать количество кадров и детализацию, но нужно ли это делать? Я считаю, что нет. Совсем необязательно добиваться плавности анимации. Главное, чтобы элемент вписывался в общую концепцию.
Три варианта анимации. Каждый состоит из 12 кадров на кружку и 6 кадров на пар. Итоговое время: два часа
Я напомню, что необходимо придерживаться принципов анимации на протяжении всей разработки. Такой подход позволит выдержать визуальную целостность проекта.
Итоги за первый день
Общее время составило 5 часов и 45 минут. Можно смело округлить до 6 часов. Я думаю, что это оптимальная цифра, которую легко распределить на весь день с учётом бытовых потребностей. Рабочие циклы протяжённостью в два часа позволяют поддерживать энтузиазм и трудоспособность.
К сожалению, я трудился без серьёзных перерывов на протяжении обозначенного времени, что сильно вымотало и утомило. Не совершайте такую ошибку! Работа одновременно над несколькими проектами вынуждает меня уделять разработке по 8-10 часов в день. Это неправильно.
Я знаю разработчиков, которые проводят за проектами по 12 часов. Уверен, что есть и те, кто трудится круглосуточно, уделяя сну 4-5 часов. Сидячая работа перед монитором — не самый лучший способ достичь крепкого здоровья. Про этот аспект не стоит забывать. Молодой и горячий характер, нацеленный на достижение успеха, всегда игнорирует прописные истины. Поэтому берегите здоровье смолоду. Каким образом? Решайте сами. Мои статьи не про здоровый образ жизни.
В заключение приглашаю вас в свою группу. Всем творческих успехов и терпения! До новой встречи!
Концептирование (Concept)
На этом первом шаге команда придумывает концепцию игры, и проводит начальную проработку игрового дизайна. Главная цель данного этапа – это геймдизайнерская документация, включающая в себя Vision (развернутый документ, описывающий игру, как конечный бизнес-продукт) и Concept Document (начальную проработку всех аспектов игры).
В продуктовой документации геймдизайнер формулирует и сохраняет свои идеи. Исполнителю документация позволяет правильно понимать свои задачи по реализации продукта. Тестировщик четко видит, что и как тестировать. Для Продюсера/ПМа эта документация предоставляет материал для формирования планов и контроля выполнения задач. Инвестор же (особенно на ранних этапах) получает понимание, на что именно он выделяет средства.
Принципиально важно, чтобы вся проектная и продуктовая документация поддерживалась в актуальном состоянии на всех этапах развития проекта. Для её эффективного использования и обновления правильно использовать специальные инструменты. Например, использование Confluence для ведения геймдизайнерской документации сильно упрощает процесс параллельного внесения изменений несколькими участниками разработки, а также позволяет всем членам команды оперативно получать любую актуальную информацию, касающуюся продукта и всех его изменений.
Среди ключевых принципов формирования продуктовой документации стоит отметить: структурированность, защищенность от разночтений, полное описание продукта, регулярную актуализацию.
Friends & Family / CBT (закрытое бета-тестирование)
На этапе CBT продукт впервые демонстрируется достаточно широкой публике, хотя и лояльной продукту или компании. Среди наиболее важных задач на этом этапе выступают: поиск и исправление гейм-дизайнерских ошибок, проблем игровой логики и устранение критических багов. На этом этапе в игре присутствуют уже все ключевые фичи, создано достаточно контента для полноценной игры продолжительное время, настроены сбор и анализ статистики. Тестирование идет по тест-плану, проводятся стресс-тесты уже с привлечением реальных игроков.